RFC 7547

Management of Networks with Constrained Devices: Problem Statement and Requirements

📅 published May 2015, from ietf

RFC 7547 🎀 Management of Networks with Constrained Devices: Problem Statement and Requirements 💖

Okay bestie, part 1 of 8 is here 🧚 Here's the title block, the vibe check, and the basics before we get into the tea.

  • Document: Request for Comments 7547 📄
  • Title: Management of Networks with Constrained Devices: Problem Statement and Requirements
  • Authors: M. Ersue (Ed.) of Nokia Networks, D. Romascanu of Avaya, J. Schoenwaelder of Jacobs University Bremen, and U. Herberg
  • Category: Informational 🦋
  • ISSN: 2070-1721
  • Date: May 2015
  • Obsoletes/Updates: Nothing is listed. This doc doesn't obsolete or update any other RFCs 💅

Abstract ✨

Okay so this doc gives you a problem statement 🫶 It also covers deployment and management topology options, plus requirements for all the different use cases where you're managing networks that have constrained devices in them. Main character energy 👑

Status of This Memo 🌸

This doc is not an Internet Standards Track spec. It's published just for info, so no pressure to treat it like law 🙈

It's a product of the Internet Engineering Task Force (IETF) and it 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 doc the IESG approves is a candidate for any level of Internet Standard, though. See Section 2 of RFC 5741 for the deets 💀

Want the current status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc7547 🍓

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 date it was published. Please actually read those, because they spell out your rights and restrictions for this doc 🫶 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🔥

Table of Contents 🦋

   1. Introduction ....................................................3
      1.1. Overview ...................................................3
      1.2. Terminology ................................................4
      1.3. Network Types and Characteristics in Focus .................5
      1.4. Constrained Device Deployment Options ......................9
      1.5. Management Topology Options ...............................10
      1.6. Managing the Constrainedness of a Device or Network .......10
      1.7. Configuration and Monitoring Functionality Levels .........13
   2. Problem Statement ..............................................14
   3. Requirements on the Management of Networks with
      Constrained Devices ............................................16
      3.1. Management Architecture/System ............................18
      3.2. Management Protocols and Data Models ......................22
      3.3. Configuration Management ..................................25
      3.4. Monitoring Functionality ..................................27
      3.5. Self-Management ...........................................32
      3.6. Security and Access Control ...............................33
      3.7. Energy Management .........................................35
      3.8. Software Distribution .....................................37
      3.9. Traffic Management ........................................37
      3.10. Transport Layer ..........................................39
      3.11. Implementation Requirements ..............................40
   4. Security Considerations ........................................41
   5. Informative References .........................................42
   Acknowledgments ...................................................44
   Authors' Addresses ................................................44

1. Introduction ✨

1.1. Overview 🌷

Constrained devices (also called sensors, smart objects, or smart devices) have limited CPU, memory, and power, and they can get connected to a network 🧚 That network might be built on unreliable or lossy channels. It could use wireless tech with limited bandwidth and a dynamic topology. Or the device might need a gateway or proxy to reach the Internet. In other situations, constrained devices can hook up to an unconstrained network using off-the-shelf protocol stacks 💅

Constrained devices are often in charge of gathering info in all kinds of places, like natural ecosystems, buildings, and factories, and then sending that info to one or more server stations 🌿 They can also run under severe resource limits: small batteries, not much computing power, little memory, skimpy wireless bandwidth, and limited communication abilities 😭 A central entity, like a base station or a controlling server, usually has way more compute and comms resources. It can act as a gateway between the constrained devices and the application logic in the core network 👑

Today, constrained devices of all sizes, with all kinds of resources and capabilities, are getting connected 🎀 Mobile personal gadgets, building-automation devices, cellphones, machine-to-machine (M2M) devices, and so on all benefit from talking to other "things" nearby or somewhere out on the Internet 🦋 So the Internet of Things (IoT) is becoming real, made up of uniquely identifiable objects (things) ✨ Over the next decade, this could grow to trillions of constrained devices, and it's going to seriously expand the Internet's size and scope 🌈

Network management is all about monitoring network status, detecting faults and figuring out what caused them, setting network parameters, and taking action to clear faults, keep things running normally, and boost network efficiency and application performance 💜 The traditional network monitoring app regularly collects info from a set of managed network elements, processes the data, and presents the results to the network management users 📊 Constrained devices are a whole different story, though. They often have limited power and low transmission range, and they might be unreliable 💀 They might also have to work in hostile environments with serious security requirements, or stay in harsh environments for a long time with no supervision 🙈 Because of these constraints, managing a network with constrained devices comes with a different set of challenges than managing a traditional IP network 🫶

The IETF has already done a lot of standards work to enable communication in IP networks and to manage those networks, plus the many types of nodes in them [RFC6632] 🔥 But the IETF hasn't yet developed any specific tech for managing constrained devices or the networks made of them 😭 IP-based sensors and constrained devices in that kind of environment (with very limited memory, CPU, and energy) currently use application-layer protocols in an ad hoc way to do simple resource management and monitoring 🍓

This doc gives a problem statement and lists requirements for the different use cases of managing a network with constrained devices 🧚 Sections 1.3 and 1.5 describe different topology options for networking and managing constrained devices. Section 2 is the problem statement on managing networked constrained devices. Section 3 lists requirements on managing applications and networks with constrained devices. Heads up: the requirements in Section 3 have been separated from the context they might show up in. Depending on the situation, an implementer may decide to address a certain relevant subset of those requirements 💅

The use cases for networks with constrained devices are in [RFC7548] ✨ This doc is a list of objectives for discussion. It isn't meant to be a strict requirements doc for every use case. Honestly, there likely isn't one single solution that works equally well for all the use cases 🌸

1.2. Terminology 🩷

For constrained devices and networks, this doc mostly builds on the terminology defined in [RFC7228], where terms like "constrained device" and "constrained network" are defined 💜

On top of that, these terms are used throughout 👇

  • AMI: (Advanced Metering Infrastructure) A system made of hardware, software, and networking tech that measures, collects, and analyzes energy use, and that communicates with a hierarchically deployed network of metering devices, either on request or on a schedule ⚡
  • C0: Class 0 constrained device, as defined in Section 3 of [RFC7228] 🍼
  • C1: Class 1 constrained device, as defined in Section 3 of [RFC7228] 🌱
  • C2: Class 2 constrained device, as defined in Section 3 of [RFC7228] 🌷
  • Network of Constrained Devices: A network that constrained devices are connected to. It may or may not be a constrained network (see [RFC7228] for the definition of constrained network) 🫧
  • M2M: (Machine to Machine) Automatic data transfer between devices of different kinds. In M2M scenarios, a device (like a sensor or meter) captures an event, which gets relayed through a network (wireless, wired, or hybrid) to an application 🤖
  • MANET: (Mobile Ad Hoc Network [RFC2501]) A self-configuring, infrastructureless network of mobile devices connected by wireless tech 📡
  • Smart Grid: An electrical grid that uses communication tech to gather and act on info automatically, to improve the efficiency, reliability, and sustainability of electricity production and distribution ⚡💖
  • Smart Meter: An electrical meter in the context of a smart grid 🔌

For a deeper dive on constrained networks and the classes of constrained devices and their capabilities, check out [RFC7228] 🫶

