]> Terminology for Constrained-Node Networks Universität Bremen TZI
Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org
Munich Germany mersue@gmail.com
Ericsson
Hirsalantie 11 Jorvas 02420 Finland ari.keranen@ericsson.com
Universitat Politecnica de Catalunya
C/Esteve Terradas, 7 Castelldefels 08860 Spain +34-93-413-7206 carlesgo@entel.upc.edu
Internet IOTOPS Working Group The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in research and standardization work for constrained-node networks. This document obsoletes RFC 7228. About This Document Status information for this document may be found at . Discussion of this document takes place on the IOT Operations (iotops) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction Small devices with limited CPU, memory, and power resources, so-called "constrained devices" (often used as sensors/actuators, smart objects, or smart devices) can form a network, becoming "constrained nodes" in that network. Such a network may itself exhibit constraints, e.g., with unreliable or lossy channels, limited and unpredictable bandwidth, and a highly dynamic topology. Constrained devices might be in charge of gathering information in diverse settings, including natural ecosystems, buildings, and factories, and of sending the information to one or more server stations. They might also act on information, by performing some physical action, including displaying it. Constrained devices may work under severe resource constraints such as limited electrical and computing power, little memory, and insufficient wireless bandwidth and ability to communicate; these constraints often exacerbate each other. Other entities on the network, e.g., a base station or controlling server, might have more computational and communication resources and could support the interaction between the constrained devices and applications in more traditional networks. Today, constrained devices with different resources and capabilities are becoming connected. Mobile personal gadgets, building-automation devices, cellular phones, machine-to-machine (M2M) devices, and other devices benefit from interacting with other "things" nearby or somewhere in the Internet. With this, the Internet of Things (IoT) became a reality, built up out of uniquely identifiable and addressable objects (things). The present document provides a number of basic terms that have been useful in research and standardization work for constrained environments. The intention is not to exhaustively cover the field but to make sure a few core terms are used consistently between different groups cooperating in this space. The present document is a revision of , updated to the situation a dozen years later, adding useful terminology, and with new sections and subsections discussing classes of specific characteristics. See for a slightly more detailed list of changes.
Conventions Used in this Document In this document, the term "byte" is used in its now customary sense as a synonym for "octet". Where sizes of semiconductor memory are given, the prefix "kibi" (1024) is combined with "byte" to "kibibyte", abbreviated "KiB", for 1024 bytes or 210 bytes. Similarly, MiB stands for 220 and GiB for 230 bytes. Superscript notation denotes exponentiation. For example, 10 raised to the 100th is notated: 10100, where 10 is the base and 100 is the exponent. In the plain-text rendition of this specification, superscript notation is not available and exponentiation therefore is rendered by the surrogate notation seen here in the plain-text rendition. In computing, the term "power" is often used for the concept of "computing power" or "processing power", as in CPU performance. In this document, the term stands for electrical power unless explicitly stated otherwise. "Mains-powered" is used as a shorthand for being permanently connected to a stable electrical power grid.
Core Terminology There are two important aspects to scaling within the Internet of Things:
  • scaling up Internet technologies to a large number of inexpensive nodes, while
  • scaling down the characteristics of each of these nodes and of the networks being built out of them, to make this massive scaling up economically and physically viable.
The need for scaling down the characteristics of nodes leads to "constrained nodes" ().
Constrained Nodes The term "constrained node" is best defined by contrasting the characteristics of a constrained node with certain widely held expectations on more familiar Internet nodes:
Constrained Node:
A node where some of the characteristics that are otherwise pretty much taken for granted for Internet nodes at the time of writing are not attainable, often due to cost constraints and/or physical constraints on characteristics such as size, weight, and available power and energy. The tight limits on power, memory, and processing resources lead to hard upper bounds on state, code space, and processing cycles, making optimization of energy and network bandwidth usage a dominating consideration in all design requirements. Also, some Layer 2 (L2) services such as full connectivity and broadcast/multicast may be lacking.
While this is not a rigorous definition, it is grounded in the state of the art and clearly sets apart constrained nodes from server systems, desktop or laptop computers, powerful mobile devices such as smartphones, etc. There may be many design considerations that lead to these constraints, including cost, size, weight, and other scaling factors. (An alternative term, when the properties as a network node are not in focus, is "constrained device".) "Unconstrained node" cannot be used as an antonym, as engineering is unable to produce nodes that are literally without constraints. To mark the other end of the constrainedness spectrum, the term Capable (as in "capable nodes") has become popular.
Capable Node:
A node that is not subject to the constraints that would make it a "Constrained Node" for the purposes of the discussion this term is used in.
There are multiple facets to the constraints on nodes, which often apply in combination, for example:
  • constraints on the maximum code complexity (ROM/Flash),
  • constraints on the size of state and buffers (RAM),
  • constraints on the amount of computation feasible in a period of time ("processing power"),
  • constraints on the available power and/or total energy,
  • constraints on the security properties and guarantees attainable, and
  • constraints on user interface and accessibility in deployment (ability to set keys, update software, etc.).
