idnits 2.17.1 draft-ietf-lwig-terminology-07.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 (February 10, 2014) is 3728 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-lwig-cellular-00 == Outdated reference: A later version (-05) exists of draft-ietf-lwig-ikev2-minimal-01 == Outdated reference: A later version (-01) exists of draft-ietf-lwig-tls-minimal-00 == Outdated reference: A later version (-11) exists of draft-ietf-roll-security-threats-06 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 5 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: August 14, 2014 Nokia Siemens Networks 6 A. Keranen 7 Ericsson 8 February 10, 2014 10 Terminology for Constrained Node Networks 11 draft-ietf-lwig-terminology-07 13 Abstract 15 The Internet Protocol Suite is increasingly used on small devices 16 with severe constraints on power, memory and processing resources, 17 creating constrained node networks. This document provides a number 18 of basic terms that have turned out to be useful in the 19 standardization work for constrained node networks. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 14, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Core Terminology . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5 59 2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6 60 2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 6 61 2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 7 62 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7 63 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8 64 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 10 66 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 10 67 4.3. Strategies of Using Power for Communication . . . . . . . 11 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 71 8. Informative References . . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 Small devices with limited CPU, memory, and power resources, so 77 called constrained devices (often used as a sensor/actuator, a smart 78 object, or a smart device) can form a network, becoming "constrained 79 nodes" in that network. Such a network may itself exhibit 80 constraints, e.g. with unreliable or lossy channels, limited and 81 unpredictable bandwidth, and a highly dynamic topology. 83 Constrained devices might be in charge of gathering information in 84 diverse settings including natural ecosystems, buildings, and 85 factories and sending the information to one or more server stations. 86 They also act on information, by performing some physical action, 87 including displaying it. Constrained devices may work under severe 88 resource constraints such as limited battery and computing power, 89 little memory, as well as insufficient wireless bandwidth and ability 90 to communicate; these constraints often exacerbate each other. Other 91 entities on the network, e.g., a base station or controlling server, 92 might have more computational and communication resources and could 93 support the interaction between the constrained devices and 94 applications in more traditional networks. 96 Today diverse sizes of constrained devices with different resources 97 and capabilities are becoming connected. Mobile personal gadgets, 98 building-automation devices, cellular phones, Machine-to-machine 99 (M2M) devices, etc. benefit from interacting with other "things" 100 nearby or somewhere in the Internet. With this, the Internet of 101 Things (IoT) becomes a reality, built up out of uniquely identifiable 102 and addressable objects (things). And over the next decade, this 103 could grow to large numbers [fifty-billion] of Internet-connected 104 constrained devices, greatly increasing the Internet's size and 105 scope. 107 The present document provides a number of basic terms that have 108 turned out to be useful in the standardization work for constrained 109 environments. The intention is not to exhaustively cover the field, 110 but to make sure a few core terms are used consistently between 111 different groups cooperating in this space. 113 In this document, the term "byte" is used in its now customary sense 114 as a synonym for "octet". Where sizes of semiconductor memory are 115 given, the prefix "kibi" (1024) is combined with "byte" to 116 "kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13]. 118 In computing, the term "power" is often used for the concept of 119 "computing power" or "processing power", as in CPU performance. 120 Unless explicitly stated otherwise, in this document the term stands 121 for electrical power. "Mains-powered" is used as a short-hand for 122 being permanently connected to a stable electrical power grid. 124 2. Core Terminology 126 There are two important aspects to _scaling_ within the Internet of 127 Things: 129 o Scaling up Internet technologies to a large number [fifty-billion] 130 of inexpensive nodes, while 132 o scaling down the characteristics of each of these nodes and of the 133 networks being built out of them, to make this scaling up 134 economically and physically viable. 136 The need for scaling down the characteristics of nodes leads to 137 _constrained nodes_. 139 2.1. Constrained Nodes 141 The term "constrained node" is best defined by contrasting the 142 characteristics of a constrained node with certain widely held 143 expectations on more familiar Internet nodes: 145 Constrained Node: A node where some of the characteristics that are 146 otherwise pretty much taken for granted for Internet nodes at the 147 time of writing are not attainable, often due to cost constraints 148 and/or physical constraints on characteristics such as size, 149 weight, and available power and energy. The tight limits on 150 power, memory and processing resources lead to hard upper bounds 151 on state, code space and processing cycles, making optimization of 152 energy and network bandwidth usage a dominating consideration in 153 all design requirements. Also, some layer 2 services such as full 154 connectivity and broadcast/multicast may be lacking. 156 While this is not a rigorous definition, it is grounded in the state 157 of the art and clearly sets apart constrained nodes from server 158 systems, desktop or laptop computers, powerful mobile devices such as 159 smartphones etc. There may be many design considerations that lead 160 to these constraints, including cost, size, weight, and other scaling 161 factors. 163 (An alternative name, when the properties as a network node are not 164 in focus, is "constrained device".) 166 There are multiple facets to the constraints on nodes, often applying 167 in combination, e.g.: 169 o constraints on the maximum code complexity (ROM/Flash); 171 o constraints on the size of state and buffers (RAM); 173 o constraints on the amount of computation feasible in a period of 174 time ("processing power"); 176 o constraints on the available (electrical) power; 178 o constraints on user interface and accessibility in deployment 179 (ability to set keys, update software, etc.). 181 Section 3 defines a small number of interesting classes ("class-N" 182 for N=0,1,2) of constrained nodes focusing on relevant combinations 183 of the first two constraints. With respect to available (electrical) 184 power, [RFC6606] distinguishes "power-affluent" nodes (mains-powered 185 or regularly recharged) from "power-constrained nodes" that draw 186 their power from primary batteries or by using energy harvesting; 187 more detailed power terminology is given in Section 4. 189 The use of constrained nodes in networks often also leads to 190 constraints on the networks themselves. However, there may also be 191 constraints on networks that are largely independent from those of 192 the nodes. We therefore distinguish _constrained networks_ and 193 _constrained node networks_. 195 2.2. Constrained Networks 197 We define "constrained network" in a similar way: 199 Constrained Network: A network where some of the characteristics 200 pretty much taken for granted with link layers in common use in 201 the Internet at the time of writing, are not attainable. 203 Constraints may include: 205 o low achievable bit rate/throughput (including limits on duty 206 cycle), 208 o high packet loss, high packet loss (delivery rate) variability, 210 o highly asymmetric link characteristics, 212 o severe penalties for using larger packets (e.g., high packet loss 213 due to link layer fragmentation), 215 o limits on reachability over time (a substantial number of devices 216 may power off at any point in time but periodically "wake up" and 217 can communicate for brief periods of time) 219 o lack of (or severe constraints on) advanced services such as IP 220 multicast. 222 More generally, we speak of constrained networks whenever at least 223 some of the nodes involved in the network exhibit these 224 characteristics. 226 Again, there may be several reasons for this: 228 o cost constraints on the network, 229 o constraints of the nodes (for constrained node networks), 231 o physical constraints (e.g., power constraints, environmental 232 constraints, media constraints such as underwater operation, 233 limited spectrum for very high density, electromagnetic 234 compatibility), 236 o regulatory constraints, such as very limited spectrum availability 237 (including limits on effective radiated power and duty cycle), or 238 explosion safety, 240 o technology constraints, such as older and lower speed technologies 241 that are still operational and may need to stay in use for some 242 more time. 244 2.2.1. Challenged Networks 246 A constrained network is not necessarily a _challenged_ network 247 [FALL]: 249 Challenged Network: A network that has serious trouble maintaining 250 what an application would today expect of the end-to-end IP model, 251 e.g., by: 253 o not being able to offer end-to-end IP connectivity at all; 255 o exhibiting serious interruptions in end-to-end IP connectivity; 257 o exhibiting delay well beyond the Maximum Segment Lifetime (MSL) 258 defined by TCP [RFC0793]. 260 All challenged networks are constrained networks in some sense, but 261 not all constrained networks are challenged networks. There is no 262 well-defined boundary between the two, though. Delay-Tolerant 263 Networking (DTN) has been designed to cope with challenged networks 264 [RFC4838]. 266 2.3. Constrained Node Networks 268 Constrained Node Network: A network whose characteristics are 269 influenced by being composed of a significant portion of 270 constrained nodes. 272 A constrained node network always is a constrained network because of 273 the network constraints stemming from the node constraints, but may 274 also have other constraints that already make it a constrained 275 network. 277 The rest of this subsection introduces two additional terms that are 278 in active use in the area of constrained node networks, without an 279 intent to define them: LLN and (6)LoWPAN. 281 2.3.1. LLN ("low-power lossy network") 283 A related term that has been used to describe the focus of the IETF 284 working group on Routing Over Low power and Lossy networks (ROLL) is 285 "low-power lossy network" (LLN). The ROLL terminology document 286 [RFC7102] defines LLNs as follows: 288 LLN: Low power and Lossy networks (LLNs) are typically composed of 289 many embedded devices with limited power, memory, and processing 290 resources interconnected by a variety of links, such as IEEE 291 802.15.4 or Low Power WiFi. There is a wide scope of application 292 areas for LLNs, including industrial monitoring, building 293 automation (HVAC, lighting, access control, fire), connected home, 294 healthcare, environmental monitoring, urban sensor networks, 295 energy management, assets tracking and refrigeration.. [sic] 297 Beyond that, LLNs often exhibit considerable loss at the physical 298 layer, with significant variability of the delivery rate, and some 299 short-term unreliability, coupled with some medium term stability 300 that makes it worthwhile to construct medium-term stable directed 301 acyclic graphs for routing and do measurements on the edges such as 302 ETX [RFC6551]. Not all LLNs comprise low power nodes 303 [I-D.hui-vasseur-roll-rpl-deployment]. 305 LLNs typically are composed of constrained nodes; this leads to the 306 design of operation modes such as the "non-storing mode" defined by 307 RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks 308 [RFC6650]). So, in the terminology of the present document, an LLN 309 is a constrained node network with certain network characteristics, 310 which include constraints on the network as well. 312 2.3.2. LoWPAN, 6LoWPAN 314 One interesting class of a constrained network often used as a 315 constrained node network is the "LoWPAN" [RFC4919], a term inspired 316 from the name of the IEEE 802.15.4 working group (low-rate wireless 317 personal area networks (LR-WPANs)). The expansion of that acronym, 318 "Low-Power Wireless Personal Area Network" contains a hard to justify 319 "Personal" that is due to the history of task group naming in IEEE 320 802 more than due to an orientation of LoWPANs around a single 321 person. Actually, LoWPANs have been suggested for urban monitoring, 322 control of large buildings, and industrial control applications, so 323 the "Personal" can only be considered a vestige. Occasionally the 324 term is read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI]. 326 Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6, 327 "6LoWPAN") also refers to networks built from similarly constrained 328 link layer technologies [I-D.ietf-6lowpan-btle] 329 [I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz]. 331 3. Classes of Constrained Devices 333 Despite the overwhelming variety of Internet-connected devices that 334 can be envisioned, it may be worthwhile to have some succinct 335 terminology for different classes of constrained devices. In this 336 document, the class designations in Table 1 may be used as rough 337 indications of device capabilities: 339 +-------------+-----------------------+-------------------------+ 340 | Name | data size (e.g., RAM) | code size (e.g., Flash) | 341 +-------------+-----------------------+-------------------------+ 342 | Class 0, C0 | << 10 KiB | << 100 KiB | 343 | | | | 344 | Class 1, C1 | ~ 10 KiB | ~ 100 KiB | 345 | | | | 346 | Class 2, C2 | ~ 50 KiB | ~ 250 KiB | 347 +-------------+-----------------------+-------------------------+ 349 Table 1: Classes of Constrained Devices (KiB = 1024 bytes) 351 As of the writing of this document, these characteristics correspond 352 to distinguishable clusters of commercially available chips and 353 design cores for constrained devices. While it is expected that the 354 boundaries of these classes will move over time, Moore's law tends to 355 be less effective in the embedded space than in personal computing 356 devices: Gains made available by increases in transistor count and 357 density are more likely to be invested in reductions of cost and 358 power requirements than into continual increases in computing power. 360 Class 0 devices are very constrained sensor-like motes. They are so 361 severely constrained in memory and processing capabilities that most 362 likely they will not have the resources required to communicate 363 directly with the Internet in a secure manner (rare heroic, narrowly 364 targeted implementation efforts notwithstanding). Class 0 devices 365 will participate in Internet communications with the help of larger 366 devices acting as proxies, gateways or servers. Class 0 devices 367 generally cannot be secured or managed comprehensively in the 368 traditional sense. They will most likely be preconfigured (and will 369 be reconfigured rarely, if at all), with a very small data set. For 370 management purposes, they could answer keepalive signals and send on/ 371 off or basic health indications. 373 Class 1 devices are quite constrained in code space and processing 374 capabilities, such that they cannot easily talk to other Internet 375 nodes employing a full protocol stack such as using HTTP, TLS and 376 related security protocols and XML-based data representations. 377 However, they have enough power to use a protocol stack specifically 378 designed for constrained nodes (such as CoAP over UDP 379 [I-D.ietf-core-coap]) and participate in meaningful conversations 380 without the help of a gateway node. In particular, they can provide 381 support for the security functions required on a large network. 382 Therefore, they can be integrated as fully developed peers into an IP 383 network, but they need to be parsimonious with state memory, code 384 space, and often power expenditure for protocol and application 385 usage. 387 Class 2 devides are less constrained and fundamentally capable of 388 supporting most of the same protocol stacks as used on notebooks or 389 servers. However, even these devices can benefit from lightweight 390 and energy-efficient protocols and from consuming less bandwidth. 391 Furthermore, using fewer resources for networking leaves more 392 resources available to applications. Thus, using the protocol stacks 393 defined for more constrained devices also on Class 2 devices might 394 reduce development costs and increase the interoperability. 396 Constrained devices with capabilities significantly beyond Class 2 397 devices exist. They are less demanding from a standards development 398 point of view as they can largely use existing protocols unchanged. 399 The present document therefore does not make any attempt to define 400 classes beyond Class 2. These devices can still be constrained by a 401 limited energy supply. 403 With respect to examining the capabilities of constrained nodes, 404 particularly for Class 1 devices, it is important to understand what 405 type of applications they are able to run and which protocol 406 mechanisms would be most suitable. Because of memory and other 407 limitations, each specific Class 1 device might be able to support 408 only a few selected functions needed for its intended operation. In 409 other words, the set of functions that can actually be supported is 410 not static per device type: devices with similar constraints might 411 choose to support different functions. Even though Class 2 devices 412 have some more functionality available and may be able to provide a 413 more complete set of functions, they still need to be assessed for 414 the type of applications they will be running and the protocol 415 functions they would need. To be able to derive any requirements, 416 the use cases and the involvement of the devices in the application 417 and the operational scenario need to be analyzed. Use cases may 418 combine constrained devices of multiple classes as well as more 419 traditional Internet nodes. 421 4. Power Terminology 423 Devices not only differ in their computing capabilities, but also in 424 available electrical power and/or energy. While it is harder to find 425 recognizable clusters in this space, it is still useful to introduce 426 some common terminology. 428 4.1. Scaling Properties 430 The power and/or energy available to a device may vastly differ, from 431 kilowatts to microwatts, from essentially unlimited to hundreds of 432 microjoules. 434 Instead of defining classes or clusters, we simply state, in SI 435 units, an approximate value for one or both of the quantities listed 436 in Table 2: 438 +--------+---------------------------------------------+------------+ 439 | Name | Definition | SI Unit | 440 +--------+---------------------------------------------+------------+ 441 | Ps | Sustainable average power available for the | W (Watt) | 442 | | device over the time it is functioning | | 443 | | | | 444 | Et | Total electrical energy available before | J (Joule) | 445 | | the energy source is exhausted | | 446 +--------+---------------------------------------------+------------+ 448 Table 2: Quantities Relevant to Power and Energy 450 The value of Et may need to be interpreted in conjunction with an 451 indication over which period of time the value is given; see the next 452 subsection. 454 Some devices enter a "low-power" mode before the energy available in 455 a period is exhausted, or even have multiple such steps on the way to 456 exhaustion. For these devices, Ps would need to be given for each of 457 the modes/steps. 459 4.2. Classes of Energy Limitation 461 As discussed above, some devices are limited in available energy as 462 opposed to (or in addition to) being limited in available power. 463 Where no relevant limitations exist with respect to energy, the 464 device is classified as E9. The energy limitation may be in total 465 energy available in the usable lifetime of the device (e.g. a device 466 with a non-replaceable primary battery, which is discarded when this 467 battery is exhausted), classified as E2. Where the relevant 468 limitation is for a specific period, this is classified as E1, e.g. a 469 limited amount of energy available for the night with a solar-powered 470 device, or for the period between recharges with a device that is 471 manually connected to a charger, or by a periodic (primary) battery 472 replacement interval. Finally, there may be a limited amount of 473 energy available for a specific event, e.g. for a button press in an 474 energy harvesting light switch; this is classified as E0. Note that 475 many E1 devices in a sense also are E2, as the rechargeable battery 476 has a limited number of useful recharging cycles. 478 In summary, we distinguish (Table 3): 480 +------+------------------------------+-----------------------------+ 481 | Name | Type of energy limitation | Example Power Source | 482 +------+------------------------------+-----------------------------+ 483 | E0 | Event energy-limited | Event-based harvesting | 484 | | | | 485 | E1 | Period energy-limited | Battery that is | 486 | | | periodically recharged or | 487 | | | replaced | 488 | | | | 489 | E2 | Lifetime energy-limited | Non-replaceable primary | 490 | | | battery | 491 | | | | 492 | E9 | No direct quantitative | Mains powered | 493 | | limitations to available | | 494 | | energy | | 495 +------+------------------------------+-----------------------------+ 497 Table 3: Classes of Energy Limitation 499 4.3. Strategies of Using Power for Communication 501 Especially when wireless transmission is used, the radio often 502 consumes a big portion of the total energy consumed by the device. 503 Design parameters such as the available spectrum, the desired range, 504 and the bitrate aimed for, influence the power consumed during 505 transmission and reception; the duration of transmission and 506 reception (including potential reception) influence the total energy 507 consumption. 509 Based on the type of the energy source (e.g., battery or mains power) 510 and how often device needs to communicate, it may use different kinds 511 of strategies for power usage and network attachment. 513 The general strategies for power usage can be described as follows: 515 Always-on: This strategy is most applicable if there is no reason 516 for extreme measures for power saving. The device can stay on in 517 the usual manner all the time. It may be useful to employ power- 518 friendly hardware or limit the number of wireless transmissions, 519 CPU speeds, and other aspects for general power saving and cooling 520 needs, but the device can be connected to the network all the 521 time. 523 Normally-off: Under this strategy, the device sleeps such long 524 periods at a time that once it wakes up, it makes sense for it to 525 not pretend that it has been connected to the network during 526 sleep: The device re-attaches to the network as it is woken up. 527 The main optimization goal is to minimize the effort during such 528 re-attachment process and any resulting application 529 communications. 531 If the device sleeps for long periods of time, and needs to 532 communicate infrequently, the relative increase in energy 533 expenditure during reattachment may be acceptable. 535 Low-power: This strategy is most applicable to devices that need to 536 operate on a very small amount of power, but still need to be able 537 to communicate on a relatively frequent basis. This implies that 538 extremely low power solutions needs to be used for the hardware, 539 chosen link layer mechanisms, and so on. Typically, given the 540 small amount of time between transmissions, despite their sleep 541 state these devices retain some form of network attachment to the 542 network. Techniques used for minimizing power usage for the 543 network communications include minimizing any work from re- 544 establishing communications after waking up, tuning the frequency 545 of communications (including "duty cycling", where components are 546 switched on and off in a regular cycle), and other parameters 547 appropriately. 549 In summary, we distinguish (Table 4): 551 +--------+--------------------+-------------------------------------+ 552 | Name | Strategy | Ability to communicate | 553 +--------+--------------------+-------------------------------------+ 554 | P0 | Normally-off | Re-attach when required | 555 | | | | 556 | P1 | Low-power | Appears connected, perhaps with | 557 | | | high latency | 558 | | | | 559 | P9 | Always-on | Always connected | 560 +--------+--------------------+-------------------------------------+ 562 Table 4: Strategies of Using Power for Communication 564 Note that the discussion above is at the device level; similar 565 considerations can apply at the communications interface level. This 566 document does not define terminology for the latter. 568 A term often used to describe power-saving approaches is "duty- 569 cycling". This describes all forms of periodically switching off 570 some function, leaving it on only for a certain percentage of time 571 (the "duty cycle"). 573 [RFC7102] only distinguishes two levels, defining a Non-sleepy Node 574 as a node that always remains in a fully powered on state (always 575 awake) where it has the capability to perform communication (P9), and 576 a Sleepy Node as a node that may sometimes go into a sleep mode (a 577 low power state to conserve power) and temporarily suspend protocol 578 communication (P0); there is no explicit mention of P1. 580 5. Security Considerations 582 This document introduces common terminology that does not raise any 583 new security issue. Security considerations arising from the 584 constraints discussed in this document need to be discussed in the 585 context of specific protocols. For instance, [I-D.ietf-core-coap] 586 section 11.6, "Constrained node considerations", discusses 587 implications of specific constraints on the security mechanisms 588 employed. [I-D.ietf-roll-security-threats] provides a security 589 threat analysis for the RPL routing protocol. Implementation 590 considerations for security protocols on constrained nodes are 591 discussed in [I-D.ietf-lwig-ikev2-minimal] and 592 [I-D.ietf-lwig-tls-minimal]. A wider view at security in constrained 593 node networks is provided in [I-D.garcia-core-security]. 595 6. IANA Considerations 597 This document has no actions for IANA. 599 7. Acknowledgements 601 Dominique Barthel and Peter van der Stok provided useful comments; 602 Charles Palmer provided a full editorial review. 604 Peter van der Stok insisted that we should have power terminology, 605 hence Section 4. The text for Section 4.3 is mostly lifted from a 606 previous version of [I-D.ietf-lwig-cellular] and has been adapted for 607 this document. 609 8. Informative References 611 [FALL] Fall, K., "A Delay-Tolerant Network Architecture for 612 Challenged Internets", SIGCOMM 2003, 2003. 614 [I-D.brandt-6man-lowpanz] 615 Brandt, A. and J. Buron, "Transmission of IPv6 packets 616 over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02 617 (work in progress), June 2013. 619 [I-D.garcia-core-security] 620 Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and 621 R. Struik, "Security Considerations in the IP-based 622 Internet of Things", draft-garcia-core-security-06 (work 623 in progress), September 2013. 625 [I-D.hui-vasseur-roll-rpl-deployment] 626 Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL 627 deployment experience in large scale networks", draft-hui- 628 vasseur-roll-rpl-deployment-01 (work in progress), July 629 2012. 631 [I-D.ietf-6lowpan-btle] 632 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 633 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 634 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 635 (work in progress), February 2013. 637 [I-D.ietf-core-coap] 638 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 639 Application Protocol (CoAP)", draft-ietf-core-coap-18 640 (work in progress), June 2013. 642 [I-D.ietf-lwig-cellular] 643 Arkko, J., Eriksson, A., and A. Keranen, "Building Power- 644 Efficient CoAP Devices for Cellular Networks", draft-ietf- 645 lwig-cellular-00 (work in progress), August 2013. 647 [I-D.ietf-lwig-ikev2-minimal] 648 Kivinen, T., "Minimal IKEv2", draft-ietf-lwig- 649 ikev2-minimal-01 (work in progress), October 2013. 651 [I-D.ietf-lwig-tls-minimal] 652 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 653 Guide to the (Datagram) Transport Layer Security Protocol 654 for Smart Objects and Constrained Node Networks", draft- 655 ietf-lwig-tls-minimal-00 (work in progress), September 656 2013. 658 [I-D.ietf-roll-security-threats] 659 Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 660 and M. Richardson, "A Security Threat Analysis for Routing 661 Protocol for Low-power and lossy networks (RPL)", draft- 662 ietf-roll-security-threats-06 (work in progress), December 663 2013. 665 [I-D.mariager-6lowpan-v6over-dect-ule] 666 Mariager, P., Petersen, J., and Z. Shelby, "Transmission 667 of IPv6 Packets over DECT Ultra Low Energy", draft- 668 mariager-6lowpan-v6over-dect-ule-03 (work in progress), 669 July 2013. 671 [ISQ-13] International Electrotechnical Commission, "International 672 Standard -- Quantities and units -- Part 13: Information 673 science and technology", IEC 80000-13, March 2008. 675 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 676 793, September 1981. 678 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 679 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 680 Networking Architecture", RFC 4838, April 2007. 682 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 683 over Low-Power Wireless Personal Area Networks (6LoWPANs): 684 Overview, Assumptions, Problem Statement, and Goals", RFC 685 4919, August 2007. 687 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 688 Barthel, "Routing Metrics Used for Path Calculation in 689 Low-Power and Lossy Networks", RFC 6551, March 2012. 691 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 692 Statement and Requirements for IPv6 over Low-Power 693 Wireless Personal Area Network (6LoWPAN) Routing", RFC 694 6606, May 2012. 696 [RFC6650] Falk, J. and M. Kucherawy, "Creation and Use of Email 697 Feedback Reports: An Applicability Statement for the Abuse 698 Reporting Format (ARF)", RFC 6650, June 2012. 700 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 701 Lossy Networks", RFC 7102, January 2014. 703 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 704 Internet", ISBN 9780470747995, 2009. 706 [fifty-billion] 707 Ericsson, "More Than 50 Billion Connected Devices", 708 Ericsson White Paper 284 23-3149 Uen, February 2011, 709 . 712 Authors' Addresses 714 Carsten Bormann 715 Universitaet Bremen TZI 716 Postfach 330440 717 D-28359 Bremen 718 Germany 720 Phone: +49-421-218-63921 721 Email: cabo@tzi.org 723 Mehmet Ersue 724 Nokia Siemens Networks 725 St.-Martinstrasse 76 726 81541 Munich 727 Germany 729 Phone: +49 172 8432301 730 Email: mehmet.ersue@nsn.com 732 Ari Keranen 733 Ericsson 734 Hirsalantie 11 735 02420 Jorvas 736 Finland 738 Email: ari.keranen@ericsson.com