1.3. Network Types and Characteristics in Focus ✨

okay so first things first, we're sorting networks by how they handle transport and communication tech 🫶 these are the types we care about:

(a network in general can involve constrained and unconstrained devices, so don't be surprised when both show up in the same network 💅)

  1. Wireline unconstrained networks, e.g., an Ethernet LAN with constrained and unconstrained devices involved. 🌈
  2. A combination of wireline and wireless networks, possibly with multi-hop connectivity between constrained devices, using dynamic routing in both the wireless and wireline parts of the network. These networks are giving highly distributed apps with lots of nodes (environmental monitoring, for example) and they tend to deal with large-scale multipoint-to-point (MP2P) systems 🦋 Wireless Mesh Networks (WMNs) are a specific flavor. They use off-the-shelf radio tech like Wi-Fi, WiMAX, and cellular 3G/4G. WMNs are reliable because of the redundancy they offer, and they're often more planned in deployment so they can give dynamic, cost-effective connectivity over a certain geographic area. literally so smart 🧠
  3. A combination of wireline and wireless networks with point-to-point (P2P) or point-to-multipoint (P2MP) communication, generally with single-hop connectivity to constrained devices, using static routing over the wireless network. These networks support short-range, P2P, low-data-rate, source-to-sink apps, like RFID systems, light switches, fire/smoke detectors, and home appliances 🏠 They also cover confined short-range spaces like a home, a factory, a building, or the human body. [IEEE802.15.1] (Bluetooth) and [IEEE802.15.4] are the well-known standards for these networks 🔥 By running 6LoWPANs (IPv6 over Low-Power Wireless Personal Area Networks) [RFC4919] and RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] on top of IEEE 802.15.4, you can get multi-hop connectivity and dynamic routing 🧚 With RPL, the IETF specified a proactive "route-over" architecture where routing and forwarding happen at the network layer. The protocol supports MP2P, P2MP, and P2P traffic 💜
  4. Self-configuring infrastructureless networks of mobile devices (e.g., MANET) are a particular type of network connected by wireless tech. Infrastructureless networks are mostly based on P2P communication between devices that move independently in any direction and change their links to other devices all the time 🦋 These devices do act as routers and forward traffic that isn't related to their own use. main character routers, honestly 👑

Wireline unconstrained networks with constrained and unconstrained devices are mainly used for specific apps like Building Automation or Infrastructure Monitoring. Wireline and wireless networks with multi-hop or P2MP connectivity are used for things like environmental monitoring, plus transport and mobile apps 🌸

Furthermore, different network characteristics are determined by multiple dimensions: dynamicity of the topology, bandwidth, and loss rate. Each dimension is explained below, and the networks in scope for this document are outlined too 💖

Network Topology

The topology of a network can be represented as a graph, with edges (i.e., links) and vertices (routers and hosts). Examples of topologies include "star" topologies (one central node with multiple nodes at one-hop distance), tree structures (each node having exactly one parent), directed acyclic graphs (each node having one or more parents), clustered topologies (where one or more "cluster heads" are responsible for a certain area of the network), mesh topologies (fully distributed), and so on 🌳

Management protocols can take advantage of specific topologies. For example, they can distribute large-scale management tasks across multiple distributed network management stations (like in a mesh topology), or use a hierarchical management approach (like in a tree or clustered topology). These different management topology options are described in Section 1.6. 🫶

Note that in certain deployments, such as community ad hoc networks (see the use case "Community Network Applications" in [RFC7548]), the topology isn't preplanned. So it may be unknown for management purposes 🙈 In other use cases, like industrial applications (see the use case "Industrial Applications" in [RFC7548]), the topology may be designed in advance, so the network management can take advantage of it.

Dynamicity of the network topology

The dynamicity of the network topology determines how fast the graph changes over time. These changes happen for different reasons, like node mobility (e.g., in MANETs or cellular networks), duty cycles (low-power devices that only turn their network interface on periodically to transmit or receive packets), or unstable links (especially wireless links with strongly fluctuating link quality) 😭

Examples of different dynamicity levels are Ethernets (typically a very static topology) on one end, and Low-power and Lossy Networks (LLNs) on the other. LLN nodes are often duty-cycled, run on unreliable wireless links, and are potentially mobile (e.g., for sensor networks) 🍓

The more dynamic the topology, the more routing, transport, and application-layer protocols have to cope with interrupted connectivity and/or longer delays. For example, management protocols (with a given underlying transport protocol) that expect continuous session flows without route changes during a communication flow may fail to work ⚠️

Networks with very low dynamicity (e.g., Ethernet) that have no or infrequent topology changes (e.g., less than once every 30 minutes) are in scope for this document if they're used with constrained devices (see, e.g., the use case "Building Automation" in [RFC7548]) 🎀

Traffic flows

The traffic flow in a network determines which sources send data traffic to which destinations in the network. [RFC7102] defines several different traffic flows, including P2P, MP2P, and P2MP flows, as follows:

  • P2P: Point-to-point refers to traffic exchanged between two nodes (regardless of the number of hops between the two nodes). 💌
  • P2MP: Point-to-multipoint traffic refers to traffic between one node and a set of nodes. This is similar to the P2MP concept in Multicast or MPLS Traffic Engineering. 📣
  • MP2P: Multipoint-to-point is used to describe a particular traffic pattern (e.g., MP2P flows collecting information from many nodes flowing inwards towards a collecting sink). 🧺

If one of these traffic patterns is dominant in a network, protocols (routing, transport, application) can be optimized for that specific traffic flow. For example, in a network with a tree topology and MP2P traffic, collection tree protocols are efficient at sending data from the leaves of the tree to the root of the tree, via each node's parent 🌲

Bandwidth

The bandwidth of the network is the amount of data that can be sent per unit of time between two communication endpoints. It's usually determined by the link with the minimum bandwidth on the path from the source to the destination of data packets. Bandwidth can range from a few kilobytes per second (such as on some IEEE 802.15.4 link layers) to many gigabytes per second (e.g., on fiber optics) 💫

For management purposes, the management protocol typically needs to send information between the network management station and the clients, for monitoring or control. If the available bandwidth isn't enough for the management protocol, packets will be buffered and eventually dropped, so management isn't possible with such a protocol 😱

Networks without bandwidth limitation (e.g., Ethernet) are in scope for this document if they're used with constrained devices (see the use case "Building Automation" in [RFC7548]) ✨

Loss rate

The loss rate (or bit error rate) is the number of bit errors divided by the total number of bits transmitted. For wired networks, loss rates are typically extremely low, e.g., around 10^-12 or 10^-13 for the latest 10 Gbit Ethernet. For wireless networks, like IEEE 802.15.4, the bit error rate can be as high as 10^-1 to 1 when there's interference 📡 Even with a reliable transport protocol, management operations can fail if the loss rate is too high, unless they're specifically designed to cope with those situations 🥲

1.4. Constrained Device Deployment Options 🧸

