| < 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/ | ||||