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