We differentiate the following deployment options for constrained devices:

  • A network of constrained devices that communicate with each other. 🤝
  • Constrained devices that are connected directly to an IP network. 🌐
  • A network of constrained devices that communicate with a gateway or proxy with more communication capabilities, possibly acting as a representative of the device to entities in the unconstrained network. 🪞
  • Constrained devices that are connected to the Internet or an IP network via a gateway/proxy. 🚪
  • A hierarchy of constrained devices, e.g., a network of C0 devices connected to one or more C1 devices -- connected to one or more C2 devices -- connected to one or more gateways -- connected to some application servers or NMS. 🏗️
  • The possibility of device grouping (possibly in a dynamic manner), such that the grouped devices can act as one logical device at the edge of the network, and one device in this group can act as the managing entity. 👯‍♀️

1.5. Management Topology Options 🗺️

okay so there are a few different vibes for who's actually running the show when it comes to managing a network of constrained devices 💅 we call these the following options:

  • One central manager 👑: a single network of constrained devices gets managed by one central manager. This can be done in a hierarchical way so it scales better and stays more robust. The manager and the management application logic might have a gateway or proxy sitting in between, or they might live on different nodes in different networks, like a management application running on a cloud server ☁️
  • Distributed management 🌸: here, a network of constrained devices is managed by more than one manager. Each manager looks after a subnetwork and can talk directly to other manager stations in a cooperative way. This can come in two flavors. It can be weakly distributed, where functions get broken down and handed out to lots of managers dynamically. Or it can be strongly distributed, where almost every managed thing has management functionality built right in and explicit management just kinda disappears 🫥 the catch is that the strongly distributed management logic now needs to be managed itself 💀
  • Hierarchical management 🧚: a hierarchy of networks with constrained devices gets managed by managers at their matching hierarchy level. Each manager is responsible for the nodes in its own subnetwork. It passes information up from its subnetwork to its higher-level manager, and it passes management functions received from that higher-level manager down to its subnetwork. Honestly this is mainly a scalability mechanism, and the decision-making can still be centralized ✨

1.6. Managing the Constrainedness of a Device or Network 🦋

the capabilities of a constrained device or network, and how constrained it is, really shape what the management of that network or device needs to look like 🫶

heads up that the list below is just examples and is NOT a complete list, so don't treat it like the whole story 🙈

A constrained device:

  • might only support an unreliable (e.g., lossy) radio link 📡, which means the client and server of a management protocol need to gracefully handle incomplete command exchanges or missing commands.
  • might only be able to go online from time to time, which is when it's reachable. So a command might need to be repeated after a longer timeout, or the timeout value that one endpoint waits on a response with needs to be sufficiently high ⏰
  • might only be able to support a limited operating time (e.g., based on the available battery 🔋), or it might behave as 'sleepy endpoints' that set their network links to a disconnected state for long stretches. So the devices need to economize their energy usage with suitable mechanisms, and the managing entity needs to monitor and control the energy status of the constrained devices it manages 😴
  • might only be able to support one simple communication protocol. That means the management protocol needs to be able to downscale from constrained (C2) to very constrained (C0) devices, with a modular implementation and a very basic version that has just a few simple commands 🧩
  • might only be able to support a communication protocol that is not IP based 🤷‍♀️
  • might only be able to support limited or no user and/or transport security. So the management system needs to support a less-costly and simple but sufficiently secure authentication mechanism 🔐
  • might not be able to support compression and decompression of exchanged data because of limited CPU power. So an intermediary entity that can compress data should be able to talk to both devices that support data compression (e.g., C2) and devices that do not (e.g., C1 and C0) 🗜️
  • might only be able to support a simple encryption. It would be beneficial if the devices use cryptographic algorithms that are supported in hardware, and if the encryption is efficient in terms of memory and CPU usage 💜
  • might only be able to communicate with one single managing entity and can't support parallel access from many managing entities ☝️
  • might depend on a self-configuration feature. The managing entity might not know all devices in a network, so the device needs to be able to initiate connection setup for its own device configuration 🛠️
  • might depend on self- or neighbor-monitoring features. The managing entity might not be able to monitor all devices in a network continuously 👀
  • might only be able to communicate with its neighbors. So the device should be able to get its configuration from a neighbor 🏘️
  • might only be able to support parsing of data models with limited size. So the device data models need to be compact, containing the most necessary data, and if possible parsable as a stream 🌊
  • might only be able to support a limited or no failure detection. So the managing entity needs to handle the situation where a failure does not get detected, or gets detected late, gracefully, e.g., by asking repeatedly 🔁
  • might only be able to support the reporting of just one or a limited set of failure types 🚨
  • might only be able to support a limited set of notifications, possibly only an "I am alive." message 💓
  • might only be able to support a soft-reset from failure recovery 🔄
  • might possibly generate a large amount of redundant reporting data. So the intermediary management entity (see [RFC7252]) should be able to filter and aggregate redundant data 🧹

A network of constrained devices:

  • might only support an unreliable (e.g., lossy) radio link. So the client and server of a management protocol need to repeat commands as necessary, or gracefully ignore incomplete commands 📶
  • might need to be managed based on multicast communication. So the managing entity needs to be prepared to configure many devices at once based on the same data model 📣
  • might have a very large topology supporting 10,000 or more nodes for some applications. As such, node naming is a specific issue for constrained networks 🌐
  • needs to support self-organization. Given the large number of nodes, their potential placement in hostile locations, and frequently changing topology, manual configuration of nodes is typically not feasible. So the network would benefit from being able to reconfigure itself so it can keep operating properly and support reliable connectivity 🐝
  • might need a management solution that is energy efficient, using as little wireless bandwidth as possible, since communication is highly energy demanding ⚡
  • needs to support localization schemes to determine the location of devices, since devices might be moving and location information is important for some applications 📍
  • needs a management solution that is scalable, since the network may consist of thousands of nodes and may need to be extended continuously 📈
  • needs to provide fault tolerance. Faults in network operation, including hardware and software errors or failures detected by the transport protocol, should be handled smoothly. In such a case, it should be possible to run the protocol at a reduced level but avoid failing completely. For example, self-monitoring mechanisms or graceful degradation of features can be used to provide fault tolerance 🛡️
  • might require new management capabilities, for example, network coverage information and a constrained device power distribution map 🗺️
  • might require a new management function for data management, since the type and amount of data collected in constrained networks is different from traditional networks 🗃️
  • might also need energy-efficient key management 🔑

1.7. Configuration and Monitoring Functionality Levels 📊

okay so devices often differ a LOT in how much configuration management support they give you. this document sorts configuration management functionality into these levels:

  • CL0: devices are preconfigured and allow no runtime configuration changes. The configuration parameters are often hard coded and compiled directly into the firmware image 🧱
  • CL1: devices have explicit configuration objects. However, changes require a restart of the device to take effect 🔁
  • CL2: devices allow management systems to replace the entire configuration (or predetermined subsets) in bulk. Configuration changes take effect by soft-restarts of the system (or subsystems) 📦
  • CL3: devices allow management systems to modify configuration objects without bulk replacements, and changes take effect immediately ⚡
  • CL4: devices support multiple configuration datastores, and they might distinguish between the currently running and the next startup configuration 🗂️
  • CL5: devices support configuration datastore locking and device-local configuration change transactions. In other words, either all configuration changes are applied or none of them are 🔒
  • CL6: devices support configuration change transactions across devices 🌈

