idnits 2.17.1 draft-bormann-lwig-7228bis-00.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 (October 30, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-6lo-dect-ule-07 == Outdated reference: A later version (-16) exists of draft-irtf-t2trg-iot-seccons-00 -- 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 C. Gomez 5 Expires: May 3, 2017 UPC/i2CAT 6 October 30, 2016 8 Terminology for Constrained-Node Networks 9 draft-bormann-lwig-7228bis-00 11 Abstract 13 The Internet Protocol Suite is increasingly used on small devices 14 with severe constraints on power, memory, and processing resources, 15 creating constrained-node networks. This document provides a number 16 of basic terms that have been useful in the standardization work for 17 constrained-node networks. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 3, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Core Terminology . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5 57 2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6 58 2.3. Constrained-Node Networks . . . . . . . . . . . . . . . . 6 59 2.3.1. LLN . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7 61 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8 62 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 10 63 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 10 64 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 10 65 4.3. Strategies for Using Power for Communication . . . . . . 11 66 5. Classes of Networks . . . . . . . . . . . . . . . . . . . . . 13 67 5.1. Classes of link layer MTU size . . . . . . . . . . . . . 13 68 5.2. Class of Internet Integration . . . . . . . . . . . . . . 14 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 8. Informative References . . . . . . . . . . . . . . . . . . . 15 72 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Introduction 77 Small devices with limited CPU, memory, and power resources, so- 78 called "constrained devices" (often used as sensors/actuators, smart 79 objects, or smart devices) can form a network, becoming "constrained 80 nodes" in that network. Such a network may itself exhibit 81 constraints, e.g., with unreliable or lossy channels, limited and 82 unpredictable bandwidth, and a highly dynamic topology. 84 Constrained devices might be in charge of gathering information in 85 diverse settings, including natural ecosystems, buildings, and 86 factories, and sending the information to one or more server 87 stations. They might also act on information, by performing some 88 physical action, including displaying it. Constrained devices may 89 work under severe resource constraints such as limited battery and 90 computing power, little memory, and insufficient wireless bandwidth 91 and ability to communicate; these constraints often exacerbate each 92 other. Other entities on the network, e.g., a base station or 93 controlling server, might have more computational and communication 94 resources and could support the interaction between the constrained 95 devices and applications in more traditional networks. 97 Today, diverse sizes of constrained devices with different resources 98 and capabilities are becoming connected. Mobile personal gadgets, 99 building-automation devices, cellular phones, machine-to-machine 100 (M2M) devices, and other devices benefit from interacting with other 101 "things" nearby or somewhere in the Internet. With this, the 102 Internet of Things (IoT) becomes a reality, built up out of uniquely 103 identifiable and addressable objects (things). Over the next decade, 104 this could grow to large numbers [FIFTY-BILLION] of Internet- 105 connected constrained devices, greatly increasing the Internet's size 106 and scope. 108 The present document provides a number of basic terms that have been 109 useful in the standardization work for constrained environments. The 110 intention is not to exhaustively cover the field but to make sure a 111 few core terms are used consistently between different groups 112 cooperating in this space. 114 In this document, the term "byte" is used in its now customary sense 115 as a synonym for "octet". Where sizes of semiconductor memory are 116 given, the prefix "kibi" (1024) is combined with "byte" to 117 "kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13]. 119 In computing, the term "power" is often used for the concept of 120 "computing power" or "processing power", as in CPU performance. In 121 this document, the term stands for electrical power unless explicitly 122 stated otherwise. "Mains-powered" is used as a shorthand for being 123 permanently connected to a stable electrical power grid. 125 2. Core Terminology 127 There are two important aspects to _scaling_ within the Internet of 128 Things: 130 o scaling up Internet technologies to a large number [FIFTY-BILLION] 131 of inexpensive nodes, while 133 o scaling down the characteristics of each of these nodes and of the 134 networks being built out of them, to make this scaling up 135 economically and physically viable. 137 The need for scaling down the characteristics of nodes leads to 138 "constrained nodes". 140 2.1. Constrained Nodes 142 The term "constrained node" is best defined by contrasting the 143 characteristics of a constrained node with certain widely held 144 expectations on more familiar Internet nodes: 146 Constrained Node: A node where some of the characteristics that are 147 otherwise pretty much taken for granted for Internet nodes at the 148 time of writing are not attainable, often due to cost constraints 149 and/or physical constraints on characteristics such as size, 150 weight, and available power and energy. The tight limits on 151 power, memory, and processing resources lead to hard upper bounds 152 on state, code space, and processing cycles, making optimization 153 of energy and network bandwidth usage a dominating consideration 154 in all design requirements. Also, some layer-2 services such as 155 full connectivity and broadcast/multicast may be lacking. 157 While this is not a rigorous definition, it is grounded in the state 158 of the art and clearly sets apart constrained nodes from server 159 systems, desktop or laptop computers, powerful mobile devices such as 160 smartphones, etc. There may be many design considerations that lead 161 to these constraints, including cost, size, weight, and other scaling 162 factors. 164 (An alternative term, when the properties as a network node are not 165 in focus, is "constrained device".) 167 There are multiple facets to the constraints on nodes, often applying 168 in combination, for example: 170 o constraints on the maximum code complexity (ROM/Flash), 172 o constraints on the size of state and buffers (RAM), 174 o constraints on the amount of computation feasible in a period of 175 time ("processing power"), 177 o constraints on the available power, and 179 o constraints on user interface and accessibility in deployment 180 (ability to set keys, update software, etc.). 182 Section 3 defines a small number of interesting classes ("class-N" 183 for N = 0, 1, 2) of constrained nodes focusing on relevant 184 combinations of the first two constraints. With respect to available 185 power, [RFC6606] distinguishes "power-affluent" nodes (mains-powered 186 or regularly recharged) from "power-constrained nodes" that draw 187 their power from primary batteries or by using energy harvesting; 188 more detailed power terminology is given in Section 4. 190 The use of constrained nodes in networks often also leads to 191 constraints on the networks themselves. However, there may also be 192 constraints on networks that are largely independent from those of 193 the nodes. We therefore distinguish "constrained networks" from 194 "constrained-node networks". 196 2.2. Constrained Networks 198 We define "constrained network" in a similar way: 200 Constrained Network: A network where some of the characteristics 201 pretty much taken for granted with link layers in common use in 202 the Internet at the time of writing are not attainable. 204 Constraints may include: 206 o low achievable bitrate/throughput (including limits on duty 207 cycle), 209 o high packet loss and high variability of packet loss (delivery 210 rate), 212 o highly asymmetric link characteristics, 214 o severe penalties for using larger packets (e.g., high packet loss 215 due to link-layer fragmentation), 217 o limits on reachability over time (a substantial number of devices 218 may power off at any point in time but periodically "wake up" and 219 can communicate for brief periods of time), and 221 o lack of (or severe constraints on) advanced services such as IP 222 multicast. 224 More generally, we speak of constrained networks whenever at least 225 some of the nodes involved in the network exhibit these 226 characteristics. 228 Again, there may be several reasons for this: 230 o cost constraints on the network, 232 o constraints posed by the nodes (for constrained-node networks), 234 o physical constraints (e.g., power constraints, environmental 235 constraints, media constraints such as underwater operation, 236 limited spectrum for very high density, electromagnetic 237 compatibility), 239 o regulatory constraints, such as very limited spectrum availability 240 (including limits on effective radiated power and duty cycle) or 241 explosion safety, and 243 o technology constraints, such as older and lower-speed technologies 244 that are still operational and may need to stay in use for some 245 more time. 247 2.2.1. Challenged Networks 249 A constrained network is not necessarily a "challenged network" 250 [FALL]: 252 Challenged Network: A network that has serious trouble maintaining 253 what an application would today expect of the end-to-end IP model, 254 e.g., by: 256 * not being able to offer end-to-end IP connectivity at all, 258 * exhibiting serious interruptions in end-to-end IP connectivity, 259 or 261 * exhibiting delay well beyond the Maximum Segment Lifetime (MSL) 262 defined by TCP [RFC0793]. 264 All challenged networks are constrained networks in some sense, but 265 not all constrained networks are challenged networks. There is no 266 well-defined boundary between the two, though. Delay-Tolerant 267 Networking (DTN) has been designed to cope with challenged networks 268 [RFC4838]. 270 2.3. Constrained-Node Networks 272 Constrained-Node Network: A network whose characteristics are 273 influenced by being composed of a significant portion of 274 constrained nodes. 276 A constrained-node network always is a constrained network because of 277 the network constraints stemming from the node constraints, but it 278 may also have other constraints that already make it a constrained 279 network. 281 The rest of this subsection introduces two additional terms that are 282 in active use in the area of constrained-node networks, without an 283 intent to define them: LLN and (6)LoWPAN. 285 2.3.1. LLN 287 A related term that has been used to describe the focus of the IETF 288 ROLL working group is "Low-Power and Lossy Network (LLN)". The ROLL 289 (Routing Over Low-Power and Lossy) terminology document [RFC7102] 290 defines LLNs as follows: 292 LLN: Low-Power and Lossy Network. Typically composed of many 293 embedded devices with limited power, memory, and processing 294 resources interconnected by a variety of links, such as IEEE 295 802.15.4 or low-power Wi-Fi. There is a wide scope of application 296 areas for LLNs, including industrial monitoring, building 297 automation (heating, ventilation, and air conditioning (HVAC), 298 lighting, access control, fire), connected home, health care, 299 environmental monitoring, urban sensor networks, energy 300 management, assets tracking, and refrigeration. 302 Beyond that, LLNs often exhibit considerable loss at the physical 303 layer, with significant variability of the delivery rate, and some 304 short-term unreliability, coupled with some medium-term stability 305 that makes it worthwhile to both construct directed acyclic graphs 306 that are medium-term stable for routing and do measurements on the 307 edges such as Expected Transmission Count (ETX) [RFC6551]. Not all 308 LLNs comprise low-power nodes [I-D.hui-vasseur-roll-rpl-deployment]. 310 LLNs typically are composed of constrained nodes; this leads to the 311 design of operation modes such as the "non-storing mode" defined by 312 RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks 313 [RFC6550]). So, in the terminology of the present document, an LLN 314 is a constrained-node network with certain network characteristics, 315 which include constraints on the network as well. 317 2.3.2. LoWPAN, 6LoWPAN 319 One interesting class of a constrained network often used as a 320 constrained-node network is "LoWPAN" [RFC4919], a term inspired from 321 the name of an IEEE 802.15.4 working group (low-rate wireless 322 personal area networks (LR-WPANs)). The expansion of the LoWPAN 323 acronym, "Low-Power Wireless Personal Area Network", contains a hard- 324 to-justify "Personal" that is due to the history of task group naming 325 in IEEE 802 more than due to an orientation of LoWPANs around a 326 single person. Actually, LoWPANs have been suggested for urban 327 monitoring, control of large buildings, and industrial control 328 applications, so the "Personal" can only be considered a vestige. 329 Occasionally, the term is read as "Low-Power Wireless Area Networks" 330 [WEI]. Originally focused on IEEE 802.15.4, "LoWPAN" (or when used 331 for IPv6, "6LoWPAN") also refers to networks built from similarly 332 constrained link-layer technologies [RFC7668] [I-D.ietf-6lo-dect-ule] 333 [RFC7428]. 335 3. Classes of Constrained Devices 337 Despite the overwhelming variety of Internet-connected devices that 338 can be envisioned, it may be worthwhile to have some succinct 339 terminology for different classes of constrained devices. In this 340 document, the class designations in Table 1 may be used as rough 341 indications of device capabilities: 343 +-------------+-----------------------+-------------------------+ 344 | Name | data size (e.g., RAM) | code size (e.g., Flash) | 345 +-------------+-----------------------+-------------------------+ 346 | Class 0, C0 | << 10 KiB | << 100 KiB | 347 | | | | 348 | Class 1, C1 | ~ 10 KiB | ~ 100 KiB | 349 | | | | 350 | Class 2, C2 | ~ 50 KiB | ~ 250 KiB | 351 +-------------+-----------------------+-------------------------+ 353 Table 1: Classes of Constrained Devices (KiB = 1024 bytes) 355 As of the writing of this document, these characteristics correspond 356 to distinguishable clusters of commercially available chips and 357 design cores for constrained devices. While it is expected that the 358 boundaries of these classes will move over time, Moore's law tends to 359 be less effective in the embedded space than in personal computing 360 devices: gains made available by increases in transistor count and 361 density are more likely to be invested in reductions of cost and 362 power requirements than into continual increases in computing power. 364 Class 0 devices are very constrained sensor-like motes. They are so 365 severely constrained in memory and processing capabilities that most 366 likely they will not have the resources required to communicate 367 directly with the Internet in a secure manner (rare heroic, narrowly 368 targeted implementation efforts notwithstanding). Class 0 devices 369 will participate in Internet communications with the help of larger 370 devices acting as proxies, gateways, or servers. Class 0 devices 371 generally cannot be secured or managed comprehensively in the 372 traditional sense. They will most likely be preconfigured (and will 373 be reconfigured rarely, if at all) with a very small data set. For 374 management purposes, they could answer keepalive signals and send on/ 375 off or basic health indications. 377 Class 1 devices are quite constrained in code space and processing 378 capabilities, such that they cannot easily talk to other Internet 379 nodes employing a full protocol stack such as using HTTP, Transport 380 Layer Security (TLS), and related security protocols and XML-based 381 data representations. However, they are capable enough to use a 382 protocol stack specifically designed for constrained nodes (such as 383 the Constrained Application Protocol (CoAP) over UDP [RFC7252]) and 384 participate in meaningful conversations without the help of a gateway 385 node. In particular, they can provide support for the security 386 functions required on a large network. Therefore, they can be 387 integrated as fully developed peers into an IP network, but they need 388 to be parsimonious with state memory, code space, and often power 389 expenditure for protocol and application usage. 391 Class 2 devices are less constrained and fundamentally capable of 392 supporting most of the same protocol stacks as used on notebooks or 393 servers. However, even these devices can benefit from lightweight 394 and energy-efficient protocols and from consuming less bandwidth. 395 Furthermore, using fewer resources for networking leaves more 396 resources available to applications. Thus, using the protocol stacks 397 defined for more constrained devices on Class 2 devices might reduce 398 development costs and increase the interoperability. 400 Constrained devices with capabilities significantly beyond Class 2 401 devices exist. They are less demanding from a standards development 402 point of view as they can largely use existing protocols unchanged. 403 The present document therefore does not make any attempt to define 404 classes beyond Class 2. These devices can still be constrained by a 405 limited energy supply. 407 With respect to examining the capabilities of constrained nodes, 408 particularly for Class 1 devices, it is important to understand what 409 type of applications they are able to run and which protocol 410 mechanisms would be most suitable. Because of memory and other 411 limitations, each specific Class 1 device might be able to support 412 only a few selected functions needed for its intended operation. In 413 other words, the set of functions that can actually be supported is 414 not static per device type: devices with similar constraints might 415 choose to support different functions. Even though Class 2 devices 416 have some more functionality available and may be able to provide a 417 more complete set of functions, they still need to be assessed for 418 the type of applications they will be running and the protocol 419 functions they would need. To be able to derive any requirements, 420 the use cases and the involvement of the devices in the application 421 and the operational scenario need to be analyzed. Use cases may 422 combine constrained devices of multiple classes as well as more 423 traditional Internet nodes. 425 4. Power Terminology 427 Devices not only differ in their computing capabilities but also in 428 available power and/or energy. While it is harder to find 429 recognizable clusters in this space, it is still useful to introduce 430 some common terminology. 432 4.1. Scaling Properties 434 The power and/or energy available to a device may vastly differ, from 435 kilowatts to microwatts, from essentially unlimited to hundreds of 436 microjoules. 438 Instead of defining classes or clusters, we simply state, using the 439 International System of Units (SI units), an approximate value for 440 one or both of the quantities listed in Table 2: 442 +------+--------------------------------------------------+---------+ 443 | Name | Definition | SI Unit | 444 +------+--------------------------------------------------+---------+ 445 | Ps | Sustainable average power available for the | W | 446 | | device over the time it is functioning | (Watt) | 447 | | | | 448 | Et | Total electrical energy available before the | J | 449 | | energy source is exhausted | (Joule) | 450 +------+--------------------------------------------------+---------+ 452 Table 2: Quantities Relevant to Power and Energy 454 The value of Et may need to be interpreted in conjunction with an 455 indication over which period of time the value is given; see 456 Section 4.2. 458 Some devices enter a "low-power" mode before the energy available in 459 a period is exhausted or even have multiple such steps on the way to 460 exhaustion. For these devices, Ps would need to be given for each of 461 the modes/steps. 463 4.2. Classes of Energy Limitation 465 As discussed above, some devices are limited in available energy as 466 opposed to (or in addition to) being limited in available power. 467 Where no relevant limitations exist with respect to energy, the 468 device is classified as E9. The energy limitation may be in total 469 energy available in the usable lifetime of the device (e.g., a device 470 that is discarded when its non-replaceable primary battery is 471 exhausted), classified as E2. Where the relevant limitation is for a 472 specific period, the device is classified as E1, e.g., a solar- 473 powered device with a limited amount of energy available for the 474 night, a device that is manually connected to a charger and has a 475 period of time between recharges, or a device with a periodic 476 (primary) battery replacement interval. Finally, there may be a 477 limited amount of energy available for a specific event, e.g., for a 478 button press in an energy-harvesting light switch; such devices are 479 classified as E0. Note that, in a sense, many E1 devices are also 480 E2, as the rechargeable battery has a limited number of useful 481 recharging cycles. 483 Table 3 provides a summary of the classifications described above. 485 +------+------------------------------+-----------------------------+ 486 | Name | Type of energy limitation | Example Power Source | 487 +------+------------------------------+-----------------------------+ 488 | E0 | Event energy-limited | Event-based harvesting | 489 | | | | 490 | E1 | Period energy-limited | Battery that is | 491 | | | periodically recharged or | 492 | | | replaced | 493 | | | | 494 | E2 | Lifetime energy-limited | Non-replaceable primary | 495 | | | battery | 496 | | | | 497 | E9 | No direct quantitative | Mains-powered | 498 | | limitations to available | | 499 | | energy | | 500 +------+------------------------------+-----------------------------+ 502 Table 3: Classes of Energy Limitation 504 4.3. Strategies for Using Power for Communication 506 Especially when wireless transmission is used, the radio often 507 consumes a big portion of the total energy consumed by the device. 508 Design parameters, such as the available spectrum, the desired range, 509 and the bitrate aimed for, influence the power consumed during 510 transmission and reception; the duration of transmission and 511 reception (including potential reception) influence the total energy 512 consumption. 514 Different strategies for power usage and network attachment may be 515 used, based on the type of the energy source (e.g., battery or mains- 516 powered) and the frequency with which a device needs to communicate. 518 The general strategies for power usage can be described as follows: 520 Always-on: This strategy is most applicable if there is no reason 521 for extreme measures for power saving. The device can stay on in 522 the usual manner all the time. It may be useful to employ power- 523 friendly hardware or limit the number of wireless transmissions, 524 CPU speeds, and other aspects for general power-saving and cooling 525 needs, but the device can be connected to the network all the 526 time. 528 Normally-off: Under this strategy, the device sleeps such long 529 periods at a time that once it wakes up, it makes sense for it to 530 not pretend that it has been connected to the network during 531 sleep: the device reattaches to the network as it is woken up. 532 The main optimization goal is to minimize the effort during the 533 reattachment process and any resulting application communications. 534 If the device sleeps for long periods of time and needs to 535 communicate infrequently, the relative increase in energy 536 expenditure during reattachment may be acceptable. 538 Low-power: This strategy is most applicable to devices that need to 539 operate on a very small amount of power but still need to be able 540 to communicate on a relatively frequent basis. This implies that 541 extremely low-power solutions need to be used for the hardware, 542 chosen link-layer mechanisms, and so on. Typically, given the 543 small amount of time between transmissions, despite their sleep 544 state, these devices retain some form of attachment to the 545 network. Techniques used for minimizing power usage for the 546 network communications include minimizing any work from re- 547 establishing communications after waking up and tuning the 548 frequency of communications (including "duty cycling", where 549 components are switched on and off in a regular cycle) and other 550 parameters appropriately. 552 Table 4 provides a summary of the strategies described above. 554 +------+--------------+---------------------------------------------+ 555 | Name | Strategy | Ability to communicate | 556 +------+--------------+---------------------------------------------+ 557 | P0 | Normally-off | Reattach when required | 558 | | | | 559 | P1 | Low-power | Appears connected, perhaps with high | 560 | | | latency | 561 | | | | 562 | P9 | Always-on | Always connected | 563 +------+--------------+---------------------------------------------+ 565 Table 4: Strategies of Using Power for Communication 567 Note that the discussion above is at the device level; similar 568 considerations can apply at the communications-interface level. This 569 document does not define terminology for the latter. 571 A term often used to describe power-saving approaches is "duty- 572 cycling". This describes all forms of periodically switching off 573 some function, leaving it on only for a certain percentage of time 574 (the "duty cycle"). 576 [RFC7102] only distinguishes two levels, defining a Non-Sleepy Node 577 as a node that always remains in a fully powered-on state (always 578 awake) where it has the capability to perform communication (P9) and 579 a Sleepy Node as a node that may sometimes go into a sleep mode (a 580 low-power state to conserve power) and temporarily suspend protocol 581 communication (P0); there is no explicit mention of P1. 583 5. Classes of Networks 585 5.1. Classes of link layer MTU size 587 Link layer technologies used by constrained devices can be 588 categorized on the basis of link layer MTU size. Depending on this 589 parameter, the fragmentation techniques needed (if any) to support 590 the IPv6 MTU requirement may vary. 592 We define the following classes of link layer MTU size: 594 +------+---------------------+------------------------------------+ 595 | Name | L2 MTU size (bytes) | 6LoWPAN Fragmentation applicable*? | 596 +------+---------------------+------------------------------------+ 597 | S0 | 3 - 12 | need new kind of fragmentation | 598 | | | | 599 | S1 | 13 - 127 | yes | 600 | | | | 601 | S2 | 128 - 1279 | yes | 602 | | | | 603 | S2 | >= 1280 | no fragmentation needed | 604 +------+---------------------+------------------------------------+ 606 *if no link layer fragmentation is available 607 (note: 'Sx' stands for 'Size x') 609 S0 technologies require fragmentation to support the IPv6 MTU 610 requirement. If no link layer fragmentation is available, 611 fragmentation is needed at the adaptation layer below IPv6. However, 612 6LoWPAN fragmentation [RFC4944] cannot be used for these 613 technologies, given the extremely reduced link layer MTU. In this 614 case, lightweight fragmentation formats must be used (e.g. 615 [I-D.gomez-lpwan-fragmentation-header]). 617 S1 and S2 technologies require fragmentation at the subnetwork level 618 to support the IPv6 MTU requirement. If link layer fragmentation is 619 unavailable or insufficient, fragmentation is needed at the 620 adaptation layer below IPv6. 6LoWPAN fragmentation [RFC4944] can be 621 used to carry 1280-byte IPv6 packets over these technologies. 623 S3 technologies do not require fragmentation to support the IPv6 MTU 624 requirement. 626 5.2. Class of Internet Integration 628 The term "Internet of Things" is sometimes confusingly used for 629 connected devices that are not actually employing Internet 630 technology. Some devices do use Internet technology, but only use it 631 to exchange packets with a fixed communication partner ("device-to- 632 cloud" scenarios, [RFC7452]). More general devices are prepared to 633 communicate with other nodes in the Internet as well. 635 We define the following classes of Internet technology level: 637 +------+--------------------------------------+ 638 | Name | Internet technology | 639 +------+--------------------------------------+ 640 | I0 | none (local interconnect only) | 641 | | | 642 | I1 | device-to-cloud only | 643 | | | 644 | I9 | full Internet connectivity supported | 645 +------+--------------------------------------+ 647 6. IANA Considerations 649 This document makes no requests of IANA. 651 7. Security Considerations 653 This document introduces common terminology that does not raise any 654 new security issues. Security considerations arising from the 655 constraints discussed in this document need to be discussed in the 656 context of specific protocols. For instance, Section 11.6 of 657 [RFC7252], "Constrained node considerations", discusses implications 658 of specific constraints on the security mechanisms employed. 659 [RFC7416] provides a security threat analysis for the RPL routing 660 protocol. Implementation considerations for security protocols on 661 constrained nodes are discussed in [RFC7815] and 663 [I-D.ietf-lwig-tls-minimal]. A wider view of security in 664 constrained-node networks is provided in 665 [I-D.irtf-t2trg-iot-seccons]. 667 8. Informative References 669 [FALL] Fall, K., "A Delay-Tolerant Network Architecture for 670 Challenged Internets", SIGCOMM 2003, 671 DOI 10.1145/863955.863960, 2003. 673 [FIFTY-BILLION] 674 Ericsson, "More Than 50 Billion Connected Devices", 675 Ericsson White Paper 284 23-3149 Uen, February 2011, 676 . 679 [I-D.gomez-lpwan-fragmentation-header] 680 Gomez, C., Paradells, J., and J. Crowcroft, "LPWAN 681 Fragmentation Header", draft-gomez-lpwan-fragmentation- 682 header-03 (work in progress), October 2016. 684 [I-D.hui-vasseur-roll-rpl-deployment] 685 Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL 686 deployment experience in large scale networks", draft-hui- 687 vasseur-roll-rpl-deployment-01 (work in progress), July 688 2012. 690 [I-D.ietf-6lo-dect-ule] 691 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 692 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 693 Energy", draft-ietf-6lo-dect-ule-07 (work in progress), 694 October 2016. 696 [I-D.ietf-lwig-tls-minimal] 697 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 698 Guide to the (Datagram) Transport Layer Security Protocol 699 for Smart Objects and Constrained Node Networks", draft- 700 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 702 [I-D.irtf-t2trg-iot-seccons] 703 Garcia-Morchon, O., Kumar, S., and M. Sethi, "Security 704 Considerations in the IP-based Internet of Things", draft- 705 irtf-t2trg-iot-seccons-00 (work in progress), October 706 2016. 708 [ISQ-13] International Electrotechnical Commission, "International 709 Standard -- Quantities and units -- Part 13: Information 710 science and technology", IEC 80000-13, March 2008. 712 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 713 RFC 793, DOI 10.17487/RFC0793, September 1981, 714 . 716 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 717 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 718 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 719 April 2007, . 721 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 722 over Low-Power Wireless Personal Area Networks (6LoWPANs): 723 Overview, Assumptions, Problem Statement, and Goals", 724 RFC 4919, DOI 10.17487/RFC4919, August 2007, 725 . 727 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 728 "Transmission of IPv6 Packets over IEEE 802.15.4 729 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 730 . 732 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 733 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 734 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 735 Low-Power and Lossy Networks", RFC 6550, 736 DOI 10.17487/RFC6550, March 2012, 737 . 739 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 740 and D. Barthel, "Routing Metrics Used for Path Calculation 741 in Low-Power and Lossy Networks", RFC 6551, 742 DOI 10.17487/RFC6551, March 2012, 743 . 745 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 746 Statement and Requirements for IPv6 over Low-Power 747 Wireless Personal Area Network (6LoWPAN) Routing", 748 RFC 6606, DOI 10.17487/RFC6606, May 2012, 749 . 751 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 752 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 753 2014, . 755 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 756 Constrained-Node Networks", RFC 7228, 757 DOI 10.17487/RFC7228, May 2014, 758 . 760 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 761 Application Protocol (CoAP)", RFC 7252, 762 DOI 10.17487/RFC7252, June 2014, 763 . 765 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 766 and M. Richardson, Ed., "A Security Threat Analysis for 767 the Routing Protocol for Low-Power and Lossy Networks 768 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 769 . 771 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 772 over ITU-T G.9959 Networks", RFC 7428, 773 DOI 10.17487/RFC7428, February 2015, 774 . 776 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 777 "Architectural Considerations in Smart Object Networking", 778 RFC 7452, DOI 10.17487/RFC7452, March 2015, 779 . 781 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 782 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 783 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 784 . 786 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 787 (IKEv2) Initiator Implementation", RFC 7815, 788 DOI 10.17487/RFC7815, March 2016, 789 . 791 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 792 Internet", Wiley-Blackwell monograph, 793 DOI 10.1002/9780470686218, ISBN 9780470747995, 2009. 795 Acknowledgements 797 Ari Keranen and Mehmet Ersue were co-authors of the [RFC7228], from 798 which this bis document is derived. Ari has already started 799 contributing to this document as well. 801 Authors' Addresses 803 Carsten Bormann 804 Universitaet Bremen TZI 805 Postfach 330440 806 Bremen D-28359 807 Germany 809 Phone: +49-421-218-63921 810 EMail: cabo@tzi.org 812 Carles Gomez 813 UPC/i2CAT 814 Escola d'Enginyeria de Telecomunicacio i Aeroespacial 815 de Castelldefels 816 C/Esteve Terradas, 7 817 Castelldefels 08860 818 Spain 820 Phone: +34-93-413-7206 821 EMail: carlesgo@entel.upc.edu