idnits 2.17.1 draft-bormann-lwig-7228bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 02, 2019) is 1692 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-21 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational M. Ersue 5 Expires: March 5, 2020 Nokia Solutions and Networks 6 A. Keranen 7 Ericsson 8 C. Gomez 9 UPC/i2CAT 10 September 02, 2019 12 Terminology for Constrained-Node Networks 13 draft-bormann-lwig-7228bis-05 15 Abstract 17 The Internet Protocol Suite is increasingly used on small devices 18 with severe constraints on power, memory, and processing resources, 19 creating constrained-node networks. This document provides a number 20 of basic terms that have been useful in the standardization work for 21 constrained-node networks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 5, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Core Terminology . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5 61 2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6 62 2.3. Constrained-Node Networks . . . . . . . . . . . . . . . . 6 63 2.3.1. LLN . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7 65 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8 66 3.1. Firmware/Software upgradeability . . . . . . . . . . . . 11 67 3.2. Isolation functionality . . . . . . . . . . . . . . . . . 11 68 3.3. Shielded secrets . . . . . . . . . . . . . . . . . . . . 12 69 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 12 70 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 12 71 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 13 72 4.3. Strategies for Using Power for Communication . . . . . . 14 73 4.4. Strategies of Keeping Time over Power Events . . . . . . 16 74 5. Classes of Networks . . . . . . . . . . . . . . . . . . . . . 18 75 5.1. Classes of link layer MTU size . . . . . . . . . . . . . 18 76 5.2. Class of Internet Integration . . . . . . . . . . . . . . 19 77 5.3. Classes of physical layer bit rate . . . . . . . . . . . 19 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 8. Informative References . . . . . . . . . . . . . . . . . . . 21 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 84 1. Introduction 86 Small devices with limited CPU, memory, and power resources, so- 87 called "constrained devices" (often used as sensors/actuators, smart 88 objects, or smart devices) can form a network, becoming "constrained 89 nodes" in that network. Such a network may itself exhibit 90 constraints, e.g., with unreliable or lossy channels, limited and 91 unpredictable bandwidth, and a highly dynamic topology. 93 Constrained devices might be in charge of gathering information in 94 diverse settings, including natural ecosystems, buildings, and 95 factories, and sending the information to one or more server 96 stations. They might also act on information, by performing some 97 physical action, including displaying it. Constrained devices may 98 work under severe resource constraints such as limited battery and 99 computing power, little memory, and insufficient wireless bandwidth 100 and ability to communicate; these constraints often exacerbate each 101 other. Other entities on the network, e.g., a base station or 102 controlling server, might have more computational and communication 103 resources and could support the interaction between the constrained 104 devices and applications in more traditional networks. 106 Today, diverse sizes of constrained devices with different resources 107 and capabilities are becoming connected. Mobile personal gadgets, 108 building-automation devices, cellular phones, machine-to-machine 109 (M2M) devices, and other devices benefit from interacting with other 110 "things" nearby or somewhere in the Internet. With this, the 111 Internet of Things (IoT) becomes a reality, built up out of uniquely 112 identifiable and addressable objects (things). Over the next decade, 113 this could grow to large numbers [FIFTY-BILLION] of Internet- 114 connected constrained devices, greatly increasing the Internet's size 115 and scope. 117 The present document provides a number of basic terms that have been 118 useful in the standardization work for constrained environments. The 119 intention is not to exhaustively cover the field but to make sure a 120 few core terms are used consistently between different groups 121 cooperating in this space. 123 The present document is an update of [RFC7228]. 125 In this document, the term "byte" is used in its now customary sense 126 as a synonym for "octet". Where sizes of semiconductor memory are 127 given, the prefix "kibi" (1024) is combined with "byte" to 128 "kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13]. 130 In computing, the term "power" is often used for the concept of 131 "computing power" or "processing power", as in CPU performance. In 132 this document, the term stands for electrical power unless explicitly 133 stated otherwise. "Mains-powered" is used as a shorthand for being 134 permanently connected to a stable electrical power grid. 136 2. Core Terminology 138 There are two important aspects to _scaling_ within the Internet of 139 Things: 141 o scaling up Internet technologies to a large number [FIFTY-BILLION] 142 of inexpensive nodes, while 144 o scaling down the characteristics of each of these nodes and of the 145 networks being built out of them, to make this scaling up 146 economically and physically viable. 148 The need for scaling down the characteristics of nodes leads to 149 "constrained nodes". 151 2.1. Constrained Nodes 153 The term "constrained node" is best defined by contrasting the 154 characteristics of a constrained node with certain widely held 155 expectations on more familiar Internet nodes: 157 Constrained Node: A node where some of the characteristics that are 158 otherwise pretty much taken for granted for Internet nodes at the 159 time of writing are not attainable, often due to cost constraints 160 and/or physical constraints on characteristics such as size, 161 weight, and available power and energy. The tight limits on 162 power, memory, and processing resources lead to hard upper bounds 163 on state, code space, and processing cycles, making optimization 164 of energy and network bandwidth usage a dominating consideration 165 in all design requirements. Also, some layer-2 services such as 166 full connectivity and broadcast/multicast may be lacking. 168 While this is not a rigorous definition, it is grounded in the state 169 of the art and clearly sets apart constrained nodes from server 170 systems, desktop or laptop computers, powerful mobile devices such as 171 smartphones, etc. There may be many design considerations that lead 172 to these constraints, including cost, size, weight, and other scaling 173 factors. 175 (An alternative term, when the properties as a network node are not 176 in focus, is "constrained device".) 178 There are multiple facets to the constraints on nodes, often applying 179 in combination, for example: 181 o constraints on the maximum code complexity (ROM/Flash), 183 o constraints on the size of state and buffers (RAM), 185 o constraints on the amount of computation feasible in a period of 186 time ("processing power"), 188 o constraints on the available power, and 190 o constraints on user interface and accessibility in deployment 191 (ability to set keys, update software, etc.). 193 Section 3 defines a small number of interesting classes ("class-N" 194 for N = 0, 1, 2) of constrained nodes focusing on relevant 195 combinations of the first two constraints. With respect to available 196 power, [RFC6606] distinguishes "power-affluent" nodes (mains-powered 197 or regularly recharged) from "power-constrained nodes" that draw 198 their power from primary batteries or by using energy harvesting; 199 more detailed power terminology is given in Section 4. 201 The use of constrained nodes in networks often also leads to 202 constraints on the networks themselves. However, there may also be 203 constraints on networks that are largely independent from those of 204 the nodes. We therefore distinguish "constrained networks" from 205 "constrained-node networks". 207 2.2. Constrained Networks 209 We define "constrained network" in a similar way: 211 Constrained Network: A network where some of the characteristics 212 pretty much taken for granted with link layers in common use in 213 the Internet at the time of writing are not attainable. 215 Constraints may include: 217 o low achievable bitrate/throughput (including limits on duty 218 cycle), 220 o high packet loss and high variability of packet loss (delivery 221 rate), 223 o highly asymmetric link characteristics, 225 o severe penalties for using larger packets (e.g., high packet loss 226 due to link-layer fragmentation), 228 o limits on reachability over time (a substantial number of devices 229 may power off at any point in time but periodically "wake up" and 230 can communicate for brief periods of time), and 232 o lack of (or severe constraints on) advanced services such as IP 233 multicast. 235 More generally, we speak of constrained networks whenever at least 236 some of the nodes involved in the network exhibit these 237 characteristics. 239 Again, there may be several reasons for this: 241 o cost constraints on the network, 243 o constraints posed by the nodes (for constrained-node networks), 245 o physical constraints (e.g., power constraints, environmental 246 constraints, media constraints such as underwater operation, 247 limited spectrum for very high density, electromagnetic 248 compatibility), 250 o regulatory constraints, such as very limited spectrum availability 251 (including limits on effective radiated power and duty cycle) or 252 explosion safety, and 254 o technology constraints, such as older and lower-speed technologies 255 that are still operational and may need to stay in use for some 256 more time. 258 2.2.1. Challenged Networks 260 A constrained network is not necessarily a "challenged network" 261 [FALL]: 263 Challenged Network: A network that has serious trouble maintaining 264 what an application would today expect of the end-to-end IP model, 265 e.g., by: 267 * not being able to offer end-to-end IP connectivity at all, 269 * exhibiting serious interruptions in end-to-end IP connectivity, 270 or 272 * exhibiting delay well beyond the Maximum Segment Lifetime (MSL) 273 defined by TCP [RFC0793]. 275 All challenged networks are constrained networks in some sense, but 276 not all constrained networks are challenged networks. There is no 277 well-defined boundary between the two, though. Delay-Tolerant 278 Networking (DTN) has been designed to cope with challenged networks 279 [RFC4838]. 281 2.3. Constrained-Node Networks 283 Constrained-Node Network: A network whose characteristics are 284 influenced by being composed of a significant portion of 285 constrained nodes. 287 A constrained-node network always is a constrained network because of 288 the network constraints stemming from the node constraints, but it 289 may also have other constraints that already make it a constrained 290 network. 292 The rest of this subsection introduces two additional terms that are 293 in active use in the area of constrained-node networks, without an 294 intent to define them: LLN and (6)LoWPAN. 296 2.3.1. LLN 298 A related term that has been used to describe the focus of the IETF 299 ROLL working group is "Low-Power and Lossy Network (LLN)". The ROLL 300 (Routing Over Low-Power and Lossy) terminology document [RFC7102] 301 defines LLNs as follows: 303 LLN: Low-Power and Lossy Network. Typically composed of many 304 embedded devices with limited power, memory, and processing 305 resources interconnected by a variety of links, such as IEEE 306 802.15.4 or low-power Wi-Fi. There is a wide scope of application 307 areas for LLNs, including industrial monitoring, building 308 automation (heating, ventilation, and air conditioning (HVAC), 309 lighting, access control, fire), connected home, health care, 310 environmental monitoring, urban sensor networks, energy 311 management, assets tracking, and refrigeration. 313 Beyond that, LLNs often exhibit considerable loss at the physical 314 layer, with significant variability of the delivery rate, and some 315 short-term unreliability, coupled with some medium-term stability 316 that makes it worthwhile to both construct directed acyclic graphs 317 that are medium-term stable for routing and do measurements on the 318 edges such as Expected Transmission Count (ETX) [RFC6551]. Not all 319 LLNs comprise low-power nodes [I-D.hui-vasseur-roll-rpl-deployment]. 321 LLNs typically are composed of constrained nodes; this leads to the 322 design of operation modes such as the "non-storing mode" defined by 323 RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks 324 [RFC6550]). So, in the terminology of the present document, an LLN 325 is a constrained-node network with certain network characteristics, 326 which include constraints on the network as well. 328 2.3.2. LoWPAN, 6LoWPAN 330 One interesting class of a constrained network often used as a 331 constrained-node network is "LoWPAN" [RFC4919], a term inspired from 332 the name of an IEEE 802.15.4 working group (low-rate wireless 333 personal area networks (LR-WPANs)). The expansion of the LoWPAN 334 acronym, "Low-Power Wireless Personal Area Network", contains a hard- 335 to-justify "Personal" that is due to the history of task group naming 336 in IEEE 802 more than due to an orientation of LoWPANs around a 337 single person. Actually, LoWPANs have been suggested for urban 338 monitoring, control of large buildings, and industrial control 339 applications, so the "Personal" can only be considered a vestige. 340 Occasionally, the term is read as "Low-Power Wireless Area Networks" 341 [WEI]. Originally focused on IEEE 802.15.4, "LoWPAN" (or when used 342 for IPv6, "6LoWPAN") also refers to networks built from similarly 343 constrained link-layer technologies [RFC7668] [RFC8105] [RFC7428]. 345 3. Classes of Constrained Devices 347 Despite the overwhelming variety of Internet-connected devices that 348 can be envisioned, it may be worthwhile to have some succinct 349 terminology for different classes of constrained devices. 351 Before we get to that, let's first distinguish two big rough groups 352 of devices based on their CPU capabilities: 354 o Microcontroller-class devices (ARM term: "M-class" [need ref]). 355 These often (but not always) include RAM and code storage on chip 356 and limit their support for general-purpose operating systems, 357 e.g., they do not have an MMU (memory management unit). They use 358 most of their pins for interfaces to application hardware such as 359 digital in/out (the latter often PWM-controllable), ADC/DACs, etc. 360 Where this hardware is specialized for an application, we may talk 361 about "Systems on a Chip" (SOC). These devices often implement 362 elaborate sleep modes to achieve microwatt- or at least milliwatt- 363 level sustained power usage (Ps, see below). 365 o General-purpose-class devices (ARM term: "A-class"). These 366 usually have RAM and Flash storage on separate chips (not always 367 separate packages), and offer support for general-purpose 368 operating systems such as Linux, e.g. an MMU. Many of the pins on 369 the CPU chip are dedidated to interfacing with RAM and other 370 memory. Some general-purpose-class devices integrate some 371 application hardware such as video controllers, these are often 372 called "Systems on a Chip" (SOC). While these chips also include 373 sleep modes, they are usually more on the watt side of sustained 374 power usage (Ps). 376 If the distinction between these groups needs to be made in this 377 document, we distinguish group "M" (microcontroller) from group "J" 378 (general purpose). 380 In this document, the class designations in Table 1 may be used as 381 rough indications of device capabilities. Note that the classes from 382 10 upwards are not really constrained devices in the sense of the 383 previous section; they may still be useful to discuss constraints in 384 larger devices: 386 +-------+--------------+----------------+-------------+-------------+ 387 | Group | Name | data size | code size | Examples | 388 | | | (e.g., RAM) | (e.g., | | 389 | | | | Flash) | | 390 +-------+--------------+----------------+-------------+-------------+ 391 | M | Class 0, C0 | << 10 KiB | << 100 KiB | ATtiny | 392 | | | | | | 393 | M | Class 1, C1 | ~ 10 KiB | ~ 100 KiB | STM32F103CB | 394 | | | | | | 395 | M | Class 2, C2 | ~ 50 KiB | ~ 250 KiB | STM32F103RC | 396 | | | | | | 397 | M | Class 3, C3 | ~ 100 KiB | ~ 500..1000 | STM32F103RG | 398 | | | | KiB | | 399 | | | | | | 400 | M | Class 4, C4 | ~ | ~ | "Luxury" | 401 | | | 300..500..1000 | 1000...2000 | | 402 | | | KiB | KiB | | 403 | | | | | | 404 | J | Class 10, | 4-8 MiB | (?) | OpenWRT | 405 | | C10 | | | routers | 406 | | | | | | 407 | J | | fill in | ...J-group | | 408 | | | useful... | classes | | 409 | | | | | | 410 | J | Class 15, | 0.5..1 GiB | (lots) | Raspberry | 411 | | C13 | | | PI | 412 | | | | | | 413 | J | Class 16, | 1..4 GiB | (lots) | Smartphones | 414 | | C15 | | | | 415 | | | | | | 416 | J | Class 17, | 4..32 GiB | (lots) | Laptops | 417 | | C16 | | | | 418 | | | | | | 419 | J | Class 19, | (lots) | (lots) | Servers | 420 | | C19 | | | | 421 +-------+--------------+----------------+-------------+-------------+ 423 Table 1: Classes of Constrained Devices (KiB = 1024 bytes) 425 As of the writing of this document, these characteristics correspond 426 to distinguishable clusters of commercially available chips and 427 design cores for constrained devices. While it is expected that the 428 boundaries of these classes will move over time, Moore's law tends to 429 be less effective in the embedded space than in personal computing 430 devices: gains made available by increases in transistor count and 431 density are more likely to be invested in reductions of cost and 432 power requirements than into continual increases in computing power. 434 Class 0 devices are very constrained sensor-like motes. They are so 435 severely constrained in memory and processing capabilities that most 436 likely they will not have the resources required to communicate 437 directly with the Internet in a secure manner (rare heroic, narrowly 438 targeted implementation efforts notwithstanding). Class 0 devices 439 will participate in Internet communications with the help of larger 440 devices acting as proxies, gateways, or servers. Class 0 devices 441 generally cannot be secured or managed comprehensively in the 442 traditional sense. They will most likely be preconfigured (and will 443 be reconfigured rarely, if at all) with a very small data set. For 444 management purposes, they could answer keepalive signals and send on/ 445 off or basic health indications. 447 Class 1 devices are quite constrained in code space and processing 448 capabilities, such that they cannot easily talk to other Internet 449 nodes employing a full protocol stack such as using HTTP, Transport 450 Layer Security (TLS), and related security protocols and XML-based 451 data representations. However, they are capable enough to use a 452 protocol stack specifically designed for constrained nodes (such as 453 the Constrained Application Protocol (CoAP) over UDP [RFC7252]) and 454 participate in meaningful conversations without the help of a gateway 455 node. In particular, they can provide support for the security 456 functions required on a large network. Therefore, they can be 457 integrated as fully developed peers into an IP network, but they need 458 to be parsimonious with state memory, code space, and often power 459 expenditure for protocol and application usage. 461 Class 2 devices are less constrained and fundamentally capable of 462 supporting most of the same protocol stacks as used on notebooks or 463 servers. However, even these devices can benefit from lightweight 464 and energy-efficient protocols and from consuming less bandwidth. 465 Furthermore, using fewer resources for networking leaves more 466 resources available to applications. Thus, using the protocol stacks 467 defined for more constrained devices on Class 2 devices might reduce 468 development costs and increase the interoperability. 470 Constrained devices with capabilities significantly beyond Class 2 471 devices exist. They are less demanding from a standards development 472 point of view as they can largely use existing protocols unchanged. 473 The previous version of the present document therefore did not make 474 any attempt to define constrained classes beyond Class 2. These 475 devices, and to a certain extent even J-group devices, can still be 476 constrained by a limited energy supply. Class 3 and 4 devices are 477 less clearly defined than the lower classes; they are even less 478 constrained. In particular Class 4 devices are powerful enough to 479 quite comfortably run, e.g., JavaScript interpreters, together with 480 elaborate network stacks. Additional classes may need to be defined 481 based on protection capabilities, e.g., an MPU (memory protection 482 unit; true MMUs are typically only found in J-group devices). 484 With respect to examining the capabilities of constrained nodes, 485 particularly for Class 1 devices, it is important to understand what 486 type of applications they are able to run and which protocol 487 mechanisms would be most suitable. Because of memory and other 488 limitations, each specific Class 1 device might be able to support 489 only a few selected functions needed for its intended operation. In 490 other words, the set of functions that can actually be supported is 491 not static per device type: devices with similar constraints might 492 choose to support different functions. Even though Class 2 devices 493 have some more functionality available and may be able to provide a 494 more complete set of functions, they still need to be assessed for 495 the type of applications they will be running and the protocol 496 functions they would need. To be able to derive any requirements, 497 the use cases and the involvement of the devices in the application 498 and the operational scenario need to be analyzed. Use cases may 499 combine constrained devices of multiple classes as well as more 500 traditional Internet nodes. 502 3.1. Firmware/Software upgradeability 504 Platforms may differ in their firmware or software upgradeability. 505 The below is a first attempt at classifying this. 507 +------+------------------------------------------------------------+ 508 | Name | Firmware/Software upgradeability | 509 +------+------------------------------------------------------------+ 510 | F0 | no (discard for upgrade) | 511 | | | 512 | F1 | replaceable, out of service during replacement, reboot | 513 | | | 514 | F2 | patchable during operation, reboot required | 515 | | | 516 | F3 | patchable during operation, restart not visible externally | 517 | | | 518 | F9 | app-level upgradeability, no reboot required ("hitless") | 519 +------+------------------------------------------------------------+ 521 3.2. Isolation functionality 523 TBD. This section could discuss the ability of the platform to 524 isolate different components. The categories below are not mutually 525 exclusive; we need to build relevant clusters. 527 +------+-----------------------------------------------------------+ 528 | Name | Isolation functionality | 529 +------+-----------------------------------------------------------+ 530 | Is0 | no isolation | 531 | | | 532 | Is2 | MPU (memory protection unit), at least boundary registers | 533 | | | 534 | Is5 | MMU with Linux-style kernel/user | 535 | | | 536 | Is7 | Virtualization-style isolation | 537 | | | 538 | Is8 | Secure enclave isolation | 539 +------+-----------------------------------------------------------+ 541 3.3. Shielded secrets 543 Some platforms can keep shielded secrets (usually in conjuction with 544 secure enclave functionality). 546 4. Power Terminology 548 Devices not only differ in their computing capabilities but also in 549 available power and/or energy. While it is harder to find 550 recognizable clusters in this space, it is still useful to introduce 551 some common terminology. 553 4.1. Scaling Properties 555 The power and/or energy available to a device may vastly differ, from 556 kilowatts to microwatts, from essentially unlimited to hundreds of 557 microjoules. 559 Instead of defining classes or clusters, we simply state, using the 560 International System of Units (SI units), an approximate value for 561 one or both of the quantities listed in Table 2: 563 +------+--------------------------------------------------+---------+ 564 | Name | Definition | SI Unit | 565 +------+--------------------------------------------------+---------+ 566 | Ps | Sustainable average power available for the | W | 567 | | device over the time it is functioning | (Watt) | 568 | | | | 569 | Et | Total electrical energy available before the | J | 570 | | energy source is exhausted | (Joule) | 571 +------+--------------------------------------------------+---------+ 573 Table 2: Quantities Relevant to Power and Energy 575 The value of Et may need to be interpreted in conjunction with an 576 indication over which period of time the value is given; see 577 Section 4.2. 579 Some devices enter a "low-power" mode before the energy available in 580 a period is exhausted or even have multiple such steps on the way to 581 exhaustion. For these devices, Ps would need to be given for each of 582 the modes/steps. 584 4.2. Classes of Energy Limitation 586 As discussed above, some devices are limited in available energy as 587 opposed to (or in addition to) being limited in available power. 588 Where no relevant limitations exist with respect to energy, the 589 device is classified as E9. The energy limitation may be in total 590 energy available in the usable lifetime of the device (e.g., a device 591 that is discarded when its non-replaceable primary battery is 592 exhausted), classified as E2. Where the relevant limitation is for a 593 specific period, the device is classified as E1, e.g., a solar- 594 powered device with a limited amount of energy available for the 595 night, a device that is manually connected to a charger and has a 596 period of time between recharges, or a device with a periodic 597 (primary) battery replacement interval. Finally, there may be a 598 limited amount of energy available for a specific event, e.g., for a 599 button press in an energy-harvesting light switch; such devices are 600 classified as E0. Note that, in a sense, many E1 devices are also 601 E2, as the rechargeable battery has a limited number of useful 602 recharging cycles. 604 Table 3 provides a summary of the classifications described above. 606 +------+------------------------------+-----------------------------+ 607 | Name | Type of energy limitation | Example Power Source | 608 +------+------------------------------+-----------------------------+ 609 | E0 | Event energy-limited | Event-based harvesting | 610 | | | | 611 | E1 | Period energy-limited | Battery that is | 612 | | | periodically recharged or | 613 | | | replaced | 614 | | | | 615 | E2 | Lifetime energy-limited | Non-replaceable primary | 616 | | | battery | 617 | | | | 618 | E9 | No direct quantitative | Mains-powered | 619 | | limitations to available | | 620 | | energy | | 621 +------+------------------------------+-----------------------------+ 623 Table 3: Classes of Energy Limitation 625 4.3. Strategies for Using Power for Communication 627 Especially when wireless transmission is used, the radio often 628 consumes a big portion of the total energy consumed by the device. 629 Design parameters, such as the available spectrum, the desired range, 630 and the bitrate aimed for, influence the power consumed during 631 transmission and reception; the duration of transmission and 632 reception (including potential reception) influence the total energy 633 consumption. 635 Different strategies for power usage and network attachment may be 636 used, based on the type of the energy source (e.g., battery or mains- 637 powered) and the frequency with which a device needs to communicate. 639 The general strategies for power usage can be described as follows: 641 Always-on: This strategy is most applicable if there is no reason 642 for extreme measures for power saving. The device can stay on in 643 the usual manner all the time. It may be useful to employ power- 644 friendly hardware or limit the number of wireless transmissions, 645 CPU speeds, and other aspects for general power-saving and cooling 646 needs, but the device can be connected to the network all the 647 time. 649 Normally-off: Under this strategy, the device sleeps such long 650 periods at a time that once it wakes up, it makes sense for it to 651 not pretend that it has been connected to the network during 652 sleep: the device reattaches to the network as it is woken up. 653 The main optimization goal is to minimize the effort during the 654 reattachment process and any resulting application communications. 655 If the device sleeps for long periods of time and needs to 656 communicate infrequently, the relative increase in energy 657 expenditure during reattachment may be acceptable. 659 Low-power: This strategy is most applicable to devices that need to 660 operate on a very small amount of power but still need to be able 661 to communicate on a relatively frequent basis. This implies that 662 extremely low-power solutions need to be used for the hardware, 663 chosen link-layer mechanisms, and so on. Typically, given the 664 small amount of time between transmissions, despite their sleep 665 state, these devices retain some form of attachment to the 666 network. Techniques used for minimizing power usage for the 667 network communications include minimizing any work from re- 668 establishing communications after waking up and tuning the 669 frequency of communications (including "duty cycling", where 670 components are switched on and off in a regular cycle) and other 671 parameters appropriately. 673 Table 4 provides a summary of the strategies described above. 675 +------+--------------+---------------------------------------------+ 676 | Name | Strategy | Ability to communicate | 677 +------+--------------+---------------------------------------------+ 678 | P0 | Normally-off | Reattach when required | 679 | | | | 680 | P1 | Low-power | Appears connected, perhaps with high | 681 | | | latency | 682 | | | | 683 | P9 | Always-on | Always connected | 684 +------+--------------+---------------------------------------------+ 686 Table 4: Strategies of Using Power for Communication 688 Note that the discussion above is at the device level; similar 689 considerations can apply at the communications-interface level. This 690 document does not define terminology for the latter. 692 A term often used to describe power-saving approaches is "duty- 693 cycling". This describes all forms of periodically switching off 694 some function, leaving it on only for a certain percentage of time 695 (the "duty cycle"). 697 [RFC7102] only distinguishes two levels, defining a Non-Sleepy Node 698 as a node that always remains in a fully powered-on state (always 699 awake) where it has the capability to perform communication (P9) and 700 a Sleepy Node as a node that may sometimes go into a sleep mode (a 701 low-power state to conserve power) and temporarily suspend protocol 702 communication (P0); there is no explicit mention of P1. 704 4.4. Strategies of Keeping Time over Power Events 706 [This subsection is very drafty.] 708 Many applications for a device require it to keep some concept of 709 time. 711 Time-keeping can be relative to a previous event (last packet 712 received), absolute on a device-specific scale (e.g., last reboot), 713 or absolute on a world-wide scale ("wall-clock time"). 715 Some devices lose the concept of time when going to sleep: after 716 wakeup, they don't know how long they slept. Some others do keep 717 some concept of time during sleep, but not precise enough to use as a 718 basis for keeping absolute time. Some devices have a continuously 719 running source of a reasonably accurate time (often a 32,768 Hz watch 720 crystal). Finally, some devices can keep their concept of time even 721 during a battery change, e.g., by using a backup battery or a 722 supercapacitor to power the real-time clock (RTC). 724 The actual accuracy of time may vary, with errors ranging from tens 725 of percent from on-chip RC oscillators (not useful for keeping 726 absolute time, but still useful for, e.g., timing out some state) to 727 approximately 1e-4 to 1e-5 ("watch crystal") of error. More precise 728 timing is available with temperature compensated crystal oscillators 729 (TCXO). Further improvement requires significantly higher power 730 usage, bulk, fragility, and device cost, e.g. oven-controlled crystal 731 oscillators (OCXO) can reach 1e-8, and Rubidium frequency sources can 732 reach 1e-11 over the short term and 1e-9 over the long term. 734 A device may need to fire up a more accurate frequency source during 735 wireless communication, this may also allow it to keep more precise 736 time during the period. 738 The various time sources available on the device can be assisted by 739 external time input, e.g. via the network using the NTP protocol 740 [RFC5905]. Information from measuring the deviation between external 741 input and local time source can be used to increase the accuracy of 742 maintaining time even during periods of no network use. 744 Errors of the frequency source can be compensated if known 745 (calibrated against a known better source, or even predicted, e.g., 746 in a software TCXO). Even with errors partially compensated, an 747 uncertainty remains, which is the more fundamental characteristic to 748 discuss. 750 Battery solutions may allow the device to keep a wall-clock time 751 during its entire life, or the wall-clock time may need to be reset 752 after a battery change. Even devices that have a battery lasting for 753 their lifetime may not be set to wall-clock time at manufacture time, 754 possibly because the battery is only activated at installation time 755 where time sources may be questionable or because setting the clock 756 during manufacture is deemed too much effort. 758 Devices that keep a good approximation of wall-clock time during 759 their life may be in a better position to securely validate external 760 time inputs than devices that need to be reset episodically, which 761 can possibly be tricked by their environment into accepting a long- 762 past time, for instance with the intent of exploiting expired 763 security assertions such as certificates. 765 From a practical point of view, devices can be divided at least on 766 the two dimensions proposed in Table 5 and Table 6. Corrections to 767 the local time of a device performed over the network can be used to 768 improve the uncertainty exhibited by these basic device classes. 770 +------+-------------------------------+----------------------------+ 771 | Name | Type | Uncertainty (roughly) | 772 +------+-------------------------------+----------------------------+ 773 | T0 | relative time while awake | (usually high) | 774 | | | | 775 | T1 | relative time | (usually high during | 776 | | | sleep) | 777 | | | | 778 | T2 | relative time | 1e-4 or better | 779 | | | | 780 | T5 | absolute time (e.g., since | 1e-4 or better | 781 | | boot) | | 782 | | | | 783 | T7 | wall-clock time | 1e-4 or better | 784 | | | | 785 | T8 | wall-clock time | 1e-5 or better | 786 | | | | 787 | T9 | wall-clock time | 1e-6 or better (TCXO) | 788 | | | | 789 | T10 | wall-clock time | 1e-7 or better (OCXO or | 790 | | | Rb) | 791 +------+-------------------------------+----------------------------+ 793 Table 5: Strategies of Keeping Time over Power Events 795 +------+-----------------------------------+------------------------+ 796 | Name | Permanency (from type T5 | Uncertainty | 797 | | upwards): | | 798 +------+-----------------------------------+------------------------+ 799 | TP0 | time needs to be reset on certain | | 800 | | occasions | | 801 | | | | 802 | TP1 | time needs to be set during | (possibly reduced... | 803 | | installation | | 804 | | | | 805 | TP9 | reliable time is maintained | ...by using external | 806 | | during lifetime | input) | 807 +------+-----------------------------------+------------------------+ 809 Table 6: Permanency of Keeping Time 811 5. Classes of Networks 813 5.1. Classes of link layer MTU size 815 Link layer technologies used by constrained devices can be 816 categorized on the basis of link layer MTU size. Depending on this 817 parameter, the fragmentation techniques needed (if any) to support 818 the IPv6 MTU requirement may vary. 820 We define the following classes of link layer MTU size: 822 +------+---------------------+------------------------------------+ 823 | Name | L2 MTU size (bytes) | 6LoWPAN Fragmentation applicable*? | 824 +------+---------------------+------------------------------------+ 825 | S0 | 3 - 12 | need new kind of fragmentation | 826 | | | | 827 | S1 | 13 - 127 | yes | 828 | | | | 829 | S2 | 128 - 1279 | yes | 830 | | | | 831 | S2 | >= 1280 | no fragmentation needed | 832 +------+---------------------+------------------------------------+ 834 *if no link layer fragmentation is available 835 (note: 'Sx' stands for 'Size x') 837 S0 technologies require fragmentation to support the IPv6 MTU 838 requirement. If no link layer fragmentation is available, 839 fragmentation is needed at the adaptation layer below IPv6. However, 840 6LoWPAN fragmentation [RFC4944] cannot be used for these 841 technologies, given the extremely reduced link layer MTU. In this 842 case, lightweight fragmentation formats must be used (e.g. 843 [I-D.ietf-lpwan-ipv6-static-context-hc]). 845 S1 and S2 technologies require fragmentation at the subnetwork level 846 to support the IPv6 MTU requirement. If link layer fragmentation is 847 unavailable or insufficient, fragmentation is needed at the 848 adaptation layer below IPv6. 6LoWPAN fragmentation [RFC4944] can be 849 used to carry 1280-byte IPv6 packets over these technologies. 851 S3 technologies do not require fragmentation to support the IPv6 MTU 852 requirement. 854 5.2. Class of Internet Integration 856 The term "Internet of Things" is sometimes confusingly used for 857 connected devices that are not actually employing Internet 858 technology. Some devices do use Internet technology, but only use it 859 to exchange packets with a fixed communication partner ("device-to- 860 cloud" scenarios, [RFC7452]). More general devices are prepared to 861 communicate with other nodes in the Internet as well. 863 We define the following classes of Internet technology level: 865 +------+--------------------------------------+ 866 | Name | Internet technology | 867 +------+--------------------------------------+ 868 | I0 | none (local interconnect only) | 869 | | | 870 | I1 | device-to-cloud only | 871 | | | 872 | I9 | full Internet connectivity supported | 873 +------+--------------------------------------+ 875 5.3. Classes of physical layer bit rate 877 [This section is a trial balloon. We could also talk about burst 878 rate, sustained rate; bits/s, messages/s, ...] 880 Physical layer technologies used by constrained devices can be 881 categorized on the basis of physical layer (PHY) bit rate. The PHY 882 bit rate class of a technology has important implications with regard 883 to compatibility with existing protocols and mechanisms on the 884 Internet, responsiveness to frame transmissions and need for header 885 compression techniques. 887 We define the following classes of PHY bit rate: 889 +------+------------+-----------------------------------------------+ 890 | Name | PHY bit | Comment | 891 | | rate | | 892 | | (bit/s) | | 893 +------+------------+-----------------------------------------------+ 894 | B0 | < 10 | Tx time of 150-byte frame > MSL | 895 | | | | 896 | B1 | 10 - 10^3 | Unresponsiveness if human expects reaction to | 897 | | | sent frame (frame size > 62.5 byte) | 898 | | | | 899 | B2 | 10^3 - | Responsiveness if human expects reaction to | 900 | | 10^6 | sent frame, but header compression still | 901 | | | needed | 902 | | | | 903 | B3 | > 10^6 | Header compression yields relatively low | 904 | | | performance benefits | 905 +------+------------+-----------------------------------------------+ 907 (note: 'Bx' stands for 'Bit rate x') 909 B0 technologies lead to very high transmission times, which may be 910 close to or even greater than the Maximum Segment Lifetime (MSL) 911 assumed on the Internet [RFC0793]. Many Internet protocols and 912 mechanisms will fail when transmit times are greater than the MSL. 913 B0 technologies lead to a frame transmission time greater than the 914 MSL for a frame size greater than 150 bytes. 916 B1 technologies offer transmission times which are lower than the MSL 917 (for a frame size greater than 150 bytes). However, transmission 918 times for B1 technologies are still significant if a human expects a 919 reaction to the transmission of a frame. With B1 technologies, the 920 transmission time of a frame greater than 62.5 bytes exceeds 0.5 921 seconds, i.e. a threshold time beyond which any response or reaction 922 to a frame transmission will appear not to be immediate [RFC5826]. 924 B2 technologies do not incur responsiveness problems, but still 925 benefit from using header compression techniques (e.g. [RFC6282]) to 926 achieve performance improvements. 928 Over B3 technologies, the relative performance benefits of header 929 compression are low. For example, in a duty-cycled technology 930 offering B3 PHY bit rates, energy consumption decrease due to header 931 compression may be comparable with the energy consumed while in a 932 sleep interval. On the other hand, for B3 PHY bit rates, a human 933 user will not be able to perceive whether header compression has been 934 used or not in a frame transmission. 936 6. IANA Considerations 938 This document makes no requests of IANA. 940 7. Security Considerations 942 This document introduces common terminology that does not raise any 943 new security issues. Security considerations arising from the 944 constraints discussed in this document need to be discussed in the 945 context of specific protocols. For instance, Section 11.6 of 946 [RFC7252], "Constrained node considerations", discusses implications 947 of specific constraints on the security mechanisms employed. 948 [RFC7416] provides a security threat analysis for the RPL routing 949 protocol. Implementation considerations for security protocols on 950 constrained nodes are discussed in [RFC7815] and 951 [I-D.ietf-lwig-tls-minimal]. A wider view of security in 952 constrained-node networks is provided in [RFC8576]. 954 8. Informative References 956 [FALL] Fall, K., "A Delay-Tolerant Network Architecture for 957 Challenged Internets", SIGCOMM 2003, 958 DOI 10.1145/863955.863960, 2003. 960 [FIFTY-BILLION] 961 Ericsson, "More Than 50 Billion Connected Devices", 962 Ericsson White Paper 284 23-3149 Uen, February 2011, 963 . 966 [I-D.hui-vasseur-roll-rpl-deployment] 967 Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL 968 deployment experience in large scale networks", draft-hui- 969 vasseur-roll-rpl-deployment-01 (work in progress), July 970 2012. 972 [I-D.ietf-lpwan-ipv6-static-context-hc] 973 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 974 Zuniga, "Static Context Header Compression (SCHC) and 975 fragmentation for LPWAN, application to UDP/IPv6", draft- 976 ietf-lpwan-ipv6-static-context-hc-21 (work in progress), 977 July 2019. 979 [I-D.ietf-lwig-tls-minimal] 980 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 981 Guide to the (Datagram) Transport Layer Security Protocol 982 for Smart Objects and Constrained Node Networks", draft- 983 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 985 [ISQ-13] International Electrotechnical Commission, "International 986 Standard -- Quantities and units -- Part 13: Information 987 science and technology", IEC 80000-13, March 2008. 989 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 990 RFC 793, DOI 10.17487/RFC0793, September 1981, 991 . 993 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 994 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 995 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 996 April 2007, . 998 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 999 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1000 Overview, Assumptions, Problem Statement, and Goals", 1001 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1002 . 1004 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1005 "Transmission of IPv6 Packets over IEEE 802.15.4 1006 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1007 . 1009 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1010 Routing Requirements in Low-Power and Lossy Networks", 1011 RFC 5826, DOI 10.17487/RFC5826, April 2010, 1012 . 1014 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1015 "Network Time Protocol Version 4: Protocol and Algorithms 1016 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1017 . 1019 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1020 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1021 DOI 10.17487/RFC6282, September 2011, 1022 . 1024 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1025 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1026 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1027 Low-Power and Lossy Networks", RFC 6550, 1028 DOI 10.17487/RFC6550, March 2012, 1029 . 1031 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1032 and D. Barthel, "Routing Metrics Used for Path Calculation 1033 in Low-Power and Lossy Networks", RFC 6551, 1034 DOI 10.17487/RFC6551, March 2012, 1035 . 1037 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1038 Statement and Requirements for IPv6 over Low-Power 1039 Wireless Personal Area Network (6LoWPAN) Routing", 1040 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1041 . 1043 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1044 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1045 2014, . 1047 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1048 Constrained-Node Networks", RFC 7228, 1049 DOI 10.17487/RFC7228, May 2014, 1050 . 1052 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1053 Application Protocol (CoAP)", RFC 7252, 1054 DOI 10.17487/RFC7252, June 2014, 1055 . 1057 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1058 and M. Richardson, Ed., "A Security Threat Analysis for 1059 the Routing Protocol for Low-Power and Lossy Networks 1060 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1061 . 1063 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1064 over ITU-T G.9959 Networks", RFC 7428, 1065 DOI 10.17487/RFC7428, February 2015, 1066 . 1068 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1069 "Architectural Considerations in Smart Object Networking", 1070 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1071 . 1073 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1074 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1075 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1076 . 1078 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 1079 (IKEv2) Initiator Implementation", RFC 7815, 1080 DOI 10.17487/RFC7815, March 2016, 1081 . 1083 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1084 M., and D. Barthel, "Transmission of IPv6 Packets over 1085 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1086 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1087 2017, . 1089 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1090 Things (IoT) Security: State of the Art and Challenges", 1091 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1092 . 1094 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 1095 Internet", Wiley-Blackwell monograph, 1096 DOI 10.1002/9780470686218, ISBN 9780470747995, 2009. 1098 Acknowledgements 1100 TBD 1102 Authors' Addresses 1104 Carsten Bormann 1105 Universitaet Bremen TZI 1106 Postfach 330440 1107 Bremen D-28359 1108 Germany 1110 Phone: +49-421-218-63921 1111 EMail: cabo@tzi.org 1113 Mehmet Ersue 1114 Nokia Solutions and Networks 1115 St.-Martinstrasse 76 1116 Munich 81541 1117 Germany 1119 Phone: +49 172 8432301 1120 EMail: mehmet.ersue@nsn.com 1122 Ari Keranen 1123 Ericsson 1124 Hirsalantie 11 1125 Jorvas 02420 1126 Finland 1128 EMail: ari.keranen@ericsson.com 1130 Carles Gomez 1131 UPC/i2CAT 1132 Escola d'Enginyeria de Telecomunicacio i Aeroespacial 1133 de Castelldefels 1134 C/Esteve Terradas, 7 1135 Castelldefels 08860 1136 Spain 1138 Phone: +34-93-413-7206 1139 EMail: carlesgo@entel.upc.edu