this document also defines a classification of devices with regard to different levels of monitoring support. In general, a device may be in several of the levels listed below 👀

  • ML0: devices push predefined monitoring data 📤
  • ML1: devices allow management systems to pull predefined monitoring data 📥
  • ML2: devices allow management systems to pull user-defined filtered subsets of monitoring data 🎯
  • ML3: devices are able to locally process monitoring data in order to detect threshold crossings or to aggregate data 🧮

at the time of this writing, constrained devices often implement a combination of one of CL0-CL2 with one of ML0-ML1 💖

2. Problem Statement 💅

okay so the "Internet of Things" vocab is still super nascent 🌸 Depending on which network type or layer you're looking at, people use totally different techs and terms. But the common vibe is that "Things" or "Objects" are supposed to have a physical or virtual identity and talk through interfaces. So we need to tell apart the constrained and smart devices that have an IP address from virtual entities like Smart Objects, which can be identified as a resource or a virtual object using a unique identifier. Smart devices also usually have limited memory and CPU power, and they aim to be self-configuring and easy to deploy 🧚

Then the constraints on network nodes mean protocols need a rethink around power consumption, performance, bandwidth consumption, memory, and CPU usage 🔋 So there's a real demand for simpler protocols, energy-efficient communication, less CPU usage, and a smaller memory footprint. Literally the whole vibe is "do more with less" 💖

On the application layer, the IETF is already building protocols like the Constrained Application Protocol (CoAP) [RFC7252] to let constrained devices and networks talk, e.g., for smart energy applications or home automation 🏠 Deploying one of these environments can involve many constrained devices (e.g., smart meters), and in some scenarios that means up to millions 😭 Those devices produce a huge amount of data, and that data needs to be collected, filtered, and preprocessed before diverse services can use it 📊

With that many nodes, you have to think about manageability. That means easy deployment, configuration, and management of networks of constrained devices, as well as the devices themselves. So seamless monitoring and self-configuration of these nodes is becoming more and more imperative 🫶 Self-configuration and self-management are already a reality in the standards of some organizations, such as 3GPP. To introduce self-configuration of smart devices successfully, a device-initiated connection establishment is often required ✨

A simple, efficient application-layer protocol, such as CoAP, is essential for efficient object-to-object communication and information exchange. That exchange should be based on interoperable data models, so diverse application- and management-related data can be exchanged and interpreted 💜

In an ideal world, we'd have just one network management protocol for monitoring, configuration, and exchanging management data, no matter the network type (e.g., smart grid, wireless access, or core network) 🌈 It would also be desirable to derive the basic data models for constrained devices from the core models used today, so functionality gets reused and info flows end-to-end. But current management protocols seem too heavyweight for what constrained devices can handle, and they aren't directly applicable to a network of constrained devices. Plus, the data models for these smart devices still need to be designed 🙈

So far, the IETF hasn't developed any specific technologies for managing constrained devices and the networks they make up. IP-based sensors and constrained devices today, with very limited memory and CPU resources, use application-layer protocols to do simple resource management and monitoring. Honestly, that might be enough for some basic cases, but we need to reconsider network management mechanisms based on the new, changed, and reduced requirements coming from smart devices and their networks. It's questionable whether we can take the same comprehensive approach we use in an IP network and apply it to constrained devices, so managing a network of constrained devices is necessarily simplified and less complex 💅

As Section 1.6 highlights, constrained devices or networks have diverse characteristics that come from their constrainedness, and those characteristics affect the requirements for managing them 🦋 The use cases in [RFC7548] show that requirements on constrained networks are manifold and need to be analyzed from different angles: the design of the management architecture, the selection of the appropriate protocol features, and the specific issues that are new for constrained devices. Examples include careful management of scarce energy resources, the necessity for self-organization and self-management, and implementation considerations for using common communication technologies on constrained hardware efficiently. For an exhaustive list of the issues and requirements that need addressing for managing a network with constrained devices, see Sections 1.6 and 3 🎀

3. Requirements on the Management of Networks with Constrained Devices 🧚

This section is where the requirements live, sorted into management areas in the subsections 🗂️

Quick heads up: the requirements here are pulled out from the context they might show up in. In general, this document does not recommend implementing any subset of the described requirements. It also avoids picking any of them as mandatory to implement. A device might only be able to provide a particular selected set of requirements and might not manage all of them, and on the flip side, a device vendor might choose a specific relevant subset to implement 💖

Every requirement follows the same template, so here's how it's laid out 🌸

  • Req-ID: An ID made of two numbers: a section number showing the topic area, plus a unique three-digit number per section.
  • Title: The title of the requirement.
  • Description: The rationale and description of the requirement.
  • Source: The origin of the requirement and the matching use case or application. For the discussion of referred use cases for constrained management, see [RFC7548].
  • Requirement Type: Either Functional Requirement or Non-functional Requirement. A functional requirement is related to a function or component, so it can be technical details or specific functionality that defines what a system is supposed to accomplish. Non-functional requirements (also known as design constraints or quality requirements) impose implementation-related considerations, such as performance requirements, security, or reliability ✨
  • Device type: The device types that can support this requirement: C0, C1, and/or C2 🎀
  • Priority: How important the requirement is for a particular type of device, rated High, Medium, or Low 🔥 A requirement can be High for a C2 device but Low for a C1 or C0 device, because complex features are in many cases not possible on a C1 device 👑

3.1. Management Architecture/System ✨

Okay bestie, this is where the management architecture gets its vibe check 💅

Req-ID: 1.001

  • Title: Support multiple device classes within a single network
  • Description: Bigger networks are literally a mix of device classes, like constrained mesh endpoints and less constrained routers, all talking to each other 🕸️. So the management architecture has to work for networks with a mix of different device classes, no exceptions. For the official definition of Constrained Device Classes, check Section 3 of [RFC7228] 📚.
  • Source: All use cases
  • Requirement Type: Non-functional Requirement
  • Device type: C1 and/or C2
  • Priority: High

Req-ID: 1.002

  • Title: Management scalability
  • Description: The management architecture must be able to scale with the number of devices involved and run efficiently in any network size and topology 📈. That means the managing entity has to handle huge amounts of device monitoring data, and the management protocol can't be sensitive to the time between two client requests getting shorter. To get good scalability, caching techniques, in-network data aggregation techniques, and hierarchical management models may be used 🧠.
  • Source: General requirement for all use cases to enable large-scale networks
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID: 1.003

  • Title: Hierarchical management
  • Description: We need a way to do hierarchical management 🏗️. That means intermediary management entities on different levels, which can take over responsibility for managing a subhierarchy of the network of constrained devices. These intermediaries can handle management data aggregation for things like high-frequency monitoring data, or provide a caching mechanism for the uplink and downlink communication. Hierarchical management helps management scalability 🫶.
  • Source: Use cases where a large number of devices are deployed with a hierarchical topology
  • Requirement Type: Non-functional Requirement
  • Device type: Managing and intermediary entities
  • Priority: Medium

