What makes a device constrained
RFC 7228, the IETF’s terminology document for constrained-node networks, defines a constrained node by contrast with ordinary internet hosts. It is a node where some characteristics that are “pretty much taken for granted for Internet nodes” are not attainable, often because of cost and physical limits such as size, weight and available power. The RFC adds that “constrained device” is an alternative term when the device’s role as a network node is not the focus.
The constraints come in several forms, often together:
- Code space, the flash or ROM that holds the program.
- State and buffers, the RAM available while it runs.
- Processing, how much computation fits in a period of time.
- Power, how much energy it can draw and for how long.
- User interface and access, including the ability to set keys or update software once deployed.
The RFC is open that this is “not a rigorous definition”. It describes a design condition: tight limits lead to hard upper bounds on state, code and processing cycles, which make saving energy and network bandwidth a dominant concern in every design decision.
The device classes
To give the idea some shape, RFC 7228 names three classes by data size (RAM) and code size (flash). It calls them “rough indications of device capabilities”, where KiB means 1,024 bytes.
| Class | Data size (e.g., RAM) | Code size (e.g., flash) | What RFC 7228 says it can do |
|---|---|---|---|
| Class 0, C0 | << 10 KiB | << 100 KiB | Very constrained, sensor-like motes that will most likely reach the internet only with help from larger devices acting as proxies, gateways or servers |
| Class 1, C1 | ~ 10 KiB | ~ 100 KiB | Cannot easily run a full stack such as HTTP and TLS, but can use protocols designed for constrained nodes, such as CoAP over UDP, and support the security functions a large network needs |
| Class 2, C2 | ~ 50 KiB | ~ 250 KiB | Fundamentally capable of most of the protocol stacks used on notebooks or servers, though it can still benefit from lightweight protocols |
The table dates from May 2014, and the RFC expected the boundaries to move. It also observed that gains in chip density tend to go into lower cost and power rather than more computing power, so embedded parts do not grow the way personal computers do. A revision in progress at the IETF, draft-ietf-iotops-7228bis, keeps these three classes and adds Class 3 and Class 4 for larger microcontrollers, plus classes for general-purpose devices running operating systems such as Linux. It is an Internet-Draft, not yet an RFC.
The Constrained Application Protocol (CoAP), in RFC 7252, is an example of a protocol written for this space: a web transfer protocol for constrained nodes and constrained networks.
Energy is a separate limit
Memory class says nothing about the battery. RFC 7228 describes energy limits separately:
- E0, limited per event, such as an energy-harvesting light switch powered by a button press.
- E1, limited per period, such as a battery that is recharged or replaced on a schedule.
- E2, limited over the device’s lifetime, such as a non-replaceable primary battery.
- E9, no direct limit, such as a mains-powered device.
It also names three strategies for using power to communicate. A normally-off device (P0) sleeps and reattaches to the network when it wakes. A low-power device (P1) appears connected, perhaps with high latency, by switching components on and off in a regular cycle. An always-on device (P9) stays connected. The RFC notes that with wireless links, the radio often consumes a big portion of the device’s total energy, which is why batching transmissions matters on these devices.
Constrained networks
The links can be as limited as the devices. RFC 7228 defines a constrained network by the link-layer characteristics it lacks, listing low throughput (including limits on duty cycle), high and variable packet loss, asymmetric links, heavy penalties for larger packets, devices that are reachable only when they wake, and little or no multicast. Some of these limits are regulatory, such as limited spectrum and caps on radiated power and duty cycle.
What changes when you design for one
Designing for a constrained device involves deciding what the device will not do. The RFC notes that a Class 1 device may support only a few selected functions, and that devices with similar constraints may choose different ones. Common consequences:
- Push heavy work to a bigger device. Class 0 devices rely on proxies and gateways. The same split appears in security protocols. In Offline Protocol,
offline-protocol-leafis a firmware component that takes part in MLS as a member that never issues commits, while a full peer such as a phone sets up the session; two leaves cannot set one up with each other. - Budget memory before choosing protocols. Encryption, buffers and protocol state all compete for the same RAM and flash, covered in how much memory encryption needs on a microcontroller.
- Plan updates from the start. RFC 9019, the IETF firmware update architecture, was informed by Class 1 devices, and updates are harder still with no network, as explained in updating firmware without internet.
- Protect keys on hardware an attacker can hold. A device left in the field can be opened, which is one reason to use a secure element.
Whether such a device can run end-to-end encryption at all is covered in can a microcontroller run encrypted mesh messaging.