Some of these constraints apply to the hardware of the device, others to all or part of a combination of hardware, firmware, and essential infrastructure (the "platform", e.g., in ) and its anticipated usage (e.g., in ). defines a number of interesting classes ("class-N" for a range of numbers N) of constrained nodes focusing on relevant combinations of the first two constraints. With respect to available power, distinguishes "power-affluent" nodes (mains-powered or regularly recharged) from "power-constrained nodes" that draw their power from primary batteries or by using energy harvesting; more detailed power terminology is given in . The use of constrained nodes in networks often also leads to constraints on the networks themselves. However, there may also be constraints on networks that are largely independent of those of the nodes. This document therefore distinguishes "constrained networks" from "constrained-node networks".
Constrained Networks defines some specific classes of networks; the present section continues with some higher-level observations. This document defines "constrained network" in a similar way:
Constrained Network:
A network where some of the characteristics pretty much taken for granted with link layers in common use in the Internet at the time of writing are not attainable.
Constraints may include:
  • low achievable bitrate/throughput, including limits on communication duty cycle (for example, restrictions on transmit airtime or receive availability; see also );
  • high packet loss and high variability of packet loss (or, conversely, delivery rate);
  • highly asymmetric link characteristics;
  • severe penalties for using larger packets (e.g., high packet loss due to link-layer fragmentation);
  • limits on reachability over time (a substantial number of devices may power off at any point in time but periodically "wake up" and can communicate for brief periods of time);
  • unusually high latency or variability of latency, possibly exacerbated by the need for power-off periods or duty-cycling; and
  • lack of (or severe constraints on) advanced services such as IP multicast.
More generally, the term "constrained networks" applies whenever at least some of the nodes involved in the network exhibit these characteristics. Again, there may be several reasons for this:
  • cost constraints on the network,
  • constraints posed by the nodes (for constrained-node networks),
  • physical constraints (e.g., power constraints, environmental constraints, media constraints such as underwater operation, limited spectrum for very high density, electromagnetic compatibility),
  • regulatory constraints, such as very limited spectrum availability (including limits on effective radiated power and duty cycle) or explosion safety, and
  • technology constraints, such as older and lower-speed technologies that are still operational and may need to stay in use for some more time.
Challenged Networks A constrained network is not necessarily a "challenged network" :
Challenged Network:
A network that has serious trouble maintaining what an application would today expect of the end-to-end IP model, e.g., by:
  • not being able to offer end-to-end IP connectivity at all,
  • exhibiting serious interruptions in end-to-end IP connectivity, or
  • exhibiting delay well beyond expectations that transport or higher-level protocols may operate on, such as the Maximum Segment Lifetime (MSL) defined by TCP (Sections and of RFC 9293 ; see also ).
All challenged networks are constrained networks in some sense, but not all constrained networks are challenged networks. There is no well-defined boundary between the two, though. Delay-Tolerant Networking (DTN) has been designed to cope with challenged networks .
Constrained-Node Networks
Constrained-Node Network:
A network whose characteristics are influenced by being composed of a significant portion of constrained nodes.
A constrained-node network always is a constrained network because of the network constraints stemming from the node constraints, but it may also have other constraints that already make it a constrained network. The rest of this subsection introduces additional terms that are in active use in the area of constrained-node networks, without an intent to define them: LLN, (6)LoWPAN, and LPWAN.
LLN A related term that has been used to describe the focus of the IETF Routing Over Low power and Lossy networks (ROLL) working group is "Low-Power and Lossy Network (LLN)". The ROLL terminology document defines LLNs as follows:
LLN: Low-Power and Lossy Network. Typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4 or low-power Wi-Fi. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (heating, ventilation, and air conditioning (HVAC), lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.
Beyond that, LLNs often exhibit considerable loss at the physical layer, with significant variability of the delivery rate, and some short-term unreliability, coupled with some medium-term stability that makes it worthwhile to both (1) construct directed acyclic graphs that are medium-term stable for routing and (2) do measurements on the edges such as Expected Transmission Count (ETX) . Not all LLNs comprise low-power nodes (, definition of "field device" in ). LLNs are typically composed of constrained nodes; this leads to the design of operation modes such as the "non-storing mode" defined by RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks ). So, in the terminology of the present document, an LLN is a constrained-node network with certain network characteristics, which include constraints on the network as well.
LoWPAN, 6LoWPAN One interesting class of a constrained network often used as a constrained-node network is "LoWPAN" , a term inspired from the name of an IEEE 802.15.4 working group (low-rate wireless personal area networks (LR-WPANs)). The expansion of the LoWPAN acronym, "Low-Power Wireless Personal Area Network", contains a hard-to-justify "Personal" that is due to the history of task group naming in IEEE 802 more than due to an orientation of LoWPANs around a single person. Actually, LoWPANs have been suggested for urban monitoring, control of large buildings, and industrial control applications, so the "Personal" can only be considered a vestige. Occasionally, the term is read as "Low-Power Wireless Area Networks" . Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6, "6LoWPAN") also refers to networks built from similarly constrained link-layer technologies .
LPWAN An overview over Low-Power Wide Area Network (LPWAN) technologies is provided by .
Classes of Constrained (and More Capable) Devices Despite the overwhelming variety of Internet-connected devices that can be envisioned, it may be worthwhile to have some succinct terminology for different classes of constrained devices. The following distinguishes two big rough groups of devices based on their CPU capabilities:
  • Microcontroller-class devices (e.g., called "M-Profile" in ). These often (but not always) include RAM and code storage on chip and would struggle to support more powerful general-purpose operating systems, e.g., they do not have a Memory Management Unit (MMU). They use most of their pins for interfaces to application hardware such as digital in/out (the latter often Pulse Width Modulation (PWM)-controllable), ADC/DACs (analog-to-digital and digital-to-analog converters), etc. The term "System on a Chip" (SoC) can be used where this hardware is specialized for an application. These devices often implement complex sleep modes to achieve microwatt- or at least milliwatt-level sustained power usage (compare the related quantity Ps, see ).
  • General-purpose-class devices (e.g., called "A-Profile" in ). These usually have RAM and Flash storage on separate chips (not always separate packages), and offer support for general-purpose operating systems such as Linux, such as by providing an MMU. Many of the pins on the CPU chip are dedicated to interfacing with RAM and other memory. Some general-purpose-class devices integrate some application hardware such as video controllers, these are often also called SoC. While these chips also include sleep modes, they are usually more on the watt side of sustained power usage (Ps).