Req-ID: 1.004

  • Title: Minimize state maintained on constrained devices
  • Description: The amount of state kept on constrained devices should be minimized 🧹. This matters for saving memory (especially for C0 and C1 devices), and it lets devices restart, for example to apply configuration changes or to recover after long stretches of inactivity 🔄.
  • Note: One way to get there is a RESTful architecture that minimizes the state maintained by managed constrained devices and makes a device's resources addressable via URIs 🔗.
  • Source: Basic requirement that concerns all use cases
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID: 1.005

  • Title: Automatic resynchronization with eventual consistency
  • Description: In large-scale networks, some constrained devices may be offline at any given moment 📴. So configuration parameters need to be distributed in a way that allows temporary inconsistencies, but eventually converges to global consistency after a long enough stretch without changes ⏳✨.
  • Source: Use cases with large-scale networks with many devices
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID: 1.006

  • Title: Support for lossy links and unreachable devices
  • Description: Some constrained devices can only handle lossy and unreliable links, with a limited data rate, high latency, and a high transmission error rate 📉. On top of that, constrained devices often duty cycle their radio or the whole device to save energy 🔋. Some classes of devices labeled 'sleepy endpoints' put their network links into a disconnected state for long periods 😴. In all cases, the management system must not assume that constrained devices are always reachable 🙅‍♀️.
  • Source: Basic requirement for networks of constrained devices with unreliable links and constrained devices that sleep to save energy
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID: 1.007

  • Title: Network-wide configuration
  • Description: We need ways to specify the behavior of the network at a higher level of abstraction than per-device configuration information, which is called network-wide configuration 🌐. It's useful to derive the device-specific configuration from the network-wide configuration. A repository like this can be used to configure predefined device or protocol parameters for the whole network. A network-wide view also lets you monitor and manage a group of routers or a whole network. For example, monitoring network performance needs more information than you could get from a single router using a management protocol 📊.
  • Note: Which subset of policies gets provisioned depends on the capabilities of each device, and it can be obtained from a preconfigured data repository 🗂️.
  • Source: In general, all use cases of network and device configuration based on a network view in a top-down manner
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: Medium

Req-ID: 1.008

  • Title: Distributed management
  • Description: We need simple distributed management, where a network of constrained devices can be managed or monitored by more than one manager 👯. Since connectivity to a server can't be guaranteed at all times, a distributed approach may give higher reliability, at the cost of more complexity 🧩. This requirement means handling data consistency when there's concurrent read and write access to the device datastore. It might also happen that no management (configuration) server is accessible and the only reachable node is a peer device. In that case, the device should be able to get its configuration from peer devices 🤝.
  • Source: Use cases where the count of devices to manage is high
  • Requirement Type: Non-functional Requirement
  • Device type: C1 and C2
  • Priority: Medium

3.2. Management Protocols and Data Models 💜

Now let's talk protocols and data models, the part where everything has to fit together like a perfect outfit 👗.

Req-ID: 2.001

  • Title: Modular implementation of management protocols
  • Description: Management protocols should be specified so they allow modular implementations 🧱. That means it should be possible to implement only a basic set of protocol primitives on highly constrained devices, while devices with extra resources may support additional protocol primitives. For a discussion of how much configuration management and monitoring support constrained devices may provide, see Section 1.7 📖.
  • Source: Basic requirement interesting for all use cases
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID: 2.002

  • Title: Compact encoding of management data
  • Description: Management data should be encoded compactly and efficiently, so messages stay small 📦.
  • Source: General requirement to save memory for the receiver buffer and on-air bandwidth
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID: 2.003

  • Title: Compression of management data or complete messages
  • Description: Management data exchanges can be optimized even more with data compression or delta encoding techniques 🗜️. Compression usually needs extra code size, some extra buffers, and/or maintaining some additional state information. For C0 devices, compression may not be feasible 🙃.
  • Source: Use cases where it's beneficial to reduce transmission time and bandwidth, e.g., mobile applications that require saving on-air bandwidth
  • Requirement Type: Functional Requirement
  • Device type: C1 and C2
  • Priority: Medium

Req-ID: 2.004

  • Title: Mapping of management protocol interactions
  • Description: It's desirable to have a lossless automated mapping between the management protocol used to manage constrained devices and the management protocols used to manage regular devices 🔁. In the ideal case, the same core management protocol can be used, with certain restrictions that account for the resource limitations of constrained devices. However, for very resource-constrained devices, this goal might not be achievable 😬.
  • Source: Use cases where high-frequency interaction with the management system of an unconstrained network is required
  • Requirement Type: Functional Requirement
  • Device type: C1 and C2
  • Priority: Medium

Req-ID: 2.005

  • Title: Consistency of data models with the underlying information model
  • Description: The data models used by the management protocol must be consistent with the information model used to define data models for unconstrained networks 🧬. This is essential for integrating the management of constrained networks with the management of unconstrained networks. Using an underlying information model for future data model design enables further top-down model design and model reuse, as well as data interoperability (i.e., exchange of management information between the constrained and unconstrained networks) 🤓. This is a strong requirement, even though the underlying information models are often not explicitly documented in the IETF 💪.
  • Source: General requirement to support data interoperability, consistency, and model reuse
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID: 2.006

  • Title: Lossless mapping of management data models
  • Description: It's desirable to have a lossless automated mapping between the management data models used to manage regular devices and the ones used for managing constrained devices 🗺️. In the ideal case, the same core data models can be used with certain restrictions that account for the resource limitations of constrained devices. However, for very resource-constrained devices, this goal might not be achievable 🥲.
  • Source: Use cases where consistent data exchange with the management system of an unconstrained network is required
  • Requirement Type: Functional Requirement
  • Device type: C2
  • Priority: Medium

Req-ID: 2.007

  • Title: Protocol extensibility
  • Description: The management protocol needs ways to be extended, meaning new protocol messages or mechanisms that can handle changing requirements on supported message and data types effectively 🔧. This has to happen without causing interoperability problems or forcing anyone to replace or update a large number of deployed devices 🙌.
  • Source: Basic requirement useful for all use cases
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

3.3. Configuration Management ⚙️

Okay bestie, this section is all about configuration, and the big idea is that the device does the work itself. 🎀

  • Req-ID: 3.001
  • Title: Self-configuration capability
  • Description: Okay so this one is about devices configuring and reconfiguring themselves automatically, no manual intervention needed 🦋 In traditional management, the management application is the boss that configures every device. With autoconfiguration, the device is the active one and kicks off the whole process itself. Self-configuration can happen during the initial setup or later, whenever the configuration data needs a refresh. It also needs to work during initialization or after failures, when the device doesn't know the network topology ahead of time or the topology is unclear. Main character plug&play energy ✨
  • Source: Basically every use case that needs easy deployment and plug&play behavior, plus easy upkeep for lots of constrained devices 💖
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High for device categories C0 and C1; Medium for C2
  • Req-ID: 3.002
  • Title: Capability discovery
  • Description: Here we want devices to be able to discover which optional management capabilities they support, and then show that info through at least one protocol and/or data model 🔍 It's giving "tell me what you can do, boo" 💅
  • Source: Use cases where how a device talks to other devices or apps depends on how many of its capabilities are supported 🌸
  • Requirement Type: Functional Requirement
  • Device type: C1 and C2
  • Priority: Medium
  • Req-ID: 3.003
  • Title: Asynchronous transaction support
  • Description: Config management should support asynchronous, event-driven transactions 🔔 Configuration operations should follow a transactional model, and the device should send asynchronous indications saying the transaction was completed. Reliability queen behavior 👑
  • Source: Use cases that need transaction-style processing because of reliability or distributed architecture requirements 🧚
  • Requirement Type: Functional Requirement
  • Device type: C1 and C2
  • Priority: Medium
  • Req-ID: 3.004
  • Title: Network reconfiguration
  • Description: Okay, this one is the network glow-up arc 🌈 We want a way to iteratively reconfigure the network so it can recover from node and communication failures. The reconfiguration can be failure-driven and self-initiated (automatic reconfiguration). It can also run across the whole hierarchical structure of a network (network topology). Comeback era, literally 🦋
  • Source: Pretty much every use case, because network connectivity is a basic need 💜
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: Medium

