idnits 2.17.1 draft-bormann-lwig-7228bis-04.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 (March 11, 2019) is 1873 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-18 -- 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: September 12, 2019 Nokia Solutions and Networks 6 A. Keranen 7 Ericsson 8 C. Gomez 9 UPC/i2CAT 10 March 11, 2019 12 Terminology for Constrained-Node Networks 13 draft-bormann-lwig-7228bis-04 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 September 12, 2019. 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 5. Classes of Networks . . . . . . . . . . . . . . . . . . . . . 16 74 5.1. Classes of link layer MTU size . . . . . . . . . . . . . 16 75 5.2. Class of Internet Integration . . . . . . . . . . . . . . 17 76 5.3. Classes of physical layer bit rate . . . . . . . . . . . 17 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 8. Informative References . . . . . . . . . . . . . . . . . . . 19 80 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 Small devices with limited CPU, memory, and power resources, so- 86 called "constrained devices" (often used as sensors/actuators, smart 87 objects, or smart devices) can form a network, becoming "constrained 88 nodes" in that network. Such a network may itself exhibit 89 constraints, e.g., with unreliable or lossy channels, limited and 90 unpredictable bandwidth, and a highly dynamic topology. 92 Constrained devices might be in charge of gathering information in 93 diverse settings, including natural ecosystems, buildings, and 94 factories, and sending the information to one or more server 95 stations. They might also act on information, by performing some 96 physical action, including displaying it. Constrained devices may 97 work under severe resource constraints such as limited battery and 98 computing power, little memory, and insufficient wireless bandwidth 99 and ability to communicate; these constraints often exacerbate each 100 other. Other entities on the network, e.g., a base station or 101 controlling server, might have more computational and communication 102 resources and could support the interaction between the constrained 103 devices and applications in more traditional networks. 105 Today, diverse sizes of constrained devices with different resources 106 and capabilities are becoming connected. Mobile personal gadgets, 107 building-automation devices, cellular phones, machine-to-machine 108 (M2M) devices, and other devices benefit from interacting with other 109 "things" nearby or somewhere in the Internet. With this, the 110 Internet of Things (IoT) becomes a reality, built up out of uniquely 111 identifiable and addressable objects (things). Over the next decade, 112 this could grow to large numbers [FIFTY-BILLION] of Internet- 113 connected constrained devices, greatly increasing the Internet's size 114 and scope. 116 The present document provides a number of basic terms that have been 117 useful in the standardization work for constrained environments. The 118 intention is not to exhaustively cover the field but to make sure a 119 few core terms are used consistently between different groups 120 cooperating in this space. 122 The present document is an update of [RFC7228]. 124 In this document, the term "byte" is used in its now customary sense 125 as a synonym for "octet". Where sizes of semiconductor memory are 126 given, the prefix "kibi" (1024) is combined with "byte" to 127 "kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13]. 129 In computing, the term "power" is often used for the concept of 130 "computing power" or "processing power", as in CPU performance. In 131 this document, the term stands for electrical power unless explicitly 132 stated otherwise. "Mains-powered" is used as a shorthand for being 133 permanently connected to a stable electrical power grid. 135 2. Core Terminology 137 There are two important aspects to _scaling_ within the Internet of 138 Things: 140 o scaling up Internet technologies to a large number [FIFTY-BILLION] 141 of inexpensive nodes, while 143 o scaling down the characteristics of each of these nodes and of the 144 networks being built out of them, to make this scaling up 145 economically and physically viable. 147 The need for scaling down the characteristics of nodes leads to 148 "constrained nodes". 150 2.1. Constrained Nodes 152 The term "constrained node" is best defined by contrasting the 153 characteristics of a constrained node with certain widely held 154 expectations on more familiar Internet nodes: 156 Constrained Node: A node where some of the characteristics that are 157 otherwise pretty much taken for granted for Internet nodes at the 158 time of writing are not attainable, often due to cost constraints 159 and/or physical constraints on characteristics such as size, 160 weight, and available power and energy. The tight limits on 161 power, memory, and processing resources lead to hard upper bounds 162 on state, code space, and processing cycles, making optimization 163 of energy and network bandwidth usage a dominating consideration 164 in all design requirements. Also, some layer-2 services such as 165 full connectivity and broadcast/multicast may be lacking. 167 While this is not a rigorous definition, it is grounded in the state 168 of the art and clearly sets apart constrained nodes from server 169 systems, desktop or laptop computers, powerful mobile devices such as 170 smartphones, etc. There may be many design considerations that lead 171 to these constraints, including cost, size, weight, and other scaling 172 factors. 174 (An alternative term, when the properties as a network node are not 175 in focus, is "constrained device".) 177 There are multiple facets to the constraints on nodes, often applying 178 in combination, for example: 180 o constraints on the maximum code complexity (ROM/Flash), 182 o constraints on the size of state and buffers (RAM), 184 o constraints on the amount of computation feasible in a period of 185 time ("processing power"), 187 o constraints on the available power, and 189 o constraints on user interface and accessibility in deployment 190 (ability to set keys, update software, etc.). 192 Section 3 defines a small number of interesting classes ("class-N" 193 for N = 0, 1, 2) of constrained nodes focusing on relevant 194 combinations of the first two constraints. With respect to available 195 power, [RFC6606] distinguishes "power-affluent" nodes (mains-powered 196 or regularly recharged) from "power-constrained nodes" that draw 197 their power from primary batteries or by using energy harvesting; 198 more detailed power terminology is given in Section 4. 200 The use of constrained nodes in networks often also leads to 201 constraints on the networks themselves. However, there may also be 202 constraints on networks that are largely independent from those of 203 the nodes. We therefore distinguish "constrained networks" from 204 "constrained-node networks". 206 2.2. Constrained Networks 208 We define "constrained network" in a similar way: 210 Constrained Network: A network where some of the characteristics 211 pretty much taken for granted with link layers in common use in 212 the Internet at the time of writing are not attainable. 214 Constraints may include: 216 o low achievable bitrate/throughput (including limits on duty 217 cycle), 219 o high packet loss and high variability of packet loss (delivery 220 rate), 222 o highly asymmetric link characteristics, 224 o severe penalties for using larger packets (e.g., high packet loss 225 due to link-layer fragmentation), 227 o limits on reachability over time (a substantial number of devices 228 may power off at any point in time but periodically "wake up" and 229 can communicate for brief periods of time), and 231 o lack of (or severe constraints on) advanced services such as IP 232 multicast. 234 More generally, we speak of constrained networks whenever at least 235 some of the nodes involved in the network exhibit these 236 characteristics. 238 Again, there may be several reasons for this: 240 o cost constraints on the network, 242 o constraints posed by the nodes (for constrained-node networks), 244 o physical constraints (e.g., power constraints, environmental 245 constraints, media constraints such as underwater operation, 246 limited spectrum for very high density, electromagnetic 247 compatibility), 249 o regulatory constraints, such as very limited spectrum availability 250 (including limits on effective radiated power and duty cycle) or 251 explosion safety, and 253 o technology constraints, such as older and lower-speed technologies 254 that are still operational and may need to stay in use for some 255 more time. 257 2.2.1. Challenged Networks 259 A constrained network is not necessarily a "challenged network" 260 [FALL]: 262 Challenged Network: A network that has serious trouble maintaining 263 what an application would today expect of the end-to-end IP model, 264 e.g., by: 266 * not being able to offer end-to-end IP connectivity at all, 268 * exhibiting serious interruptions in end-to-end IP connectivity, 269 or 271 * exhibiting delay well beyond the Maximum Segment Lifetime (MSL) 272 defined by TCP [RFC0793]. 274 All challenged networks are constrained networks in some sense, but 275 not all constrained networks are challenged networks. There is no 276 well-defined boundary between the two, though. Delay-Tolerant 277 Networking (DTN) has been designed to cope with challenged networks 278 [RFC4838]. 280 2.3. Constrained-Node Networks 282 Constrained-Node Network: A network whose characteristics are 283 influenced by being composed of a significant portion of 284 constrained nodes. 286 A constrained-node network always is a constrained network because of 287 the network constraints stemming from the node constraints, but it 288 may also have other constraints that already make it a constrained 289 network. 291 The rest of this subsection introduces two additional terms that are 292 in active use in the area of constrained-node networks, without an 293 intent to define them: LLN and (6)LoWPAN. 295 2.3.1. LLN 297 A related term that has been used to describe the focus of the IETF 298 ROLL working group is "Low-Power and Lossy Network (LLN)". The ROLL 299 (Routing Over Low-Power and Lossy) terminology document [RFC7102] 300 defines LLNs as follows: 302 LLN: Low-Power and Lossy Network. Typically composed of many 303 embedded devices with limited power, memory, and processing 304 resources interconnected by a variety of links, such as IEEE 305 802.15.4 or low-power Wi-Fi. There is a wide scope of application 306 areas for LLNs, including industrial monitoring, building 307 automation (heating, ventilation, and air conditioning (HVAC), 308 lighting, access control, fire), connected home, health care, 309 environmental monitoring, urban sensor networks, energy 310 management, assets tracking, and refrigeration. 312 Beyond that, LLNs often exhibit considerable loss at the physical 313 layer, with significant variability of the delivery rate, and some 314 short-term unreliability, coupled with some medium-term stability 315 that makes it worthwhile to both construct directed acyclic graphs 316 that are medium-term stable for routing and do measurements on the 317 edges such as Expected Transmission Count (ETX) [RFC6551]. Not all 318 LLNs comprise low-power nodes [I-D.hui-vasseur-roll-rpl-deployment]. 320 LLNs typically are composed of constrained nodes; this leads to the 321 design of operation modes such as the "non-storing mode" defined by 322 RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks 323 [RFC6550]). So, in the terminology of the present document, an LLN 324 is a constrained-node network with certain network characteristics, 325 which include constraints on the network as well. 327 2.3.2. LoWPAN, 6LoWPAN 329 One interesting class of a constrained network often used as a 330 constrained-node network is "LoWPAN" [RFC4919], a term inspired from 331 the name of an IEEE 802.15.4 working group (low-rate wireless 332 personal area networks (LR-WPANs)). The expansion of the LoWPAN 333 acronym, "Low-Power Wireless Personal Area Network", contains a hard- 334 to-justify "Personal" that is due to the history of task group naming 335 in IEEE 802 more than due to an orientation of LoWPANs around a 336 single person. Actually, LoWPANs have been suggested for urban 337 monitoring, control of large buildings, and industrial control 338 applications, so the "Personal" can only be considered a vestige. 339 Occasionally, the term is read as "Low-Power Wireless Area Networks" 340 [WEI]. Originally focused on IEEE 802.15.4, "LoWPAN" (or when used 341 for IPv6, "6LoWPAN") also refers to networks built from similarly 342 constrained link-layer technologies [RFC7668] [RFC8105] [RFC7428]. 344 3. Classes of Constrained Devices 346 Despite the overwhelming variety of Internet-connected devices that 347 can be envisioned, it may be worthwhile to have some succinct 348 terminology for different classes of constrained devices. 350 Before we get to that, let's first distinguish two big rough groups 351 of devices based on their CPU capabilities: 353 o Microcontroller-class devices (ARM term: "M-class" [need ref]). 354 These often (but not always) include RAM and code storage on chip 355 and limit their support for general-purpose operating systems, 356 e.g., they do not have an MMU (memory management unit). They use 357 most of their pins for interfaces to application hardware such as 358 digital in/out (the latter often PWM-controllable), ADC/DACs, etc. 359 Where this hardware is specialized for an application, we may talk 360 about "Systems on a Chip" (SOC). These devices often implement 361 elaborate sleep modes to achieve microwatt- or at least milliwatt- 362 level sustained power usage (Ps, see below). 364 o General-purpose-class devices (ARM term: "A-class"). These 365 usually have RAM and Flash storage on separate chips (not always 366 separate packages), and offer support for general-purpose 367 operating systems such as Linux, e.g. an MMU. Many of the pins on 368 the CPU chip are dedidated to interfacing with RAM and other 369 memory. Some general-purpose-class devices integrate some 370 application hardware such as video controllers, these are often 371 called "Systems on a Chip" (SOC). While these chips also include 372 sleep modes, they are usually more on the watt side of sustained 373 power usage (Ps). 375 If the distinction between these groups needs to be made in this 376 document, we distinguish group "M" (microcontroller) from group "J" 377 (general purpose). 379 In this document, the class designations in Table 1 may be used as 380 rough indications of device capabilities. Note that the classes from 381 10 upwards are not really constrained devices in the sense of the 382 previous section; they may still be useful to discuss constraints in 383 larger devices: 385 +-------+--------------+----------------+-------------+-------------+ 386 | Group | Name | data size | code size | Examples | 387 | | | (e.g., RAM) | (e.g., | | 388 | | | | Flash) | | 389 +-------+--------------+----------------+-------------+-------------+ 390 | M | Class 0, C0 | << 10 KiB | << 100 KiB | ATtiny | 391 | | | | | | 392 | M | Class 1, C1 | ~ 10 KiB | ~ 100 KiB | STM32F103CB | 393 | | | | | | 394 | M | Class 2, C2 | ~ 50 KiB | ~ 250 KiB | STM32F103RC | 395 | | | | | | 396 | M | Class 3, C3 | ~ 100 KiB | ~ 500..1000 | STM32F103RG | 397 | | | | KiB | | 398 | | | | | | 399 | M | Class 4, C4 | ~ | ~ | "Luxury" | 400 | | | 300..500..1000 | 1000...2000 | | 401 | | | KiB | KiB | | 402 | | | | | | 403 | J | Class 10, | 4-8 MiB | (?) | OpenWRT | 404 | | C10 | | | routers | 405 | | | | | | 406 | J | | fill in | ...J-group | | 407 | | | useful... | classes | | 408 | | | | | | 409 | J | Class 15, | 0.5..1 GiB | (lots) | Raspberry | 410 | | C13 | | | PI | 411 | | | | | | 412 | J | Class 16, | 1..4 GiB | (lots) | Smartphones | 413 | | C15 | | | | 414 | | | | | | 415 | J | Class 17, | 4..32 GiB | (lots) | Laptops | 416 | | C16 | | | | 417 | | | | | | 418 | J | Class 19, | (lots) | (lots) | Servers | 419 | | C19 | | | | 420 +-------+--------------+----------------+-------------+-------------+ 422 Table 1: Classes of Constrained Devices (KiB = 1024 bytes) 424 As of the writing of this document, these characteristics correspond 425 to distinguishable clusters of commercially available chips and 426 design cores for constrained devices. While it is expected that the 427 boundaries of these classes will move over time, Moore's law tends to 428 be less effective in the embedded space than in personal computing 429 devices: gains made available by increases in transistor count and 430 density are more likely to be invested in reductions of cost and 431 power requirements than into continual increases in computing power. 433 Class 0 devices are very constrained sensor-like motes. They are so 434 severely constrained in memory and processing capabilities that most 435 likely they will not have the resources required to communicate 436 directly with the Internet in a secure manner (rare heroic, narrowly 437 targeted implementation efforts notwithstanding). Class 0 devices 438 will participate in Internet communications with the help of larger 439 devices acting as proxies, gateways, or servers. Class 0 devices 440 generally cannot be secured or managed comprehensively in the 441 traditional sense. They will most likely be preconfigured (and will 442 be reconfigured rarely, if at all) with a very small data set. For 443 management purposes, they could answer keepalive signals and send on/ 444 off or basic health indications. 446 Class 1 devices are quite constrained in code space and processing 447 capabilities, such that they cannot easily talk to other Internet 448 nodes employing a full protocol stack such as using HTTP, Transport 449 Layer Security (TLS), and related security protocols and XML-based 450 data representations. However, they are capable enough to use a 451 protocol stack specifically designed for constrained nodes (such as 452 the Constrained Application Protocol (CoAP) over UDP [RFC7252]) and 453 participate in meaningful conversations without the help of a gateway 454 node. In particular, they can provide support for the security 455 functions required on a large network. Therefore, they can be 456 integrated as fully developed peers into an IP network, but they need 457 to be parsimonious with state memory, code space, and often power 458 expenditure for protocol and application usage. 460 Class 2 devices are less constrained and fundamentally capable of 461 supporting most of the same protocol stacks as used on notebooks or 462 servers. However, even these devices can benefit from lightweight 463 and energy-efficient protocols and from consuming less bandwidth. 464 Furthermore, using fewer resources for networking leaves more 465 resources available to applications. Thus, using the protocol stacks 466 defined for more constrained devices on Class 2 devices might reduce 467 development costs and increase the interoperability. 469 Constrained devices with capabilities significantly beyond Class 2 470 devices exist. They are less demanding from a standards development 471 point of view as they can largely use existing protocols unchanged. 472 The previous version of the present document therefore did not make 473 any attempt to define constrained classes beyond Class 2. These 474 devices, and to a certain extent even J-group devices, can still be 475 constrained by a limited energy supply. Class 3 and 4 devices are 476 less clearly defined than the lower classes; they are even less 477 constrained. In particular Class 4 devices are powerful enough to 478 quite comfortably run, e.g., JavaScript interpreters, together with 479 elaborate network stacks. Additional classes may need to be defined 480 based on protection capabilities, e.g., an MPU (memory protection 481 unit; true MMUs are typically only found in J-group devices). 483 With respect to examining the capabilities of constrained nodes, 484 particularly for Class 1 devices, it is important to understand what 485 type of applications they are able to run and which protocol 486 mechanisms would be most suitable. Because of memory and other 487 limitations, each specific Class 1 device might be able to support 488 only a few selected functions needed for its intended operation. In 489 other words, the set of functions that can actually be supported is 490 not static per device type: devices with similar constraints might 491 choose to support different functions. Even though Class 2 devices 492 have some more functionality available and may be able to provide a 493 more complete set of functions, they still need to be assessed for 494 the type of applications they will be running and the protocol 495 functions they would need. To be able to derive any requirements, 496 the use cases and the involvement of the devices in the application 497 and the operational scenario need to be analyzed. Use cases may 498 combine constrained devices of multiple classes as well as more 499 traditional Internet nodes. 501 3.1. Firmware/Software upgradeability 503 Platforms may differ in their firmware or software upgradeability. 504 The below is a first attempt at classifying this. 506 +------+------------------------------------------------------------+ 507 | Name | Firmware/Software upgradeability | 508 +------+------------------------------------------------------------+ 509 | F0 | no (discard for upgrade) | 510 | | | 511 | F1 | replaceable, out of service during replacement, reboot | 512 | | | 513 | F2 | patchable during operation, reboot required | 514 | | | 515 | F3 | patchable during operation, restart not visible externally | 516 | | | 517 | F9 | app-level upgradeability, no reboot required ("hitless") | 518 +------+------------------------------------------------------------+ 520 3.2. Isolation functionality 522 TBD. This section could discuss the ability of the platform to 523 isolate different components. The categories below are not mutually 524 exclusive; we need to build relevant clusters. 526 +------+-----------------------------------------------------------+ 527 | Name | Isolation functionality | 528 +------+-----------------------------------------------------------+ 529 | Is0 | no isolation | 530 | | | 531 | Is2 | MPU (memory protection unit), at least boundary registers | 532 | | | 533 | Is5 | MMU with Linux-style kernel/user | 534 | | | 535 | Is7 | Virtualization-style isolation | 536 | | | 537 | Is8 | Secure enclave isolation | 538 +------+-----------------------------------------------------------+ 540 3.3. Shielded secrets 542 Some platforms can keep shielded secrets (usually in conjuction with 543 secure enclave functionality). 545 4. Power Terminology 547 Devices not only differ in their computing capabilities but also in 548 available power and/or energy. While it is harder to find 549 recognizable clusters in this space, it is still useful to introduce 550 some common terminology. 552 4.1. Scaling Properties 554 The power and/or energy available to a device may vastly differ, from 555 kilowatts to microwatts, from essentially unlimited to hundreds of 556 microjoules. 558 Instead of defining classes or clusters, we simply state, using the 559 International System of Units (SI units), an approximate value for 560 one or both of the quantities listed in Table 2: 562 +------+--------------------------------------------------+---------+ 563 | Name | Definition | SI Unit | 564 +------+--------------------------------------------------+---------+ 565 | Ps | Sustainable average power available for the | W | 566 | | device over the time it is functioning | (Watt) | 567 | | | | 568 | Et | Total electrical energy available before the | J | 569 | | energy source is exhausted | (Joule) | 570 +------+--------------------------------------------------+---------+ 572 Table 2: Quantities Relevant to Power and Energy 574 The value of Et may need to be interpreted in conjunction with an 575 indication over which period of time the value is given; see 576 Section 4.2. 578 Some devices enter a "low-power" mode before the energy available in 579 a period is exhausted or even have multiple such steps on the way to 580 exhaustion. For these devices, Ps would need to be given for each of 581 the modes/steps. 583 4.2. Classes of Energy Limitation 585 As discussed above, some devices are limited in available energy as 586 opposed to (or in addition to) being limited in available power. 587 Where no relevant limitations exist with respect to energy, the 588 device is classified as E9. The energy limitation may be in total 589 energy available in the usable lifetime of the device (e.g., a device 590 that is discarded when its non-replaceable primary battery is 591 exhausted), classified as E2. Where the relevant limitation is for a 592 specific period, the device is classified as E1, e.g., a solar- 593 powered device with a limited amount of energy available for the 594 night, a device that is manually connected to a charger and has a 595 period of time between recharges, or a device with a periodic 596 (primary) battery replacement interval. Finally, there may be a 597 limited amount of energy available for a specific event, e.g., for a 598 button press in an energy-harvesting light switch; such devices are 599 classified as E0. Note that, in a sense, many E1 devices are also 600 E2, as the rechargeable battery has a limited number of useful 601 recharging cycles. 603 Table 3 provides a summary of the classifications described above. 605 +------+------------------------------+-----------------------------+ 606 | Name | Type of energy limitation | Example Power Source | 607 +------+------------------------------+-----------------------------+ 608 | E0 | Event energy-limited | Event-based harvesting | 609 | | | | 610 | E1 | Period energy-limited | Battery that is | 611 | | | periodically recharged or | 612 | | | replaced | 613 | | | | 614 | E2 | Lifetime energy-limited | Non-replaceable primary | 615 | | | battery | 616 | | | | 617 | E9 | No direct quantitative | Mains-powered | 618 | | limitations to available | | 619 | | energy | | 620 +------+------------------------------+-----------------------------+ 622 Table 3: Classes of Energy Limitation 624 4.3. Strategies for Using Power for Communication 626 Especially when wireless transmission is used, the radio often 627 consumes a big portion of the total energy consumed by the device. 628 Design parameters, such as the available spectrum, the desired range, 629 and the bitrate aimed for, influence the power consumed during 630 transmission and reception; the duration of transmission and 631 reception (including potential reception) influence the total energy 632 consumption. 634 Different strategies for power usage and network attachment may be 635 used, based on the type of the energy source (e.g., battery or mains- 636 powered) and the frequency with which a device needs to communicate. 638 The general strategies for power usage can be described as follows: 640 Always-on: This strategy is most applicable if there is no reason 641 for extreme measures for power saving. The device can stay on in 642 the usual manner all the time. It may be useful to employ power- 643 friendly hardware or limit the number of wireless transmissions, 644 CPU speeds, and other aspects for general power-saving and cooling 645 needs, but the device can be connected to the network all the 646 time. 648 Normally-off: Under this strategy, the device sleeps such long 649 periods at a time that once it wakes up, it makes sense for it to 650 not pretend that it has been connected to the network during 651 sleep: the device reattaches to the network as it is woken up. 652 The main optimization goal is to minimize the effort during the 653 reattachment process and any resulting application communications. 654 If the device sleeps for long periods of time and needs to 655 communicate infrequently, the relative increase in energy 656 expenditure during reattachment may be acceptable. 658 Low-power: This strategy is most applicable to devices that need to 659 operate on a very small amount of power but still need to be able 660 to communicate on a relatively frequent basis. This implies that 661 extremely low-power solutions need to be used for the hardware, 662 chosen link-layer mechanisms, and so on. Typically, given the 663 small amount of time between transmissions, despite their sleep 664 state, these devices retain some form of attachment to the 665 network. Techniques used for minimizing power usage for the 666 network communications include minimizing any work from re- 667 establishing communications after waking up and tuning the 668 frequency of communications (including "duty cycling", where 669 components are switched on and off in a regular cycle) and other 670 parameters appropriately. 672 Table 4 provides a summary of the strategies described above. 674 +------+--------------+---------------------------------------------+ 675 | Name | Strategy | Ability to communicate | 676 +------+--------------+---------------------------------------------+ 677 | P0 | Normally-off | Reattach when required | 678 | | | | 679 | P1 | Low-power | Appears connected, perhaps with high | 680 | | | latency | 681 | | | | 682 | P9 | Always-on | Always connected | 683 +------+--------------+---------------------------------------------+ 685 Table 4: Strategies of Using Power for Communication 687 Note that the discussion above is at the device level; similar 688 considerations can apply at the communications-interface level. This 689 document does not define terminology for the latter. 691 A term often used to describe power-saving approaches is "duty- 692 cycling". This describes all forms of periodically switching off 693 some function, leaving it on only for a certain percentage of time 694 (the "duty cycle"). 696 [RFC7102] only distinguishes two levels, defining a Non-Sleepy Node 697 as a node that always remains in a fully powered-on state (always 698 awake) where it has the capability to perform communication (P9) and 699 a Sleepy Node as a node that may sometimes go into a sleep mode (a 700 low-power state to conserve power) and temporarily suspend protocol 701 communication (P0); there is no explicit mention of P1. 703 5. Classes of Networks 705 5.1. Classes of link layer MTU size 707 Link layer technologies used by constrained devices can be 708 categorized on the basis of link layer MTU size. Depending on this 709 parameter, the fragmentation techniques needed (if any) to support 710 the IPv6 MTU requirement may vary. 712 We define the following classes of link layer MTU size: 714 +------+---------------------+------------------------------------+ 715 | Name | L2 MTU size (bytes) | 6LoWPAN Fragmentation applicable*? | 716 +------+---------------------+------------------------------------+ 717 | S0 | 3 - 12 | need new kind of fragmentation | 718 | | | | 719 | S1 | 13 - 127 | yes | 720 | | | | 721 | S2 | 128 - 1279 | yes | 722 | | | | 723 | S2 | >= 1280 | no fragmentation needed | 724 +------+---------------------+------------------------------------+ 726 *if no link layer fragmentation is available 727 (note: 'Sx' stands for 'Size x') 729 S0 technologies require fragmentation to support the IPv6 MTU 730 requirement. If no link layer fragmentation is available, 731 fragmentation is needed at the adaptation layer below IPv6. However, 732 6LoWPAN fragmentation [RFC4944] cannot be used for these 733 technologies, given the extremely reduced link layer MTU. In this 734 case, lightweight fragmentation formats must be used (e.g. 735 [I-D.ietf-lpwan-ipv6-static-context-hc]). 737 S1 and S2 technologies require fragmentation at the subnetwork level 738 to support the IPv6 MTU requirement. If link layer fragmentation is 739 unavailable or insufficient, fragmentation is needed at the 740 adaptation layer below IPv6. 6LoWPAN fragmentation [RFC4944] can be 741 used to carry 1280-byte IPv6 packets over these technologies. 743 S3 technologies do not require fragmentation to support the IPv6 MTU 744 requirement. 746 5.2. Class of Internet Integration 748 The term "Internet of Things" is sometimes confusingly used for 749 connected devices that are not actually employing Internet 750 technology. Some devices do use Internet technology, but only use it 751 to exchange packets with a fixed communication partner ("device-to- 752 cloud" scenarios, [RFC7452]). More general devices are prepared to 753 communicate with other nodes in the Internet as well. 755 We define the following classes of Internet technology level: 757 +------+--------------------------------------+ 758 | Name | Internet technology | 759 +------+--------------------------------------+ 760 | I0 | none (local interconnect only) | 761 | | | 762 | I1 | device-to-cloud only | 763 | | | 764 | I9 | full Internet connectivity supported | 765 +------+--------------------------------------+ 767 5.3. Classes of physical layer bit rate 769 [This section is a trial balloon. We could also talk about burst 770 rate, sustained rate; bits/s, messages/s, ...] 772 Physical layer technologies used by constrained devices can be 773 categorized on the basis of physical layer (PHY) bit rate. The PHY 774 bit rate class of a technology has important implications with regard 775 to compatibility with existing protocols and mechanisms on the 776 Internet, responsiveness to frame transmissions and need for header 777 compression techniques. 779 We define the following classes of PHY bit rate: 781 +------+------------+-----------------------------------------------+ 782 | Name | PHY bit | Comment | 783 | | rate | | 784 | | (bit/s) | | 785 +------+------------+-----------------------------------------------+ 786 | B0 | < 10 | Tx time of 150-byte frame > MSL | 787 | | | | 788 | B1 | 10 - 10^3 | Unresponsiveness if human expects reaction to | 789 | | | sent frame (frame size > 62.5 byte) | 790 | | | | 791 | B2 | 10^3 - | Responsiveness if human expects reaction to | 792 | | 10^6 | sent frame, but header compression still | 793 | | | needed | 794 | | | | 795 | B3 | > 10^6 | Header compression yields relatively low | 796 | | | performance benefits | 797 +------+------------+-----------------------------------------------+ 799 (note: 'Bx' stands for 'Bit rate x') 801 B0 technologies lead to very high transmission times, which may be 802 close to or even greater than the Maximum Segment Lifetime (MSL) 803 assumed on the Internet [RFC0793]. Many Internet protocols and 804 mechanisms will fail when transmit times are greater than the MSL. 805 B0 technologies lead to a frame transmission time greater than the 806 MSL for a frame size greater than 150 bytes. 808 B1 technologies offer transmission times which are lower than the MSL 809 (for a frame size greater than 150 bytes). However, transmission 810 times for B1 technologies are still significant if a human expects a 811 reaction to the transmission of a frame. With B1 technologies, the 812 transmission time of a frame greater than 62.5 bytes exceeds 0.5 813 seconds, i.e. a threshold time beyond which any response or reaction 814 to a frame transmission will appear not to be immediate [RFC5826]. 816 B2 technologies do not incur responsiveness problems, but still 817 benefit from using header compression techniques (e.g. [RFC6282]) to 818 achieve performance improvements. 820 Over B3 technologies, the relative performance benefits of header 821 compression are low. For example, in a duty-cycled technology 822 offering B3 PHY bit rates, energy consumption decrease due to header 823 compression may be comparable with the energy consumed while in a 824 sleep interval. On the other hand, for B3 PHY bit rates, a human 825 user will not be able to perceive whether header compression has been 826 used or not in a frame transmission. 828 6. IANA Considerations 830 This document makes no requests of IANA. 832 7. Security Considerations 834 This document introduces common terminology that does not raise any 835 new security issues. Security considerations arising from the 836 constraints discussed in this document need to be discussed in the 837 context of specific protocols. For instance, Section 11.6 of 838 [RFC7252], "Constrained node considerations", discusses implications 839 of specific constraints on the security mechanisms employed. 840 [RFC7416] provides a security threat analysis for the RPL routing 841 protocol. Implementation considerations for security protocols on 842 constrained nodes are discussed in [RFC7815] and 843 [I-D.ietf-lwig-tls-minimal]. A wider view of security in 844 constrained-node networks is provided in 845 [I-D.irtf-t2trg-iot-seccons]. 847 8. Informative References 849 [FALL] Fall, K., "A Delay-Tolerant Network Architecture for 850 Challenged Internets", SIGCOMM 2003, 851 DOI 10.1145/863955.863960, 2003. 853 [FIFTY-BILLION] 854 Ericsson, "More Than 50 Billion Connected Devices", 855 Ericsson White Paper 284 23-3149 Uen, February 2011, 856 . 859 [I-D.hui-vasseur-roll-rpl-deployment] 860 Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL 861 deployment experience in large scale networks", draft-hui- 862 vasseur-roll-rpl-deployment-01 (work in progress), July 863 2012. 865 [I-D.ietf-lpwan-ipv6-static-context-hc] 866 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 867 Zuniga, "LPWAN Static Context Header Compression (SCHC) 868 and fragmentation for IPv6 and UDP", draft-ietf-lpwan- 869 ipv6-static-context-hc-18 (work in progress), December 870 2018. 872 [I-D.ietf-lwig-tls-minimal] 873 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 874 Guide to the (Datagram) Transport Layer Security Protocol 875 for Smart Objects and Constrained Node Networks", draft- 876 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 878 [I-D.irtf-t2trg-iot-seccons] 879 Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- 880 the-Art and Challenges for the Internet of Things 881 Security", draft-irtf-t2trg-iot-seccons-16 (work in 882 progress), December 2018. 884 [ISQ-13] International Electrotechnical Commission, "International 885 Standard -- Quantities and units -- Part 13: Information 886 science and technology", IEC 80000-13, March 2008. 888 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 889 RFC 793, DOI 10.17487/RFC0793, September 1981, 890 . 892 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 893 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 894 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 895 April 2007, . 897 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 898 over Low-Power Wireless Personal Area Networks (6LoWPANs): 899 Overview, Assumptions, Problem Statement, and Goals", 900 RFC 4919, DOI 10.17487/RFC4919, August 2007, 901 . 903 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 904 "Transmission of IPv6 Packets over IEEE 802.15.4 905 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 906 . 908 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 909 Routing Requirements in Low-Power and Lossy Networks", 910 RFC 5826, DOI 10.17487/RFC5826, April 2010, 911 . 913 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 914 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 915 DOI 10.17487/RFC6282, September 2011, 916 . 918 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 919 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 920 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 921 Low-Power and Lossy Networks", RFC 6550, 922 DOI 10.17487/RFC6550, March 2012, 923 . 925 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 926 and D. Barthel, "Routing Metrics Used for Path Calculation 927 in Low-Power and Lossy Networks", RFC 6551, 928 DOI 10.17487/RFC6551, March 2012, 929 . 931 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 932 Statement and Requirements for IPv6 over Low-Power 933 Wireless Personal Area Network (6LoWPAN) Routing", 934 RFC 6606, DOI 10.17487/RFC6606, May 2012, 935 . 937 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 938 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 939 2014, . 941 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 942 Constrained-Node Networks", RFC 7228, 943 DOI 10.17487/RFC7228, May 2014, 944 . 946 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 947 Application Protocol (CoAP)", RFC 7252, 948 DOI 10.17487/RFC7252, June 2014, 949 . 951 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 952 and M. Richardson, Ed., "A Security Threat Analysis for 953 the Routing Protocol for Low-Power and Lossy Networks 954 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 955 . 957 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 958 over ITU-T G.9959 Networks", RFC 7428, 959 DOI 10.17487/RFC7428, February 2015, 960 . 962 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 963 "Architectural Considerations in Smart Object Networking", 964 RFC 7452, DOI 10.17487/RFC7452, March 2015, 965 . 967 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 968 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 969 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 970 . 972 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 973 (IKEv2) Initiator Implementation", RFC 7815, 974 DOI 10.17487/RFC7815, March 2016, 975 . 977 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 978 M., and D. Barthel, "Transmission of IPv6 Packets over 979 Digital Enhanced Cordless Telecommunications (DECT) Ultra 980 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 981 2017, . 983 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 984 Internet", Wiley-Blackwell monograph, 985 DOI 10.1002/9780470686218, ISBN 9780470747995, 2009. 987 Acknowledgements 989 TBD 991 Authors' Addresses 993 Carsten Bormann 994 Universitaet Bremen TZI 995 Postfach 330440 996 Bremen D-28359 997 Germany 999 Phone: +49-421-218-63921 1000 EMail: cabo@tzi.org 1002 Mehmet Ersue 1003 Nokia Solutions and Networks 1004 St.-Martinstrasse 76 1005 Munich 81541 1006 Germany 1008 Phone: +49 172 8432301 1009 EMail: mehmet.ersue@nsn.com 1011 Ari Keranen 1012 Ericsson 1013 Hirsalantie 11 1014 Jorvas 02420 1015 Finland 1017 EMail: ari.keranen@ericsson.com 1019 Carles Gomez 1020 UPC/i2CAT 1021 Escola d'Enginyeria de Telecomunicacio i Aeroespacial 1022 de Castelldefels 1023 C/Esteve Terradas, 7 1024 Castelldefels 08860 1025 Spain 1027 Phone: +34-93-413-7206 1028 EMail: carlesgo@entel.upc.edu