]> 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 LWIG 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 the standardization work for constrained-node networks. About This Document Status information for this document may be found at . Discussion of this document takes place on the Light-Weight Implementation Guidance (lwig) 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 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 battery 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, diverse sizes of 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) becomes a reality, built up out of uniquely identifiable and addressable objects (things). Over the next decade, this could grow to large numbers of Internet-connected constrained devices ( predicts that by, 2025, more than 2500 devices will be connected to the Internet per second), greatly increasing the Internet's size and scope. The present document provides a number of basic terms that have been useful in the 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 . 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 . Powers of 10 are given as 10¹⁰⁰ where 100 is the exponent. 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 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 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".) As an antonym, we cannot use "unconstrained node", 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 recently 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, and
• constraints on user interface and accessibility in deployment (ability to set keys, update software, etc.).

defines a number of interesting classes ("class-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. We therefore distinguish "constrained networks" from "constrained-node networks".

Constrained Networks We define "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 duty cycle),
• 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), and
• lack of (or severe constraints on) advanced services such as IP multicast.

More generally, we speak of constrained networks 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 the Maximum Segment Lifetime (MSL) assumed by TCP (Section of RFC 9293 ).

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 two additional terms that are in active use in the area of constrained-node networks, without an intent to define them: LLN and (6)LoWPAN.

LLN A related term that has been used to describe the focus of the IETF ROLL working group is "Low-Power and Lossy Network (LLN)". The ROLL (Routing Over Low-Power and Lossy) 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 . LLNs typically are 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 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. Before we get to that, let's first distinguish two big rough groups of devices based on their CPU capabilities:

• Microcontroller-class devices (sometimes called "M-class"). 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 an MMU (memory management unit). 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. Where this hardware is specialized for an application, we may talk about "Systems on a Chip" (SOC). These devices often implement elaborate sleep modes to achieve microwatt- or at least milliwatt-level sustained power usage (Ps, see below).
• General-purpose-class devices (sometimes called "A-class"). 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, e.g. 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 "Systems on a Chip" (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 in this document, we distinguish group "M" (microcontroller) from group "J" (general purpose). 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: Classes of Constrained Devices (KiB = 1024 bytes)

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	"Luxury"
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 sensor-like motes. 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 be reconfigured rarely, 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 such as using 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 parsimonious 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 elaborate 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. The below 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 the platform to isolate different software components. The categories below are not mutually exclusive. Levels of Isolation Capabilities

Name	Isolation functionality
Is0	no isolation
Is2	MPU (memory protection unit), at least boundary registers
Is5	MMU with Linux-style kernel/user
Is7	Virtualization-style isolation
Is8	Secure enclave isolation

Shielded secrets Some platforms can keep secrets shielded (usually in conjunction with secure enclave functionality). Levels of Secret Shielding Capabilities

Name	Secret shielding functionality
Sh0	no secret shielding
Sh1	some secret shielding
Sh9	perfect 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, we simply state, using the International System of Units (SI units), an approximate value for one or both of the quantities listed in : 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. 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
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 extreme 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 reattachment may be acceptable.

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 for a device require it 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 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, e.g. 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 where 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	(usually high during sleep)
T3	relative time	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. We define the following classes of link layer MTU size: Classes of Link Layer MTU Size

Name	L2 MTU size (bytes)	6LoWPAN Fragmentation applicable*?
S0	3 – 12	need new kind of fragmentation
S1	13 – 127	yes
S2	128 – 1279	yes
S3	>= 1280	no fragmentation needed

* if no link layer fragmentation is available (note: 'Sx' stands for 'Size x') 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 and S2 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. S3 technologies do not require fragmentation to support the IPv6 MTU requirement.

Class 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. We define the following classes of Internet technology level: Classes of Internet Technology Level

Name	Internet technology
I0	none (local interconnect only)
I1	device-to-cloud only
I9	full Internet connectivity supported

Classes of physical layer bit rate [This section could be expanded to also talk about burst rate vs. sustained rate; bits/s vs. messages/s, ...] 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. We define the following classes of PHY bit rate: Classes of Physical Layer Bitrate

Name	PHY bit rate (bit/s)	Comment
B0	< 10	Transmission time of 150-byte frame > MSL
B1	10 – 103	Unresponsiveness if human expects reaction to sent frame (frame size > 62.5 byte)
B2	103 – 106	Responsiveness if human expects reaction to sent frame, but header compression still needed
B3	> 106	Header compression yields relatively low performance benefits

(note: 'Bx' stands for 'Bit rate x') B0 technologies lead to very high transmission times, which may be close to or even greater than the Maximum Segment Lifetime (MSL) assumed on the Internet (Section of RFC 9293 ). Many Internet protocols and mechanisms will fail when transmission times, and thus latencies, are greater than the MSL . B0 technologies lead to a frame transmission time greater than the MSL for a frame size greater than 150 bytes. B1 technologies offer transmission times which are lower than the 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 (e.g. ) 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.

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 . A wider view of security in constrained-node networks is provided in .

Informative References 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. 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. [STANDARDS-TRACK] 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] 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] 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. 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. 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. 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. 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. 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. 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] 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] 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) 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. 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. 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. 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. 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. 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. UPC Sateliot This document provides guidance on using the Constrained Application Protocol (CoAP) in deep space environments. The document focuses on the scenario where an IP protocol stack is used for deep space communication. Universität Bremen TZI Well-Typed Fraunhofer Institute for Secure Information Technology 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 (RFC3339 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. // (This cref will be removed by the RFC editor:) The present // revision (–12) addresses the IESG reviews. IDC Slide 11 International Electrotechnical Commission 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. 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. 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. 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. 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). 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. OpenWRT wiki, last accessed 2021-12-01 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.

Acknowledgements TBD