3.4. Monitoring Functionality 👀

Monitoring is giving "I'm always watching, but make it caring" 🫶 Here's how the requirements spill the tea.

  • Req-ID: 4.001
  • Title: Device status monitoring
  • Description: Provide a monitoring function that collects and exposes info about device status through at least one management interface 📊 The device monitoring can use hierarchical management through intermediary entities and the caching mechanism. It can also use neighbor-monitoring (fault detection in the local network) for fast fault detection and recovery. Like, if a managing entity can't be reached, a neighbor can take over the monitoring job 🤝
  • Source: All use cases 💖
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High; Medium for neighbor-monitoring
  • Req-ID: 4.002
  • Title: Energy status monitoring
  • Description: Collect and expose info about the device's energy parameters and usage, like battery level and average power consumption 🔋 Keeping tabs on the power situation is so important, bestie ⚡
  • Source: Use case "Energy Management" 🍓
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High for energy reporting devices; Low for others
  • Req-ID: 4.003
  • Title: Monitoring of current and estimated device availability
  • Description: Collect and expose info about what the device has available right now (energy, memory, computing power, forwarding-plane utilization, queue buffers, etc.), plus an estimate of how much of those resources will be left 🧮 Predicting the future like a whole psychic 🔮
  • Source: All use cases. Also, monitoring energy resources (like battery status) may be needed on all kinds of devices 🔥
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: Medium
  • Req-ID: 4.004
  • Title: Network status monitoring
  • Description: Collect, analyze, and expose info about the status of a network or network segments connected to the device's interface 🌐 Analysis is the whole vibe here 🧐
  • Source: All use cases 🦋
  • Requirement Type: Functional Requirement
  • Device type: C1 and C2
  • Priority: Low, based on the realization complexity
  • Req-ID: 4.005
  • Title: Self-monitoring
  • Description: Give the device self-monitoring (local fault detection) so it can spot faults fast and recover fast 🩹 Self-healing is a whole mood 💪
  • Source: Use cases where devices can't be monitored centrally in an appropriate way, for example when self-healing is required 🌸
  • Requirement Type: Functional Requirement
  • Device type: C1 and C2
  • Priority: High for C2; Medium for C1
  • Req-ID: 4.006
  • Title: Performance monitoring
  • Description: The device provides a monitoring function that collects and exposes info about its basic performance parameters 📈 Performance management can also use hierarchical management through intermediary devices. Not the flashiest requirement, but it's giving steady and reliable 💅
  • Source: Use cases "Building Automation" and "Transport Applications" 🚌
  • Requirement Type: Functional Requirement
  • Device type: C1 and C2
  • Priority: Low
  • Req-ID: 4.007
  • Title: Fault detection monitoring
  • Description: The device provides fault detection monitoring 🚨 The system collects info about network states so it can figure out whether faults have happened. Sometimes detecting faults means processing and analyzing parameters pulled from the network or other devices. For C0 devices, the monitoring can be limited to checking whether the device is alive or not. Are you alive? Yes? Ok, slay 💀
  • Source: Use cases "Environmental Monitoring", "Building Automation", "Energy Management", "Infrastructure Monitoring" 🌿
  • Requirement Type: Functional Requirement
  • Device type: C0, C1 and C2
  • Priority: Medium
  • Req-ID: 4.008
  • Title: Passive and reactive monitoring
  • Description: The device provides passive and reactive monitoring 👀 The system or manager collects info about device components and network states (that's passive monitoring) and can do postmortem analysis of the collected data. When events of interest happen, the system or manager can adaptively react (that's reactive monitoring), for example by reconfiguring the network. Usually, the reactions are executed or sent as commands by the management applications. Action figure energy 🎬
  • Source: Diverse use cases relevant for device status and network state monitoring 🧚
  • Requirement Type: Functional Requirement
  • Device type: C2
  • Priority: Medium
  • Req-ID: 4.009
  • Title: Recovery
  • Description: Provide local, central, and hierarchical recovery mechanisms 🩷 Sometimes recovery means recovering the whole network of constrained devices. Rebuilding the whole squad, bestie 🫂
  • Source: Use cases "Industrial Applications", "Home Automation", and "Building Automation", plus mobile applications that involve different forms of clustering or area managers 🏠
  • Requirement Type: Functional Requirement
  • Device type: C2
  • Priority: Medium
  • Req-ID: 4.010
  • Title: Network topology discovery
  • Description: Provide a network topology discovery capability (for example, topology extraction algorithms that retrieve the network state) and a monitoring function that collects and exposes info about the network topology 🗺️ Mapping the whole vibe, iykyk 🧭
  • Source: Use cases "Community Network Applications" and mobile applications 🌈
  • Requirement Type: Functional Requirement
  • Device type: C1 and C2
  • Priority: Low, based on the realization complexity
  • Req-ID: 4.011
  • Title: Notifications
  • Description: The device can send notifications about critical events and faults 📣 Alerting the group chat when something's wrong is literally the most important job 🚩
  • Source: All use cases ✨
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: Medium for C2; Low for C0 and C1
  • Req-ID: 4.012
  • Title: Logging
  • Description: The device can build, keep, and let people retrieve logs of events (including but not limited to critical faults and alarms) 📒 The receipts are always saved, bestie 🧾
  • Source: Use cases "Industrial Applications", "Building Automation", and "Infrastructure Monitoring" 🏭
  • Requirement Type: Functional Requirement
  • Device type: C2
  • Priority: High for some medical or industrial applications; Medium otherwise

3.5. Self-Management 🪞

Last but not least, self-management is the ultimate self-care era 🧖‍♀️💖

  • Req-ID: 5.001
  • Title: Self-management -- Self-healing
  • Description: Enable event-driven and/or periodic self-management in a device 🔄 The device should be able to react when something fails, for example by doing a full or partial reset, and then start a self-configuration or management data update if needed. The device can also check for failures cyclically or on a schedule, so it can trigger self-management when necessary ⏰ How much self-management a C1 device can handle is a matter of device design and is up for discussion 🗣️ Failure detection and self-management logic are assumed to be generally useful for a device's self-healing 🩹 Healing arc unlocked, periodt 💅
  • Source: This relates to all use cases in this document 🌟
  • Requirement Type: Functional Requirement
  • Device type: C1 and C2
  • Priority: High for C2; Medium for C1

3.6. Security and Access Control 🔐

Okay, security is literally the main character of this whole section, so let's get into it 💅