If the distinction between these groups needs to be made, this document distinguishes "M-group" (microcontroller) from "J-group" (general purpose, J as in "Jeep") devices. In this document, the class designations in may be used as rough indications of device capabilities. Note that the classes from 10 upwards are not really constrained devices in the sense of the previous section; they may still be useful to discuss constraints in larger devices (the designation "lots" in a column means that the characteristic of this column typically no longer poses a strong design constraint). Classes of Constrained (and More Capable) Devices
Group Name data size (e.g., RAM) code size (e.g., Flash) Examples
M Class 0, C0 << 10 KiB << 100 KiB ATtiny
M Class 1, C1 ~ 10 KiB ~ 100 KiB STM32F103CB
M Class 2, C2 ~ 50 KiB ~ 250 KiB STM32F103RC
M Class 3, C3 ~ 100 KiB ~ 500..1000 KiB STM32F103RG
M Class 4, C4 ~ 300..1000 KiB ~ 1000..2000 KiB STM32F745/767
J Class 10, C10 (16..)32..64..128 MiB 4..8..16 MiB OpenWRT routers
J Class 15, C15 0.5..1 GiB (lots) Raspberry PI
J Class 16, C16 1..4 GiB (lots) Smartphones
J Class 17, C17 4..32 GiB (lots) Laptops
J Class 19, C19 (lots) (lots) Servers
As of the writing of this document, these characteristics correspond to distinguishable clusters of commercially available chips and design cores for constrained devices. While it is expected that the boundaries of these classes will move over time, Moore's law tends to be less effective in the embedded space than in personal computing devices: gains made available by increases in transistor count and density are more likely to be invested in reductions of cost and power requirements than into continual increases in computing power. (This effect is less pronounced in the multi-chip J-group architectures; e.g., class 10 usage for OpenWRT has started at 4/16 MiB Flash/RAM, with an early lasting minimum at 4/32, to now requiring 8/64 and recommending 16/128 for modern software releases .) Class 0 devices are very constrained, often tiny sensor nodes or tags. They are so severely constrained in memory and processing capabilities that most likely they will not have the resources required to communicate directly with the Internet in a secure manner (rare heroic, narrowly targeted implementation efforts notwithstanding). Class 0 devices will participate in Internet communications with the help of larger devices acting as proxies, gateways, or servers. Class 0 devices generally cannot be secured or managed comprehensively in the traditional sense. They will most likely be preconfigured (and will rarely be reconfigured, if at all) with a very small data set. For management purposes, they could answer keepalive signals and send on/off or basic health indications. Class 1 devices are quite constrained in code space and processing capabilities, such that they cannot easily talk to other Internet nodes employing a full protocol stack that has not been designed for parsimonious use of resources including code size, such as using original forms of HTTP, Transport Layer Security (TLS) and related security protocols, and XML-based data representations. However, they are capable enough to use a protocol stack specifically designed for constrained nodes (such as the Constrained Application Protocol (CoAP) over UDP ) and participate in meaningful conversations without the help of a gateway node. In particular, they can provide support for the security functions required on a large network. Therefore, they can be integrated as fully developed peers into an IP network, but they need to be frugal with state memory, code space, and often power expenditure for protocol and application usage. Class 2 devices are less constrained and fundamentally capable of supporting most of the same protocol stacks as used on notebooks or servers. However, even these devices can benefit from lightweight and energy-efficient protocols and from consuming less bandwidth. Furthermore, using fewer resources for networking leaves more resources available to applications. Thus, using the protocol stacks defined for more constrained devices on Class 2 devices might reduce development costs and increase the interoperability. Constrained devices with capabilities significantly beyond Class 2 devices exist. They are less demanding from a standards development point of view as they can largely use existing protocols unchanged. The previous version of the present document therefore did not make any attempt to define constrained classes beyond Class 2. These devices, and to a certain extent even J-group devices, can still be constrained by a limited energy supply. Class 3 and 4 devices are less clearly defined than the lower classes; they are even less constrained. In particular Class 4 devices are powerful enough to quite comfortably run, say, JavaScript interpreters, together with more sophisticated network stacks. Additional classes may need to be defined based on protection capabilities, e.g., an MPU (memory protection unit; true MMUs are typically only found in J-group devices). With respect to examining the capabilities of constrained nodes, particularly for Class 1 devices, it is important to understand what type of applications they are able to run and which protocol mechanisms would be most suitable. Because of memory and other limitations, each specific Class 1 device might be able to support only a few selected functions needed for its intended operation. In other words, the set of functions that can actually be supported is not static per device type: devices with similar constraints might choose to support different functions. Even though Class 2 devices have some more functionality available and may be able to provide a more complete set of functions, they still need to be assessed for the type of applications they will be running and the protocol functions they would need. To be able to derive any requirements, the use cases and the involvement of the devices in the application and the operational scenario need to be analyzed. Use cases may combine constrained devices of multiple classes as well as more traditional Internet nodes.
Firmware/Software upgradability Platforms may differ in their firmware or software upgradability. is a first attempt at classifying this. Levels of Software Update Capabilities
Name Firmware/Software upgradability
F0 no (discard for upgrade)
F1 replaceable, out of service during replacement, reboot
F2 patchable during operation, reboot required
F3 patchable during operation, restart not visible externally
F9 app-level upgradability, no reboot required ("hitless")
Isolation Functionality This section discusses the ability of a platform to isolate different software components. The categories listed in are not mutually exclusive. Levels of Isolation Capabilities
Name Isolation functionality
Is0 no isolation
Is1 Boot Lock or Flash Read Lock, until next reboot
Is2 MPU (memory protection unit), at least boundary registers
Is5 MMU with Linux-style kernel/user
Is7 Virtualization-style isolation
Is8 Secure enclave isolation
Secret Shielding Some platforms employ hardware support to establish additional protection from potential attackers for some specific secrets, strongly isolating them from most code (usually in conjunction with secure enclave functionality, see Is8 above). At the time of writing, there is significant ongoing innovation but no agreed common terminology for levels of this "secret shielding". therefore only provides a rough spectrum, starting from Sh0 for no special hardware provisions to maintain secrecy (while assuming that the usual software measures can be applied even to Sh0 platforms ). Sh1 is a catch-all category that indicates that the platform does provide hardware support for secret shielding, so that it is no longer purely a software function to handle secrets such as roots of trust (for example, providing HSM, TPM, or even TEE functionality). Sh9 is aspirational language (for a fully "deluxe" platform); no real hardware is identified by this level. It is left for further study to identify clusters on this spectrum. Rough Levels of Secret Shielding Capabilities
Name Secret shielding functionality
Sh0 no secret shielding
Sh1 some secret shielding
Sh9 comprehensive secret shielding
Power Terminology Devices not only differ in their computing capabilities but also in available power and/or energy. While it is harder to find recognizable clusters in this space, it is still useful to introduce some common terminology.
Scaling Properties The power and/or energy available to a device may vastly differ, from kilowatts to microwatts, from essentially unlimited to hundreds of microjoules. Instead of defining classes or clusters, a simple statement, using the International System of Units (SI units), of an approximate value for one or both of the quantities listed in is used. Quantities Relevant to Power and Energy
Name Definition SI Unit
Ps Sustainable average power available for the device over the time it is functioning W (Watt)
Et Total electrical energy available before the energy source is exhausted J (Joule)
The value of Et may need to be interpreted in conjunction with an indication over which period of time the value is given; see . Some devices enter a "low-power" mode before the energy available in a period is exhausted or even have multiple such steps on the way to exhaustion. For these devices, Ps would need to be given for each of the modes/steps.
Classes of Energy Limitation As discussed above, some devices are limited in available energy as opposed to (or in addition to) being limited in available power. Where no relevant limitations exist with respect to energy, the device is classified as E9. The energy limitation may be in total energy available in the usable lifetime of the device (e.g., a device that is discarded when its non-replaceable primary battery is exhausted), classified as E2. Where the relevant limitation is for a specific period, the device is classified as E1, e.g., a solar-powered device with a limited amount of energy available for the night, a device that is manually connected to a charger and has a period of time between recharges, or a device with a periodic (primary) battery replacement interval. Finally, there may be a limited amount of energy available for a specific event, e.g., for a button press in an energy-harvesting light switch; such devices are classified as E0. Note that, in a sense, many E1 devices are also E2, as the rechargeable battery has a limited number of useful recharging cycles (usually less of a problem with supercapacitors for energy storage). provides a summary of the classifications described above. Classes of Energy Limitation
Name Type of energy limitation Example Power Source
E0 Event energy-limited Event-based harvesting for self-powered sensing
E1 Period energy-limited Battery that is periodically recharged or replaced
E2 Lifetime energy-limited Non-replaceable primary battery
E9 No direct quantitative limitations to available energy Mains-powered
Strategies for Using Power for Communication Especially when wireless transmission is used, the radio often consumes a big portion of the total energy consumed by the device. Design parameters, such as the available spectrum, the desired range, and the bitrate aimed for, influence the power consumed during transmission and reception; the duration of transmission and reception (including potential reception) influence the total energy consumption. Different strategies for power usage and network attachment may be used, based on the type of the energy source (e.g., battery or mains-powered) and the frequency with which a device needs to communicate. The general strategies for power usage can be described as follows:
Always-on:
This strategy is most applicable if there is no reason for intricate measures for power saving. The device can stay on in the usual manner all the time. It may be useful to employ power-friendly hardware or limit the number of wireless transmissions, CPU speeds, and other aspects for general power-saving and cooling needs, but the device can be connected to the network all the time.
Normally-off:
Under this strategy, the device sleeps such long periods at a time that once it wakes up, it makes sense for it to not pretend that it has been connected to the network during sleep: the device reattaches to the network as it is woken up. The main optimization goal is to minimize the effort during the reattachment process and any resulting application communications. If the device sleeps for long periods of time and needs to communicate infrequently, the relative increase in energy expenditure during the fewer reattachment procedures may still fit within the application's power budget.
Low-power:
This strategy is most applicable to devices that need to operate on a very small amount of power but still need to be able to communicate on a relatively frequent basis. This implies that extremely low-power solutions need to be used for the hardware, chosen link-layer mechanisms, and so on. Typically, given the small amount of time between transmissions, despite their sleep state, these devices retain some form of attachment to the network. Techniques used for minimizing power usage for the network communications include minimizing any work from re-establishing communications after waking up and tuning the frequency of communications (including "duty cycling", where components are switched on and off in a regular cycle) and other parameters appropriately.
provides a summary of the strategies described above. Strategies of Using Power for Communication
Name Strategy Ability to communicate
P0 Normally-off Reattach when required
P1 Low-power Appears connected, perhaps with high latency
P9 Always-on Always connected
Note that the discussion above is at the device level; similar considerations can apply at the communications-interface level. This document does not define terminology for the latter. A term often used to describe power-saving approaches is "duty-cycling". This describes all forms of periodically switching off some function, leaving it on only for a certain percentage of time (the "duty cycle"). only distinguishes two levels, defining a Non-Sleepy Node as a node that always remains in a fully powered-on state (always awake) where it has the capability to perform communication (P9) and a Sleepy Node as a node that may sometimes go into a sleep mode (a low-power state to conserve power) and temporarily suspend protocol communication (P0); there is no explicit mention of P1.
Strategies of Keeping Time over Power Events Many applications require a device to keep some concept of time. Time-keeping can be relative to a previous event (last packet received), absolute on a device-specific scale (e.g., last reboot), or absolute on a world-wide scale ("wall-clock time"). Some devices lose the concept of time when going to sleep: after wakeup, they don't know how long they slept. Some others do keep some concept of time during sleep, but not precise enough to use as a basis for keeping absolute time. Some devices have a continuously running source of a reasonably accurate time (often a 32,768 Hz watch crystal). Finally, some devices can keep their concept of time even during a battery change, e.g., by using a backup battery or a supercapacitor to keep powering the real-time clock (RTC). The actual accuracy of time may vary, with errors ranging from tens of percent from on-chip RC (resistor/capacitor) oscillators (not useful for keeping absolute time, but still useful for, e.g., timing out some state) to approximately 10-4 to 10-5 ("watch crystal") of error. More precise timing is available with temperature compensated crystal oscillators (TCXO). Further improvement requires significantly higher power usage, bulk, fragility, and device cost. For instance, oven-controlled crystal oscillators (OCXO) can reach 10-8 accuracy, and Rubidium frequency sources can reach 10-11 over the short term and 10-9 over the long term. A device may need to fire up a more accurate frequency source during wireless communication, this may also allow it to keep more precise time during the period. The various time sources available on the device can be assisted by external time input, e.g., via the network using the NTP protocol . Information from measuring the deviation between external input and local time source can be used to increase the accuracy of maintaining time even during periods of no network use. Errors of the frequency source can be compensated if known (calibrated against a known better source, or even predicted, e.g., in a software TCXO). Even with errors partially compensated, an uncertainty remains, which is the more fundamental characteristic to discuss. Battery solutions may allow the device to keep a wall-clock time during its entire life, or the wall-clock time may need to be reset after a battery change. Even devices that have a battery lasting for their lifetime may not be set to wall-clock time at manufacture time, possibly because the battery is only activated at installation time, when time sources may be questionable or because setting the clock during manufacture is deemed too much effort. Devices that keep a good approximation of wall-clock time during their life may be in a better position to securely validate external time inputs than devices that need to be reset episodically: the latter can possibly be tricked by their environment into accepting a long-past time, for instance with the intent of exploiting expired security assertions such as certificates. See for additional discussion and a strategy for mitigating this. From a practical point of view, devices can be divided at least on the two dimensions proposed in and . Corrections to the local time of a device performed over the network can be used to improve the uncertainty exhibited by these basic device classes. Strategies of Keeping Time over Power Events
Name Type Uncertainty (roughly)
T0 no concept of time infinite
T1 relative time while awake (usually high)
T2 relative time even across sleeps (usually high during sleep)
T3 relative time even across sleeps 10-4 or better
T5 absolute time (e.g., since boot) 10-4 or better
T7 wall-clock time 10-4 or better
T8 wall-clock time 10-5 or better
T9 wall-clock time 10-6 or better (TCXO)
T10 wall-clock time 10-7 or better (OCXO or Rb)
Permanency of Keeping Time
Name Permanency (from type T5 upwards): Uncertainty
TP0 time needs to be reset on certain occasions  
TP1 time needs to be set during installation (possibly reduced...
TP9 reliable time is maintained during lifetime ...by using external input)
Further parameters that can be used to discuss clock quality can be found in .
Classes of Networks
Classes of Link Layer MTU Size Link layer technologies used by constrained devices can be categorized on the basis of link layer MTU size. Depending on this parameter, the fragmentation techniques needed (if any) to support the IPv6 MTU requirement may vary. lists the main classes of link layer MTU size (using "Sx" as an abbreviation for "Size x"). Note that some of these classes have a span of about a (decimal) order of magnitude; this does not mean that there are no interesting transitions within these spans, just that these transitions are dependent on other parameters such as MAC (message authentication code) sizes, the variations of which would split these classes into small, less universally relevant subclasses. The range S10 to S14 is more finely divided here due to transitions resulting from the dominating link layer (15xx, 9216) and network layer protocol (1280) MTUs. In the table, "WiFi" is short for standard WiFi A-MSDU (Aggregate MAC Service Data Unit) values, describing frame aggregation on the link layer. "CAN-FD" is Controller Area Network Flexible Data-Rate (ISO 11898-1), "LoRaWAN" can be expanded as Long Range Wide Area Network, "BLE" is Bluetooth Low Energy, and "RoCE" is RDMA over Converged Ethernet. Classes of Link Layer MTU Size
Name L2 MTU Size (bytes) Example MTU (minus epsilon) 6LoWPAN Fragmentation applicable*?
S0 3 – 12   (often L2 segmentation)
S1 13 – 127 ~80 (IEEE 802.15.4 with security), ~64 (CAN-FD) yes
S2 128 – 255 (S1/S2 variable: LoRaWAN), ~251 (BLE) yes
S3 256 – 575   yes
S4 576 – 1279 576 (9*64), 1006 (RFC 1055 SLIP) yes
S10 ≥ 1280 1280 (5*256) no fragmentation needed
S11 ≥ 1500 1500/1536 (3*512, Ethernet) no fragmentation needed
S12 ≫ 1500, ..2304 2304 (9*256), 2032 (RFC 8163 MS/TP) no fragmentation needed
S13 ≫ 2304, ..4352 4352 (17*256), ~4200 (RoCE), 3839 (WiFi) no fragmentation needed
S14 ≫ 4352, ..9216 9216 (9*1024, Jumbo Ethernet), 7935 (WiFi) no fragmentation needed
S15 ≫ 9216, ..65535 11454 (WiFi), ~16384, ~65535 no fragmentation needed
S19 ≥ 65536 (not practically deployed) no fragmentation needed
* if no link layer fragmentation is available S0 technologies require fragmentation to support the IPv6 MTU requirement. If no link layer fragmentation is available, fragmentation is needed at the adaptation layer below IPv6. However, 6LoWPAN fragmentation cannot be used for these technologies, given the extremely reduced link layer MTU. In this case, lightweight fragmentation formats need to be used (e.g., ). S1 to S4 technologies require fragmentation at the subnetwork level to support the IPv6 MTU requirement. If link layer fragmentation is unavailable or insufficient, fragmentation is needed at the adaptation layer below IPv6. 6LoWPAN fragmentation can be used to carry 1280-byte IPv6 packets over these technologies. S10 or higher technologies do not require fragmentation to support the IPv6 MTU requirement; S12 and above often create islands of higher MTU in a Layer 2 network that may employ Ethernet-inspired MTUs otherwise. S15 and above may need to consider mechanisms beyond, say, CRC-32(c) to provide error protection (and possibly also correction) for larger sizes of packets.
Classes of Internet Integration The term "Internet of Things" is sometimes confusingly used for connected devices that are not actually employing Internet technology. Some devices do use Internet technology, but only use it to exchange packets with a fixed communication partner ("device-to-cloud" scenarios, see also ). More general devices are prepared to communicate with other nodes in the Internet as well. defines the classes of Internet integration level. Classes of Internet Integration Level
Name Internet technology
I0 none (local interconnect only)
I1 device-to-cloud only
I2 device-to-cloud via a local (edge) gateway, mediated internet access
I9 full Internet connectivity supported
Classes of Physical Layer Bit Rate Physical layer technologies used by constrained devices can be categorized on the basis of physical layer (PHY) bit rate. The PHY bit rate class of a technology has important implications with regard to compatibility with existing protocols and mechanisms on the Internet, responsiveness to frame transmissions and need for header compression techniques. lists the classes of PHY bit rate ('Bx' stands for 'Bit rate class x'). Classes of Physical Layer Bitrate
Name PHY bit rate (bit/s) Comment Header compression
B0 < 10 Transmission time of 150-byte frame > TCP MSL indispensable as part of system architecture
B1 10 – 103 Unresponsiveness if human expects reaction to sent frame (frame size ≥ 63 bytes) vital
B2 103 – 106 Responsiveness if human expects reaction to sent frame yields significant performance benefits
B3 > 106   yields limited performance benefits
B0 technologies can lead to very high frame transmission times, which may exceed the time scales assumed by many Internet transport protocols, middleboxes, and applications for retransmission, liveness detection, and state retention. For instance, TCP (Sections and of RFC 9293 ) defines a Maximum Segment Lifetime (MSL), which may not be faithfully implemented everywhere, but can serve as a yardstick for the present section. Many Internet protocols and mechanisms will fail when transmission times, and thus latencies, are greater than such an assumed constant, often with a default value in the same order of magnitude as the TCP MSL, but possibly explicitly configurable (compare MAX_LATENCY in , see also ). For example, B0 technologies lead to a frame transmission time greater than the TCP MSL for a frame size ≥ 150 bytes (= 1200 bits, which at ≤ 10 bit/s need ≥ 120 s = 2 min). B1 technologies offer transmission times which are lower than the TCP MSL (for a frame size greater than 150 bytes). However, transmission times for B1 technologies are still significant if a human expects a reaction to the transmission of a frame. With B1 technologies, the transmission time of a frame greater than 62.5 bytes exceeds 0.5 seconds, i.e., a threshold time beyond which any response or reaction to a frame transmission will appear not to be immediate . B2 technologies do not incur responsiveness problems, but still benefit from using header compression techniques (such as or ) to achieve performance improvements. Over B3 technologies, the relative performance benefits of header compression are low. For example, in a duty-cycled technology offering B3 PHY bit rates, energy consumption decrease due to header compression may be comparable with the energy consumed while in a sleep interval. On the other hand, for B3 PHY bit rates, a human user will not be able to perceive whether header compression has been used or not in a frame transmission.
IANA Considerations This document makes no requests to IANA.
Operational Considerations This document does not define any protocol, as such there are no new operations or manageability requirements introduced by this document.
Security Considerations This document introduces common terminology that does not raise any new security issues. Security considerations arising from the constraints discussed in this document need to be discussed in the context of specific protocols. For instance, , "Constrained node considerations", discusses implications of specific constraints on the security mechanisms employed. provides a security threat analysis for the RPL routing protocol. Implementation considerations for security protocols on constrained nodes are discussed in and in early work in . A wider view of security in constrained-node networks is provided in . discusses Security Considerations for certain platforms that protect multiple execution environments from each other, a capability that can also be used for secret shielding.
Informative References Terminology for Constrained-Node Networks The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. Network Time Protocol Version 4: Protocol and Algorithms Specification The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. Transmission of IPv6 Packets over IEEE 802.15.4 Networks This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK] Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK] SCHC: Generic Framework for Static Context Header Compression and Fragmentation This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. Transmission of SCHC-compressed packets over IEEE 802.15.4 networks UPC Consultant A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. Architectural Considerations in Smart Object Networking The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice. This document offers guidance to engineers designing Internet- connected smart objects. Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported. This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes. Transmission Control Protocol (TCP) This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Delay-Tolerant Networking Architecture This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community. Terms Used in Routing for Low-Power and Lossy Networks This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration. Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK] RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK] IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community. The Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. IPv6 over BLUETOOTH(R) Low Energy Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices. The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques. Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI. The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services. DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications. This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. Transmission of IPv6 Packets over ITU-T G.9959 Networks This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks. IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP) RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth Low Energy (Bluetooth LE) networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol Support Profile (IPSP). This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links. Raytime: Validating token expiry on an unbounded local time interval When devices are deployed in locations with no real-time access to the Internet, obtaining a trusted time for validation of time limited tokens and certificates is sometimes not possible. This document explores the options for deployments in which the trade-off between availability and security needs to be made in favor of availability. While considerations are general, terminology and examples primarily focus on the ACE framework. CoAP in Space UPC Sateliot This document provides guidance on using the Constrained Application Protocol (CoAP) in deep space environments. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication. Trusted Execution Environment Provisioning (TEEP) Architecture A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE. Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949 defines two tags for time: CBOR tag 0 (RFC 3339 time as a string) and tag 1 (POSIX time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. This document is intended as the reference document for the IANA registration of the CBOR tags defined. 6LoWPAN: the Wireless Embedded Internet A Delay-Tolerant Network Architecture for Challenged Internets International Standard — Quantities and units — Part 13: Information science and technology International Electrotechnical Commission RPL deployment experience in large scale networks Cisco Systems Cisco Systems Cisco Systems Cisco Systems Low power and Lossy Networks (LLNs) exhibit characteristics unlike other more traditional IP links. LLNs are a class of network in which both routers and their interconnect are resource constrained. LLN routers are typically resource constrained in processing power, memory, and energy (i.e. battery power). LLN links are typically exhibit high loss rates, low data rates, are are strongly affected by environmental conditions that change over time. LLNs may be composed of a few dozen to thousands of routers. A new protocol called the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) has been specified for routing in LLNs supporting multipoint-to-point, point- to-multipoint traffic, and point-to-point traffic. Since RPL's publication as an RFC, several large scale networks have been succesfully deployed. The aim of this document is to provide deployment experience on real-life deployed RPL-based networks. A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other. This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description. A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks Philips Research University of Glasgow Singapore ARM Ltd. Transport Layer Security (TLS) is a widely used security protocol that offers communication security services at the transport layer. The initial design of TLS was focused on the protection of applications running on top of the Transmission Control Protocol (TCP), and was a good match for securing the Hypertext Transfer Protocol (HTTP). Subsequent standardization efforts lead to the publication of the Datagram Transport Layer Security (DTLS) protocol, which allows the re-use of the TLS security functionality and the payloads to be exchanged on top of the User Datagram Protocol (UDP). With the work on the Constrained Application Protocol (CoAP), as a specialized web transfer protocol for use with constrained nodes and constrained networks, DTLS is a preferred communication security protocol. Smart objects are constrained in various ways (e.g., CPU, memory, power consumption) and these limitations may impose restrictions on the protocol stack such a device runs. This document only looks at the security part of that protocol stacks and the ability to customize TLS/DTLS. To offer input for implementers and system architects this document illustrates the costs and benefits of various TLS/DTLS features for use with smart objects and constraint node networks. Internet of Things (IoT) Security: State of the Art and Challenges The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). Home Automation Routing Requirements in Low-Power and Lossy Networks This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks. In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment. This document is not an Internet Standards Track specification; it is published for informational purposes. Warning about 4/32 devices OpenWRT wiki, last accessed 2021-12-01 ARM architecture profiles Arm Recommendation for key management:: part 1 - general National Institute of Standards and Technology Low-Power Wide Area Network (LPWAN) Overview Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.
Changes Since RFC 7228 The following changes have been made to the guidelines published in :
  • Updated references
  • Added Superscript notations
  • Added new terms such as "Capable Node"
  • Added a classification of device groups
  • Updated Table 1 with more details about classes of constrained devices
  • Added some narrative text about Class 3 and 4 devices
  • Added new subsections "LPWAN", "Firmware/Software Upgradability", "Isolation Functionality", "Secret Shielding", and "Strategies of Keeping Time over Power Events"
  • Added new section "Classes of Networks"
List of Tables
:
:
:
:
:
:
:
:
:
:
:
:
Acknowledgements TBD — to be completed after review process concludes. helped the document through the IETF process as Document Shepherd. served as responsible area director in the IESG. Carles Gomez was supported in part by the Spanish Government MCIU/AEI/10.13039/501100011033/FEDER/UE through project PID2023-146378NBI00.