< draft-bormann-lwig-7228bis-07.txt   draft-bormann-lwig-7228bis-08.txt >
LWIG Working Group C. Bormann LWIG Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universität Bremen TZI
Intended status: Informational M. Ersue Intended status: Informational M. Ersue
Expires: 28 April 2022 Expires: 7 October 2022
A. Keranen A. Keranen
Ericsson Ericsson
C. Gomez C. Gomez
UPC/i2CAT Universitat Politecnica de Catalunya
25 October 2021 5 April 2022
Terminology for Constrained-Node Networks Terminology for Constrained-Node Networks
draft-bormann-lwig-7228bis-07 draft-bormann-lwig-7228bis-08
Abstract Abstract
The Internet Protocol Suite is increasingly used on small devices The Internet Protocol Suite is increasingly used on small devices
with severe constraints on power, memory, and processing resources, with severe constraints on power, memory, and processing resources,
creating constrained-node networks. This document provides a number creating constrained-node networks. This document provides a number
of basic terms that have been useful in the standardization work for of basic terms that have been useful in the standardization work for
constrained-node networks. constrained-node networks.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 April 2022. This Internet-Draft will expire on 7 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Core Terminology . . . . . . . . . . . . . . . . . . . . . . 3 2. Core Terminology . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 4 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 4
2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5 2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5
2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6 2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6
2.3. Constrained-Node Networks . . . . . . . . . . . . . . . . 6 2.3. Constrained-Node Networks . . . . . . . . . . . . . . . . 6
2.3.1. LLN . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. LLN . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 8 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 8
2.3.3. LPWAN . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.3. LPWAN . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8
3.1. Firmware/Software upgradeability . . . . . . . . . . . . 12 3.1. Firmware/Software upgradability . . . . . . . . . . . . . 12
3.2. Isolation functionality . . . . . . . . . . . . . . . . . 13 3.2. Isolation functionality . . . . . . . . . . . . . . . . . 13
3.3. Shielded secrets . . . . . . . . . . . . . . . . . . . . 13 3.3. Shielded secrets . . . . . . . . . . . . . . . . . . . . 13
4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 14 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 14 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 14
4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 15 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 15
4.3. Strategies for Using Power for Communication . . . . . . 16 4.3. Strategies for Using Power for Communication . . . . . . 16
4.4. Strategies of Keeping Time over Power Events . . . . . . 17 4.4. Strategies of Keeping Time over Power Events . . . . . . 17
5. Classes of Networks . . . . . . . . . . . . . . . . . . . . . 19 5. Classes of Networks . . . . . . . . . . . . . . . . . . . . . 20
5.1. Classes of link layer MTU size . . . . . . . . . . . . . 20 5.1. Classes of link layer MTU size . . . . . . . . . . . . . 20
5.2. Class of Internet Integration . . . . . . . . . . . . . . 21 5.2. Class of Internet Integration . . . . . . . . . . . . . . 21
5.3. Classes of physical layer bit rate . . . . . . . . . . . 21 5.3. Classes of physical layer bit rate . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Informative References . . . . . . . . . . . . . . . . . . . 23 8. Informative References . . . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Small devices with limited CPU, memory, and power resources, so- Small devices with limited CPU, memory, and power resources, so-
called "constrained devices" (often used as sensors/actuators, smart called "constrained devices" (often used as sensors/actuators, smart
objects, or smart devices) can form a network, becoming "constrained objects, or smart devices) can form a network, becoming "constrained
nodes" in that network. Such a network may itself exhibit nodes" in that network. Such a network may itself exhibit
constraints, e.g., with unreliable or lossy channels, limited and constraints, e.g., with unreliable or lossy channels, limited and
unpredictable bandwidth, and a highly dynamic topology. unpredictable bandwidth, and a highly dynamic topology.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
Section 3 defines a number of interesting classes ("class-N") of Section 3 defines a number of interesting classes ("class-N") of
constrained nodes focusing on relevant combinations of the first two constrained nodes focusing on relevant combinations of the first two
constraints. With respect to available power, [RFC6606] constraints. With respect to available power, [RFC6606]
distinguishes "power-affluent" nodes (mains-powered or regularly distinguishes "power-affluent" nodes (mains-powered or regularly
recharged) from "power-constrained nodes" that draw their power from recharged) from "power-constrained nodes" that draw their power from
primary batteries or by using energy harvesting; more detailed power primary batteries or by using energy harvesting; more detailed power
terminology is given in Section 4. terminology is given in Section 4.
The use of constrained nodes in networks often also leads to The use of constrained nodes in networks often also leads to
constraints on the networks themselves. However, there may also be constraints on the networks themselves. However, there may also be
constraints on networks that are largely independent from those of constraints on networks that are largely independent of those of the
the nodes. We therefore distinguish "constrained networks" from nodes. We therefore distinguish "constrained networks" from
"constrained-node networks". "constrained-node networks".
2.2. Constrained Networks 2.2. Constrained Networks
We define "constrained network" in a similar way: We define "constrained network" in a similar way:
Constrained Network: A network where some of the characteristics Constrained Network: A network where some of the characteristics
pretty much taken for granted with link layers in common use in pretty much taken for granted with link layers in common use in
the Internet at the time of writing are not attainable. the Internet at the time of writing are not attainable.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
802.15.4 or low-power Wi-Fi. There is a wide scope of application 802.15.4 or low-power Wi-Fi. There is a wide scope of application
areas for LLNs, including industrial monitoring, building areas for LLNs, including industrial monitoring, building
automation (heating, ventilation, and air conditioning (HVAC), automation (heating, ventilation, and air conditioning (HVAC),
lighting, access control, fire), connected home, health care, lighting, access control, fire), connected home, health care,
environmental monitoring, urban sensor networks, energy environmental monitoring, urban sensor networks, energy
management, assets tracking, and refrigeration. management, assets tracking, and refrigeration.
Beyond that, LLNs often exhibit considerable loss at the physical Beyond that, LLNs often exhibit considerable loss at the physical
layer, with significant variability of the delivery rate, and some layer, with significant variability of the delivery rate, and some
short-term unreliability, coupled with some medium-term stability short-term unreliability, coupled with some medium-term stability
that makes it worthwhile to both construct directed acyclic graphs that makes it worthwhile to both (1) construct directed acyclic
that are medium-term stable for routing and do measurements on the graphs that are medium-term stable for routing and (2) do
edges such as Expected Transmission Count (ETX) [RFC6551]. Not all measurements on the edges such as Expected Transmission Count (ETX)
LLNs comprise low-power nodes [I-D.hui-vasseur-roll-rpl-deployment]. [RFC6551]. Not all LLNs comprise low-power nodes
[I-D.hui-vasseur-roll-rpl-deployment].
LLNs typically are composed of constrained nodes; this leads to the LLNs typically are composed of constrained nodes; this leads to the
design of operation modes such as the "non-storing mode" defined by design of operation modes such as the "non-storing mode" defined by
RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks
[RFC6550]). So, in the terminology of the present document, an LLN [RFC6550]). So, in the terminology of the present document, an LLN
is a constrained-node network with certain network characteristics, is a constrained-node network with certain network characteristics,
which include constraints on the network as well. which include constraints on the network as well.
2.3.2. LoWPAN, 6LoWPAN 2.3.2. LoWPAN, 6LoWPAN
skipping to change at page 8, line 20 skipping to change at page 8, line 20
personal area networks (LR-WPANs)). The expansion of the LoWPAN personal area networks (LR-WPANs)). The expansion of the LoWPAN
acronym, "Low-Power Wireless Personal Area Network", contains a hard- acronym, "Low-Power Wireless Personal Area Network", contains a hard-
to-justify "Personal" that is due to the history of task group naming 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 in IEEE 802 more than due to an orientation of LoWPANs around a
single person. Actually, LoWPANs have been suggested for urban single person. Actually, LoWPANs have been suggested for urban
monitoring, control of large buildings, and industrial control monitoring, control of large buildings, and industrial control
applications, so the "Personal" can only be considered a vestige. applications, so the "Personal" can only be considered a vestige.
Occasionally, the term is read as "Low-Power Wireless Area Networks" Occasionally, the term is read as "Low-Power Wireless Area Networks"
[WEI]. Originally focused on IEEE 802.15.4, "LoWPAN" (or when used [WEI]. Originally focused on IEEE 802.15.4, "LoWPAN" (or when used
for IPv6, "6LoWPAN") also refers to networks built from similarly for IPv6, "6LoWPAN") also refers to networks built from similarly
constrained link-layer technologies [RFC7668] [RFC8105] [RFC7428]. constrained link-layer technologies [RFC7668] [RFC8105] [RFC7428]
[RFC9159].
2.3.3. LPWAN 2.3.3. LPWAN
An overview over Low-Power Wide Area Network (LPWAN) technologies is An overview over Low-Power Wide Area Network (LPWAN) technologies is
provided by [RFC8376]. provided by [RFC8376].
3. Classes of Constrained Devices 3. Classes of Constrained Devices
Despite the overwhelming variety of Internet-connected devices that Despite the overwhelming variety of Internet-connected devices that
can be envisioned, it may be worthwhile to have some succinct can be envisioned, it may be worthwhile to have some succinct
skipping to change at page 10, line 5 skipping to change at page 10, line 5
If the distinction between these groups needs to be made in this If the distinction between these groups needs to be made in this
document, we distinguish group "M" (microcontroller) from group "J" document, we distinguish group "M" (microcontroller) from group "J"
(general purpose). (general purpose).
In this document, the class designations in Table 1 may be used as In this document, the class designations in Table 1 may be used as
rough indications of device capabilities. Note that the classes from rough indications of device capabilities. Note that the classes from
10 upwards are not really constrained devices in the sense of the 10 upwards are not really constrained devices in the sense of the
previous section; they may still be useful to discuss constraints in previous section; they may still be useful to discuss constraints in
larger devices: larger devices:
+=======+=========+=============+===============+=============+ +=======+=========+===================+===============+=============+
| Group | Name | data size | code size | Examples | | Group | Name | data size (e.g., | code size | Examples |
| | | (e.g., RAM) | (e.g., Flash) | | | | | RAM) | (e.g., Flash) | |
+=======+=========+=============+===============+=============+ +=======+=========+===================+===============+=============+
| M | Class | << 10 KiB | << 100 KiB | ATtiny | | M | Class | << 10 KiB | << 100 KiB | ATtiny |
| | 0, C0 | | | | | | 0, C0 | | | |
+-------+---------+-------------+---------------+-------------+ +-------+---------+-------------------+---------------+-------------+
| M | Class | ~ 10 KiB | ~ 100 KiB | STM32F103CB | | M | Class | ~ 10 KiB | ~ 100 KiB | STM32F103CB |
| | 1, C1 | | | | | | 1, C1 | | | |
+-------+---------+-------------+---------------+-------------+ +-------+---------+-------------------+---------------+-------------+
| M | Class | ~ 50 KiB | ~ 250 KiB | STM32F103RC | | M | Class | ~ 50 KiB | ~ 250 KiB | STM32F103RC |
| | 2, C2 | | | | | | 2, C2 | | | |
+-------+---------+-------------+---------------+-------------+ +-------+---------+-------------------+---------------+-------------+
| M | Class | ~ 100 KiB | ~ 500..1000 | STM32F103RG | | M | Class | ~ 100 KiB | ~ 500..1000 | STM32F103RG |
| | 3, C3 | | KiB | | | | 3, C3 | | KiB | |
+-------+---------+-------------+---------------+-------------+ +-------+---------+-------------------+---------------+-------------+
| M | Class | ~ 300..1000 | ~ 1000..2000 | "Luxury" | | M | Class | ~ 300..1000 KiB | ~ 1000..2000 | "Luxury" |
| | 4, C4 | KiB | KiB | | | | 4, C4 | | KiB | |
+-------+---------+-------------+---------------+-------------+ +-------+---------+-------------------+---------------+-------------+
| J | Class | 4-8 MiB | (?) | OpenWRT | | J | Class | (16..)32..64..128 | 4..8..16 MiB | OpenWRT |
| | 10, C10 | | | routers | | | 10, | MiB | | routers |
+-------+---------+-------------+---------------+-------------+ | | C10 | | | |
| J | Class | 0.5..1 GiB | (lots) | Raspberry | +-------+---------+-------------------+---------------+-------------+
| | 15, C15 | | | PI | | J | Class | 0.5..1 GiB | (lots) | Raspberry |
+-------+---------+-------------+---------------+-------------+ | | 15, | | | PI |
| J | Class | 1..4 GiB | (lots) | Smartphones | | | C15 | | | |
| | 16, C16 | | | | +-------+---------+-------------------+---------------+-------------+
+-------+---------+-------------+---------------+-------------+ | J | Class | 1..4 GiB | (lots) | Smartphones |
| J | Class | 4..32 GiB | (lots) | Laptops | | | 16, | | | |
| | 17, C17 | | | | | | C16 | | | |
+-------+---------+-------------+---------------+-------------+ +-------+---------+-------------------+---------------+-------------+
| J | Class | (lots) | (lots) | Servers | | J | Class | 4..32 GiB | (lots) | Laptops |
| | 19, C19 | | | | | | 17, | | | |
+-------+---------+-------------+---------------+-------------+ | | C17 | | | |
+-------+---------+-------------------+---------------+-------------+
| J | Class | (lots) | (lots) | Servers |
| | 19, | | | |
| | C19 | | | |
+-------+---------+-------------------+---------------+-------------+
Table 1: Classes of Constrained Devices (KiB = 1024 bytes) Table 1: Classes of Constrained Devices (KiB = 1024 bytes)
As of the writing of this document, these characteristics correspond As of the writing of this document, these characteristics correspond
to distinguishable clusters of commercially available chips and to distinguishable clusters of commercially available chips and
design cores for constrained devices. While it is expected that the design cores for constrained devices. While it is expected that the
boundaries of these classes will move over time, Moore's law tends to boundaries of these classes will move over time, Moore's law tends to
be less effective in the embedded space than in personal computing be less effective in the embedded space than in personal computing
devices: gains made available by increases in transistor count and devices: gains made available by increases in transistor count and
density are more likely to be invested in reductions of cost and density are more likely to be invested in reductions of cost and
power requirements than into continual increases in computing power. 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 preferring 16/128 for modern software releases
[W432].)
Class 0 devices are very constrained sensor-like motes. They are so Class 0 devices are very constrained sensor-like motes. They are so
severely constrained in memory and processing capabilities that most severely constrained in memory and processing capabilities that most
likely they will not have the resources required to communicate likely they will not have the resources required to communicate
directly with the Internet in a secure manner (rare heroic, narrowly directly with the Internet in a secure manner (rare heroic, narrowly
targeted implementation efforts notwithstanding). Class 0 devices targeted implementation efforts notwithstanding). Class 0 devices
will participate in Internet communications with the help of larger will participate in Internet communications with the help of larger
devices acting as proxies, gateways, or servers. Class 0 devices devices acting as proxies, gateways, or servers. Class 0 devices
generally cannot be secured or managed comprehensively in the generally cannot be secured or managed comprehensively in the
traditional sense. They will most likely be preconfigured (and will traditional sense. They will most likely be preconfigured (and will
skipping to change at page 12, line 14 skipping to change at page 12, line 9
Constrained devices with capabilities significantly beyond Class 2 Constrained devices with capabilities significantly beyond Class 2
devices exist. They are less demanding from a standards development devices exist. They are less demanding from a standards development
point of view as they can largely use existing protocols unchanged. point of view as they can largely use existing protocols unchanged.
The previous version of the present document therefore did not make The previous version of the present document therefore did not make
any attempt to define constrained classes beyond Class 2. These any attempt to define constrained classes beyond Class 2. These
devices, and to a certain extent even J-group devices, can still be 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 constrained by a limited energy supply. Class 3 and 4 devices are
less clearly defined than the lower classes; they are even less less clearly defined than the lower classes; they are even less
constrained. In particular Class 4 devices are powerful enough to constrained. In particular Class 4 devices are powerful enough to
quite comfortably run, e.g., JavaScript interpreters, together with quite comfortably run, say, JavaScript interpreters, together with
elaborate network stacks. Additional classes may need to be defined elaborate network stacks. Additional classes may need to be defined
based on protection capabilities, e.g., an MPU (memory protection based on protection capabilities, e.g., an MPU (memory protection
unit; true MMUs are typically only found in J-group devices). unit; true MMUs are typically only found in J-group devices).
With respect to examining the capabilities of constrained nodes, With respect to examining the capabilities of constrained nodes,
particularly for Class 1 devices, it is important to understand what particularly for Class 1 devices, it is important to understand what
type of applications they are able to run and which protocol type of applications they are able to run and which protocol
mechanisms would be most suitable. Because of memory and other mechanisms would be most suitable. Because of memory and other
limitations, each specific Class 1 device might be able to support limitations, each specific Class 1 device might be able to support
only a few selected functions needed for its intended operation. In only a few selected functions needed for its intended operation. In
skipping to change at page 12, line 37 skipping to change at page 12, line 32
choose to support different functions. Even though Class 2 devices choose to support different functions. Even though Class 2 devices
have some more functionality available and may be able to provide a have some more functionality available and may be able to provide a
more complete set of functions, they still need to be assessed for more complete set of functions, they still need to be assessed for
the type of applications they will be running and the protocol the type of applications they will be running and the protocol
functions they would need. To be able to derive any requirements, functions they would need. To be able to derive any requirements,
the use cases and the involvement of the devices in the application the use cases and the involvement of the devices in the application
and the operational scenario need to be analyzed. Use cases may and the operational scenario need to be analyzed. Use cases may
combine constrained devices of multiple classes as well as more combine constrained devices of multiple classes as well as more
traditional Internet nodes. traditional Internet nodes.
3.1. Firmware/Software upgradeability 3.1. Firmware/Software upgradability
Platforms may differ in their firmware or software upgradeability. Platforms may differ in their firmware or software upgradability.
The below is a first attempt at classifying this. The below is a first attempt at classifying this.
+======+============================================================+ +======+============================================================+
| Name | Firmware/Software upgradeability | | Name | Firmware/Software upgradability |
+======+============================================================+ +======+============================================================+
| F0 | no (discard for upgrade) | | F0 | no (discard for upgrade) |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| F1 | replaceable, out of service during replacement, reboot | | F1 | replaceable, out of service during replacement, reboot |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| F2 | patchable during operation, reboot required | | F2 | patchable during operation, reboot required |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| F3 | patchable during operation, restart not visible | | F3 | patchable during operation, restart not visible |
| | externally | | | externally |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| F9 | app-level upgradeability, no reboot required | | F9 | app-level upgradability, no reboot required |
| | ("hitless") | | | ("hitless") |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
Table 2: Levels of software update capabilities Table 2: Levels of software update capabilities
3.2. Isolation functionality 3.2. Isolation functionality
TBD. This section could discuss the ability of the platform to TBD. This section could discuss the ability of the platform to
isolate different components. The categories below are not mutually isolate different components. The categories below are not mutually
exclusive; we need to build relevant clusters. exclusive; we need to build relevant clusters.
skipping to change at page 17, line 39 skipping to change at page 17, line 39
[RFC7102] only distinguishes two levels, defining a Non-Sleepy Node [RFC7102] only distinguishes two levels, defining a Non-Sleepy Node
as a node that always remains in a fully powered-on state (always as a node that always remains in a fully powered-on state (always
awake) where it has the capability to perform communication (P9) and 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 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 low-power state to conserve power) and temporarily suspend protocol
communication (P0); there is no explicit mention of P1. communication (P0); there is no explicit mention of P1.
4.4. Strategies of Keeping Time over Power Events 4.4. Strategies of Keeping Time over Power Events
[This subsection is very drafty.]
Many applications for a device require it to keep some concept of Many applications for a device require it to keep some concept of
time. time.
Time-keeping can be relative to a previous event (last packet Time-keeping can be relative to a previous event (last packet
received), absolute on a device-specific scale (e.g., last reboot), received), absolute on a device-specific scale (e.g., last reboot),
or absolute on a world-wide scale ("wall-clock time"). or absolute on a world-wide scale ("wall-clock time").
Some devices lose the concept of time when going to sleep: after 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 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 some concept of time during sleep, but not precise enough to use as a
skipping to change at page 19, line 51 skipping to change at page 20, line 20
+------+------------------------------------+-----------------+ +------+------------------------------------+-----------------+
| TP1 | time needs to be set during | (possibly | | TP1 | time needs to be set during | (possibly |
| | installation | reduced... | | | installation | reduced... |
+------+------------------------------------+-----------------+ +------+------------------------------------+-----------------+
| TP9 | reliable time is maintained during | ...by using | | TP9 | reliable time is maintained during | ...by using |
| | lifetime | external input) | | | lifetime | external input) |
+------+------------------------------------+-----------------+ +------+------------------------------------+-----------------+
Table 9: Permanency of Keeping Time Table 9: Permanency of Keeping Time
Further parameters that can be used to discuss clock quality can be
found in Section 3.5 of [I-D.ietf-cbor-time-tag].
5. Classes of Networks 5. Classes of Networks
5.1. Classes of link layer MTU size 5.1. Classes of link layer MTU size
Link layer technologies used by constrained devices can be Link layer technologies used by constrained devices can be
categorized on the basis of link layer MTU size. Depending on this categorized on the basis of link layer MTU size. Depending on this
parameter, the fragmentation techniques needed (if any) to support parameter, the fragmentation techniques needed (if any) to support
the IPv6 MTU requirement may vary. the IPv6 MTU requirement may vary.
We define the following classes of link layer MTU size: We define the following classes of link layer MTU size:
+======+=====================+====================================+ +======+=====================+====================================+
skipping to change at page 21, line 11 skipping to change at page 21, line 27
S3 technologies do not require fragmentation to support the IPv6 MTU S3 technologies do not require fragmentation to support the IPv6 MTU
requirement. requirement.
5.2. Class of Internet Integration 5.2. Class of Internet Integration
The term "Internet of Things" is sometimes confusingly used for The term "Internet of Things" is sometimes confusingly used for
connected devices that are not actually employing Internet connected devices that are not actually employing Internet
technology. Some devices do use Internet technology, but only use it technology. Some devices do use Internet technology, but only use it
to exchange packets with a fixed communication partner ("device-to- to exchange packets with a fixed communication partner ("device-to-
cloud" scenarios, [RFC7452]). More general devices are prepared to cloud" scenarios, see also Section 2.2 of [RFC7452]). More general
communicate with other nodes in the Internet as well. devices are prepared to communicate with other nodes in the Internet
as well.
We define the following classes of Internet technology level: We define the following classes of Internet technology level:
+======+======================================+ +======+======================================+
| Name | Internet technology | | Name | Internet technology |
+======+======================================+ +======+======================================+
| I0 | none (local interconnect only) | | I0 | none (local interconnect only) |
+------+--------------------------------------+ +------+--------------------------------------+
| I1 | device-to-cloud only | | I1 | device-to-cloud only |
+------+--------------------------------------+ +------+--------------------------------------+
skipping to change at page 23, line 38 skipping to change at page 23, line 46
<https://doi.org/10.1145/863955.863960>. <https://doi.org/10.1145/863955.863960>.
[I-D.hui-vasseur-roll-rpl-deployment] [I-D.hui-vasseur-roll-rpl-deployment]
Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL
deployment experience in large scale networks", Work in deployment experience in large scale networks", Work in
Progress, Internet-Draft, draft-hui-vasseur-roll-rpl- Progress, Internet-Draft, draft-hui-vasseur-roll-rpl-
deployment-01, 5 July 2012, deployment-01, 5 July 2012,
<https://www.ietf.org/archive/id/draft-hui-vasseur-roll- <https://www.ietf.org/archive/id/draft-hui-vasseur-roll-
rpl-deployment-01.txt>. rpl-deployment-01.txt>.
[I-D.ietf-cbor-time-tag]
Bormann, C., Gamari, B., and H. Birkholz, "Concise Binary
Object Representation (CBOR) Tags for Time, Duration, and
Period", Work in Progress, Internet-Draft, draft-ietf-
cbor-time-tag-00, 19 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-
00.txt>.
[I-D.ietf-lwig-tls-minimal] [I-D.ietf-lwig-tls-minimal]
Kumar, S. S., Keoh, S. L., and H. Tschofenig, "A Kumar, S. S., Keoh, S. L., and H. Tschofenig, "A
Hitchhiker's Guide to the (Datagram) Transport Layer Hitchhiker's Guide to the (Datagram) Transport Layer
Security Protocol for Smart Objects and Constrained Node Security Protocol for Smart Objects and Constrained Node
Networks", Work in Progress, Internet-Draft, draft-ietf- Networks", Work in Progress, Internet-Draft, draft-ietf-
lwig-tls-minimal-01, 7 March 2014, lwig-tls-minimal-01, 7 March 2014,
<https://www.ietf.org/archive/id/draft-ietf-lwig-tls- <https://www.ietf.org/archive/id/draft-ietf-lwig-tls-
minimal-01.txt>. minimal-01.txt>.
[IoT-2025] Rosen, M. and IDC, "Driving the Digital Agenda Requires [IoT-2025] Rosen, M. and IDC, "Driving the Digital Agenda Requires
skipping to change at page 26, line 31 skipping to change at page 26, line 41
Things (IoT) Security: State of the Art and Challenges", Things (IoT) Security: State of the Art and Challenges",
RFC 8576, DOI 10.17487/RFC8576, April 2019, RFC 8576, DOI 10.17487/RFC8576, April 2019,
<https://www.rfc-editor.org/info/rfc8576>. <https://www.rfc-editor.org/info/rfc8576>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724, Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020, DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>. <https://www.rfc-editor.org/info/rfc8724>.
[RFC9159] Gomez, C., Darroudi, S.M., Savolainen, T., and M. Spoerk,
"IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet
Protocol Support Profile (IPSP)", RFC 9159,
DOI 10.17487/RFC9159, December 2021,
<https://www.rfc-editor.org/info/rfc9159>.
[W432] "Warning about 4/32 devices", OpenWRT wiki, last accessed
2021-12-01,
<https://openwrt.org/supported_devices/432_warning>.
[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
Internet", Wiley-Blackwell monograph, Internet", Wiley-Blackwell monograph,
DOI 10.1002/9780470686218, ISBN 9780470747995, 2009, DOI 10.1002/9780470686218, ISBN 9780470747995, 2009,
<https://doi.org/10.1002/9780470686218>. <https://doi.org/10.1002/9780470686218>.
Acknowledgements Acknowledgements
TBD TBD
Authors' Addresses Authors' Addresses
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
Mehmet Ersue
Mehmet Ersue
Munich
Germany
Email: mersue@gmail.com Email: mersue@gmail.com
Ari Keranen Ari Keranen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
FI-02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
Carles Gomez Carles Gomez
UPC/i2CAT Universitat Politecnica de Catalunya
Escola d'Enginyeria de Telecomunicacio i Aeroespacial
de Castelldefels
C/Esteve Terradas, 7 C/Esteve Terradas, 7
08860 Castelldefels 08860 Castelldefels
Spain Spain
Phone: +34-93-413-7206 Phone: +34-93-413-7206
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
 End of changes. 33 change blocks. 
72 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/