Req-ID 6.001 🛡️

  • Title: Authentication of management system and devices
  • Description: Systems with a management role need to be properly authenticated to the device so the device can handle access control properly and tell the real management systems apart from rogue ones. The reverse is true too: managed devices must authenticate themselves to systems with a management role, so management systems can protect themselves from rogue devices. Also, in some setups a bunch of devices might all (re-)start at about the same time. Protocols and authentication systems should be designed so that a large number of devices restarting at once doesn't mess with the device authentication process 😭
  • Source: Basic security requirement for all use cases
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High; Medium for the (re-)start of a large number of devices

Req-ID 6.002 🔑

  • Title: Support suitable security bootstrapping mechanisms
  • Description: Mechanisms should be supported that make bootstrapping easier, which basically means discovering newly deployed devices so they can be given the right access control permissions. Bestie, this is the "hello, who are you?" moment for brand-new devices 🫶
  • Source: Basic security requirement for all use cases
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID 6.003 🚪

  • Title: Access control on management system and devices
  • Description: Systems acting in a management role must provide an access control mechanism that lets the security administrator restrict which devices can access the managing system, for example with an access control white list of known devices. On the flip side, managed constrained devices must provide an access control mechanism that lets the security administrator restrict how systems in a management role can access the device, such as no-access, read-only access, and read-write access. Gatekeeping, but make it iconic ✨
  • Source: Basic security requirement for use cases where access control is essential
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID 6.004 🧮

  • Title: Select cryptographic algorithms that are efficient in both code space and execution time
  • Description: Cryptographic algorithms hit hard on both code size and overall execution time, so it is necessary to select the mandatory-to-implement algorithms that are reasonable to build with the available code space and that have a small runtime impact. Some wireless technologies, like IEEE 802.15.4, require support for certain cryptographic algorithms, so it might be useful to pick algorithms that are likely to be supported in the wireless chipsets for those technologies. Efficiency is a whole personality 💜
  • Source: Generic requirement to reduce the footprint and CPU usage of a constrained device
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High; Medium for hardware-supported algorithms

3.7. Energy Management 🔋

Okay, energy is giving "don't let the battery die on the group chat" energy, and this section is all about keeping things alive 🫠

Req-ID 7.001 ⚡

  • Title: Management of energy resources
  • Description: Enable managing power resources in the network. For example, reduce the sampling rate of nodes with a critical battery, reduce node transmission power, put nodes to sleep, put single interfaces to sleep, or reject a management job based on the available energy or on criteria predefined by the management application. Importance levels can force a job to run even when the energy level is low. The device may further implement standard data models for energy management and expose them through a management protocol interface, such as the EMAN MIB modules [RFC7460] and [RFC7461] as well as other EMAN extensions. It might be necessary to use a subset of EMAN MIBs for C1 and C2 devices.
  • Source: Use case "Energy Management"
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: Medium for the use case "Energy Management"; Low otherwise

Req-ID 7.002 📡

  • Title: Support of energy-optimized communication protocols
  • Description: Use an optimized communication protocol to minimize energy usage for the device's radio receiver and transmitter, on-air bandwidth usage (so, maximize protocol efficiency), and the amount of data communicated between nodes. Minimizing data communication implies data aggregation and filtering, but also a compact format for the transferred data. Small and efficient is the whole vibe 🌸
  • Source: Use cases "Energy Management" and mobile applications
  • Requirement Type: Non-functional Requirement
  • Device type: C2
  • Priority: Medium

Req-ID 7.003 🧷

  • Title: Support for Layer 2 (L2) energy-aware protocols
  • Description: The device will support L2 energy-management protocols, such as energy-efficient Ethernet [IEEE802.3az], and will be able to report on these.
  • Source: Use case "Energy Management"
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: Medium

Req-ID 7.004 💀

  • Title: Dying gasp
  • Description: When energy resources drop below the red-line level, the device will send a "dying gasp" notification and, if still possible, perform a graceful shutdown that includes conserving critical device configuration and status information.
  • Source: Use case "Energy Management"
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: Medium
Okay, the device literally sends a "dying gasp" before it goes, and that's the most dramatic exit 😭 It still tries to save its important config and status first. Respect 🫡

3.8. Software Distribution 📦

Software distribution is basically group chat planning, but for a whole fleet of devices 🧚

Req-ID 8.001 🎀

  • Title: Group-based provisioning
  • Description: Support group-based provisioning, meaning firmware update and configuration management for a large set of constrained devices with eventual consistency and coordinated reload times. The device should accept group-based configuration management based on bulk commands, which aim to make similar configurations for a large set of constrained devices of the same type in a given group, and which may share a common data model. Activating a configuration may be based on preloaded sets of default values. Everyone gets the same glow-up at the same time, periodt ✨
  • Source: All use cases
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: Medium

3.9. Traffic Management 🚦

Traffic management is the part where we keep the network from getting totally clogged, which is so important when everyone is talking at once 🙈

Req-ID 9.001 🌊

  • Title: Congestion avoidance
  • Description: Support congestion control principles as defined in [RFC2914]. For example, the ability to avoid congestion by modifying the device's reporting rate for periodic data, which is usually redundant, based on the importance and reliability level of the management data. This is usually controlled by the managing entity, which marks the data as important or relevant for reliability. However, a device can also initiate reducing its reporting rate itself if it detects congestion or has insufficient buffer memory.
  • Source: Use cases with high reporting rate and traffic, e.g., AMI or M2M
  • Requirement Type: Non-functional Requirement
  • Device type: C1 and C2
  • Priority: Medium

Req-ID 9.002 🔀

  • Title: Reroute traffic
  • Description: Provide the ability for network nodes to redirect traffic away from overloaded intermediary nodes in a network and onto another path. This prevents congestion on a central server and in the primary network. Rerouting is the detour that saves the day 🗺️
  • Source: Use cases with high reporting rate and traffic, e.g., AMI or M2M
  • Requirement Type: Non-functional Requirement
  • Device type: Intermediary entity in the network
  • Priority: Medium

Req-ID 9.003 🧘

  • Title: Traffic Shaping
  • Description: Provide the ability to apply traffic-shaping policies to incoming and outgoing links on an overloaded intermediary node, as necessary, to reduce the amount of traffic in the network. Calm the traffic down, bestie, we're all trying to vibe 🌈
  • Source: Use cases with high reporting rate and traffic, e.g., AMI or M2M
  • Requirement Type: Non-functional Requirement
  • Device type: Intermediary entity in the network
  • Priority: Medium

3.10. Transport Layer 🚚

The transport layer is where messages actually get delivered, so this part is the delivery driver with main character energy 💜

Req-ID 10.001 🌐

  • Title: Scalable transport layer
  • Description: Enable the use of a scalable transport layer, meaning one that isn't sensitive to a high rate of incoming client requests. This is useful for applications that need frequent access to device data. It can handle a lot of people at the door without falling over 🫶
  • Source: Applications with frequent access to the device data
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1 and C2
  • Priority: Medium

Req-ID 10.002 📬

  • Title: Reliable unicast transport of messages
  • Description: Diverse applications need reliable message transport. Reliability might be achieved with a transport protocol such as TCP, or it can be supported by message repetition if an acknowledgment is missing. Reliability is the most reliable kind of friend 💖
  • Source: Generally, applications benefit from the reliability of the message transport
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

Req-ID 10.003 📣

  • Title: Best-effort multicast
  • Description: Provide best-effort multicast of messages. This is generally useful when devices need to discover a service provided by a server, or when many devices need to be configured by a managing entity at once based on the same data model. It's the group announcement of the network 📢
  • Source: Use cases where a device needs to discover services as well as use cases with high amount of devices to manage, which are hierarchically deployed, e.g., AMI or M2M
  • Requirement Type: Functional Requirement
  • Device type: C0, C1, and C2
  • Priority: Medium

Req-ID 10.004 🔒

  • Title: Secure message transport
  • Description: Enable secure message transport that provides authentication, data integrity, and confidentiality by using existing transport-layer technologies with a small footprint, such as TLS/DTLS. Security with a light backpack, and we are obsessed 🧚
  • Source: All use cases
  • Requirement Type: Non-functional Requirements
  • Device type: C1 and C2
  • Priority: High

3.11. Implementation Requirements ✨

  • Req-ID: 11.001
  • Title: Avoid complex application-layer transactions requiring large application-layer messages
  • Description: Okay, so big, complicated application-layer transactions usually need huge memory buffers. C0 and C1 devices basically never have those, and C2 devices only manage by cutting features. And if one giant transaction fails, you have to redo the whole thing from scratch 😭. On constrained devices it's way better to split a big transaction into a sequence of smaller ones. Each little step needs fewer resources and still gets things done, one bite at a time 🍓.
  • Source: Basic requirement that concerns all use cases with memory constrained devices
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High
  • Req-ID: 11.002
  • Title: Avoid reassembly of messages at multiple layers in the protocol stack
  • Description: Reassembling messages at several layers in the protocol stack means every one of those layers needs its own buffer, and that's a seriously wasteful use of memory 💀. The fix is for the application layer, the security layer, the transport layer, the IPv6 layer, and any adaptation layers to all know about each other's limits, so nobody fragments and reassembles stuff they don't have to 🦋. Also, message size limits need to be announced to protocol peers, so they can adjust and stop sending messages the receiving device can't process because it's out of resources. Main character energy is knowing your own limits and telling everyone else ✨.
  • Source: Basic requirement that concerns all use cases with memory constrained devices
  • Requirement Type: Non-functional Requirement
  • Device type: C0, C1, and C2
  • Priority: High

4. Security Considerations 🔐

Okay, bestie, this document is about the problem statement and the requirements for networks of constrained devices. Section 1.6 lists a bunch of limitations that could stop you from implementing strong cryptographic algorithms 🙈. The security and access control requirements live in Section 3.6.

Constrained devices are often deployed in unsafe places where attackers can get physical access to them. So it's crucial that devices are robust and tamper resistant 🛡️, have no backdoors, don't offer services that aren't essential for their main job, and properly protect any security credentials stored on the device (for example, with hardware protection mechanisms). It's also important that credentials leaking from one device don't make it easier to attack other, similar devices. Security credentials should never be shared, full stop 💅.

Since constrained devices often have limited computing power, you have to be careful about choosing algorithms that are efficient but still cryptographically strong ⚡. Designers of constrained devices with a long expected lifetime need to make sure cryptographic algorithms can be updated after the devices are deployed 🔄. Being able to do secure firmware and software updates is an important management requirement, no debate.

Constrained devices might also generate sensitive data or have to process it. That's why it's an important requirement to properly protect access to that data, to protect the privacy of the humans using these Internet-enabled devices 🫶. For some kinds of data, protecting it while it's being transmitted over the network might not be enough. Methods should be investigated that protect data while it's cached or stored too, for example when using a store-and-forward transport mechanism 📦.

5. Informative References 📚

[RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
           RFC 2914, DOI 10.17487/RFC2914, September 2000,
           <http://www.rfc-editor.org/info/rfc2914>.

[RFC2501]  Corson, S. and J. Macker, "Mobile Ad hoc Networking
           (MANET): Routing Protocol Performance Issues and
           Evaluation Considerations", RFC 2501,
           DOI 10.17487/RFC2501, January 1999,
           <http://www.rfc-editor.org/info/rfc2501>.

[RFC6632]  Ersue, M., Ed. and B. Claise, "An Overview of the IETF
           Network Management Standards", RFC 6632,
           DOI 10.17487/RFC6632, June 2012,
           <http://www.rfc-editor.org/info/rfc6632>.

[RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
           Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
           2014, <http://www.rfc-editor.org/info/rfc7102>.

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

[RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
           Application Protocol (CoAP)", RFC 7252,
           DOI 10.17487/RFC7252, June 2014,
           <http://www.rfc-editor.org/info/rfc7252>.

[RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
           over Low-Power Wireless Personal Area Networks (6LoWPANs):
           Overview, Assumptions, Problem Statement, and Goals",
           RFC 4919, DOI 10.17487/RFC4919, August 2007,
           <http://www.rfc-editor.org/info/rfc4919>.

[RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
           Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
           JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
           Low-Power and Lossy Networks", RFC 6550,
           DOI 10.17487/RFC6550, March 2012,
           <http://www.rfc-editor.org/info/rfc6550>.

[RFC7460]  Chandramouli, M., Claise, B., Schoening, B., Quittek, J.,
           and T. Dietz, "Monitoring and Control MIB for Power and
           Energy", RFC 7460, DOI 10.17487/RFC7460, March 2015,
           <http://www.rfc-editor.org/info/rfc7460>.

[RFC7461]  Parello, J., Claise, B., and M. Chandramouli, "Energy
           Object Context MIB", RFC 7461, DOI 10.17487/RFC7461, March
           2015, <http://www.rfc-editor.org/info/rfc7461>.

[RFC7548]  Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A.
           Sehgal, "Management of Networks with Constrained Devices:
           Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015,
           <http://www.rfc-editor.org/info/rfc7548>.

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

[IEEE802.15.1]
           IEEE, "Part 15.1: Wireless medium access control (MAC) and
           physical layer (PHY) specifications for wireless personal
           area networks (WPANs)", IEEE Standard 802.15.1, June 2005,
           <https://standards.ieee.org/about/get/802/802.15.html>.

[IEEE802.3az]
           IEEE, "ETHERNET", IEEE Standard 802.3az, 2012-2014,
           <https://standards.ieee.org/about/get/802/802.3.html>.

Acknowledgments 🌸

The following reviewed and provided valuable comments during the creation of this document:

Dominique Barthel, Andy Bierman, Carsten Bormann, Zhen Cao, Benoit Claise, Hui Deng, Bert Greevenbosch, Joel M. Halpern, Ulrich Herberg, James Nguyen, Anuj Sehgal, Zach Shelby, Peter van der Stok, Thomas Watteyne, and Bert Wijnen. 🫶

The authors would like to thank the reviewers and the participants on the Coman and OPSAWG mailing lists for their valuable contributions and comments 💜.

Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme. 🌈

Authors' Addresses 💌

Mehmet Ersue (editor)
Nokia Networks

EMail: mehmet.ersue@nokia.com


Dan Romascanu
Avaya

EMail: dromasca@avaya.com


Juergen Schoenwaelder
Jacobs University Bremen

EMail: j.schoenwaelder@jacobs-university.de


Ulrich Herberg

EMail: ulrich@herberg.name
📦 where this page comes from