idnits 2.17.1 draft-ietf-lwig-terminology-06.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 (December 18, 2013) is 3781 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 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational M. Ersue 5 Expires: June 21, 2014 Nokia Siemens Networks 6 A. Keranen 7 Ericsson 8 December 18, 2013 10 Terminology for Constrained Node Networks 11 draft-ietf-lwig-terminology-06 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 June 21, 2014. 38 Copyright Notice 40 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . 14 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 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 Again, there may be several reasons for this: 205 o cost constraints on the network, 207 o constraints of the nodes (for constrained node networks), 209 o physical constraints (e.g., power constraints, environmental 210 constraints, media constraints such as underwater operation, 211 limited spectrum for very high density, electromagnetic 212 compatibility), 214 o regulatory constraints, such as very limited spectrum availability 215 (including limits on effective radiated power and duty cycle), or 216 explosion safety, 218 o technology constraints, such as older and lower speed technologies 219 that are still operational and may need to stay in use for some 220 more time. 222 Constraints may include: 224 o low achievable bit rate (including limits on duty cycle), 226 o high packet loss, packet loss (delivery rate) variability, 228 o highly asymmetric link characteristics, 229 o severe penalties for using larger packets (e.g., high packet loss 230 due to link layer fragmentation), 232 o lack of (or severe constraints on) advanced services such as IP 233 multicast. 235 2.2.1. Challenged Networks 237 A constrained network is not necessarily a _challenged_ network 238 [FALL]: 240 Challenged Network: A network that has serious trouble maintaining 241 what an application would today expect of the end-to-end IP model, 242 e.g., by: 244 o not being able to offer end-to-end IP connectivity at all; 246 o exhibiting serious interruptions in end-to-end IP connectivity; 248 o exhibiting delay well beyond the Maximum Segment Lifetime (MSL) 249 defined by TCP [RFC0793]. 251 All challenged networks are constrained networks in some sense, but 252 not all constrained networks are challenged networks. There is no 253 well-defined boundary between the two, though. Delay-Tolerant 254 Networking (DTN) has been designed to cope with challenged networks 255 [RFC4838]. 257 2.3. Constrained Node Networks 259 Constrained Node Network: A network whose characteristics are 260 influenced by being composed of a significant portion of 261 constrained nodes. 263 A constrained node network always is a constrained network because of 264 the network constraints stemming from the node constraints, but may 265 also have other constraints that already make it a constrained 266 network. 268 The rest of this subsection introduces two additional terms that are 269 in active use in the area of constrained node networks, without an 270 intent to define them: LLN and (6)LoWPAN. 272 2.3.1. LLN ("low-power lossy network") 274 A related term that has been used to describe the focus of the IETF 275 working group on Routing Over Low power and Lossy networks (ROLL) is 276 "low-power lossy network" (LLN). The ROLL terminology document 277 [I-D.ietf-roll-terminology] defines LLNs as follows: 279 LLN: Low power and Lossy networks (LLNs) are typically composed of 280 many embedded devices with limited power, memory, and processing 281 resources interconnected by a variety of links, such as IEEE 282 802.15.4 or Low Power WiFi. There is a wide scope of application 283 areas for LLNs, including industrial monitoring, building 284 automation (HVAC, lighting, access control, fire), connected home, 285 healthcare, environmental monitoring, urban sensor networks, 286 energy management, assets tracking and refrigeration.. [sic] 288 Beyond that, LLNs often exhibit considerable loss at the physical 289 layer, with significant variability of the delivery rate, and some 290 short-term unreliability, coupled with some medium term stability 291 that makes it worthwhile to construct medium-term stable directed 292 acyclic graphs for routing and do measurements on the edges such as 293 ETX [RFC6551]. Actual "low power" does not seem to be a defining 294 characteristic for an LLN [I-D.hui-vasseur-roll-rpl-deployment]. 296 LLNs typically are composed of constrained nodes; this leads to the 297 design of operation modes such as the "non-storing mode" defined by 298 RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks 299 [RFC6650]). So, in the terminology of the present document, an LLN 300 is a constrained node network with certain network characteristics, 301 which include constraints on the network as well. 303 2.3.2. LoWPAN, 6LoWPAN 305 One interesting class of a constrained network often used as a 306 constrained node network is the "LoWPAN" [RFC4919], a term inspired 307 from the name of the IEEE 802.15.4 working group (low-rate wireless 308 personal area networks (LR-WPANs)). The expansion of that acronym, 309 "Low-Power Wireless Personal Area Network" contains a hard to justify 310 "Personal" that is due to the history of task group naming in IEEE 311 802 more than due to an orientation of LoWPANs around a single 312 person. Actually, LoWPANs have been suggested for urban monitoring, 313 control of large buildings, and industrial control applications, so 314 the "Personal" can only be considered a vestige. Occasionally the 315 term is read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI]. 316 Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6, 317 "6LoWPAN") also refers to networks built from similarly constrained 318 link layer technologies [I-D.ietf-6lowpan-btle] 319 [I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz]. 321 3. Classes of Constrained Devices 323 Despite the overwhelming variety of Internet-connected devices that 324 can be envisioned, it may be worthwhile to have some succinct 325 terminology for different classes of constrained devices. In this 326 document, the class designations in Table 1 may be used as rough 327 indications of device capabilities: 329 +-------------+-----------------------+-------------------------+ 330 | Name | data size (e.g., RAM) | code size (e.g., Flash) | 331 +-------------+-----------------------+-------------------------+ 332 | Class 0, C0 | << 10 KiB | << 100 KiB | 333 | | | | 334 | Class 1, C1 | ~ 10 KiB | ~ 100 KiB | 335 | | | | 336 | Class 2, C2 | ~ 50 KiB | ~ 250 KiB | 337 +-------------+-----------------------+-------------------------+ 339 Table 1: Classes of Constrained Devices (KiB = 1024 bytes) 341 As of the writing of this document, these characteristics correspond 342 to distinguishable clusters of commercially available chips and 343 design cores for constrained devices. While it is expected that the 344 boundaries of these classes will move over time, Moore's law tends to 345 be less effective in the embedded space than in personal computing 346 devices: Gains made available by increases in transistor count and 347 density are more likely to be invested in reductions of cost and 348 power requirements than into continual increases in computing power. 350 Class 0 devices are very constrained sensor-like motes. Most likely 351 they will not be able to communicate directly with the Internet in a 352 secure manner. Class 0 devices will participate in Internet 353 communications with the help of larger devices acting as proxies, 354 gateways or servers. Class 0 devices generally cannot be secured or 355 managed comprehensively in the traditional sense. They will most 356 likely be preconfigured (and will be reconfigured rarely, if at all), 357 with a very small data set. For management purposes, they could 358 answer keepalive signals and send on/off or basic health indications. 360 Class 1 devices cannot easily talk to other Internet nodes employing 361 a full protocol stack such as using HTTP, TLS and related security 362 protocols and XML-based data representations. However, they have 363 enough power to use a protocol stack specifically designed for 364 constrained nodes (such as CoAP over UDP [I-D.ietf-core-coap]) and 365 participate in meaningful conversations without the help of a gateway 366 node. In particular, they can provide support for the security 367 functions required on a large network. Therefore, they can be 368 integrated as fully developed peers into an IP network, but they need 369 to be parsimonious with state memory, code space, and often power 370 expenditure for protocol and application usage. 372 Class 2 can already support mostly the same protocol stacks as used 373 on notebooks or servers. However, even these devices can benefit 374 from lightweight and energy-efficient protocols and from consuming 375 less bandwidth. Furthermore, using fewer resources for networking 376 leaves more resources available to applications. Thus, using the 377 protocol stacks defined for very constrained devices also on Class 2 378 devices might reduce development costs and increase the 379 interoperability. 381 Constrained devices with capabilities significantly beyond Class 2 382 devices exist. They are less demanding from a standards development 383 point of view as they can largely use existing protocols unchanged. 384 The present document therefore does not make any attempt to define 385 classes beyond Class 2. These devices can still be constrained by a 386 limited energy supply. 388 With respect to examining the capabilities of constrained nodes, 389 particularly for Class 1 devices, it is important to understand what 390 type of applications they are able to run and which protocol 391 mechanisms would be most suitable. Because of memory and other 392 limitations, each specific Class 1 device might be able to support 393 only a few selected functions needed for its intended operation. In 394 other words, the set of functions that can actually be supported is 395 not static per device type: devices with similar constraints might 396 choose to support different functions. Even though Class 2 devices 397 have some more functionality available and may be able to provide a 398 more complete set of functions, they still need to be assessed for 399 the type of applications they will be running and the protocol 400 functions they would need. To be able to derive any requirements, 401 the use cases and the involvement of the devices in the application 402 and the operational scenario need to be analyzed. Use cases may 403 combine constrained devices of multiple classes as well as more 404 traditional Internet nodes. 406 4. Power Terminology 408 Devices not only differ in their computing capabilities, but also in 409 available electrical power and/or energy. While it is harder to find 410 recognizable clusters in this space, it is still useful to introduce 411 some common terminology. 413 4.1. Scaling Properties 415 The power and/or energy available to a device may vastly differ, from 416 kilowatts to microwatts, from essentially unlimited to hundreds of 417 microjoules. 419 Instead of defining classes or clusters, we simply state, in SI 420 units, an approximate value for one or both of the quantities listed 421 in Table 2: 423 +--------+---------------------------------------------+------------+ 424 | Name | Definition | SI Unit | 425 +--------+---------------------------------------------+------------+ 426 | Ps | Sustainable average power available for the | W (Watt) | 427 | | device over the time it is functioning | | 428 | | | | 429 | Et | Total electrical energy available before | J (Joule) | 430 | | the energy source is exhausted | | 431 +--------+---------------------------------------------+------------+ 433 Table 2: Quantities Relevant to Power and Energy 435 The value of Et may need to be interpreted in conjunction with an 436 indication over which period of time the value is given; see the next 437 subsection. 439 Some devices enter a "low-power" mode before the energy available in 440 a period is exhausted, or even have multiple such steps on the way to 441 exhaustion. For these devices, Ps would need to be given for each of 442 the modes/steps. 444 4.2. Classes of Energy Limitation 446 As discussed above, some devices are limited in available energy as 447 opposed to (or in addition to) being limited in available power. 448 Where no relevant limitations exist with respect to energy, the 449 device is classified as E9. The energy limitation may be in total 450 energy available in the usable lifetime of the device (e.g. a device 451 with a non-replaceable primary battery, which is discarded when this 452 battery is exhausted), classified as E2. Where the relevant 453 limitation is for a specific period, this is classified as E1, e.g. a 454 limited amount of energy available for the night with a solar-powered 455 device, or for the period between recharges with a device that is 456 manually connected to a charger, or by a periodic (primary) battery 457 replacement interval. Finally, there may be a limited amount of 458 energy available for a specific event, e.g. for a button press in an 459 energy harvesting light switch; this is classified as E0. Note that 460 many E1 devices in a sense also are E2, as the rechargeable battery 461 has a limited number of useful recharging cycles. 463 In summary, we distinguish (Table 3): 465 +------+------------------------------+-----------------------------+ 466 | Name | Type of energy limitation | Example Power Source | 467 +------+------------------------------+-----------------------------+ 468 | E0 | Event energy-limited | Event-based harvesting | 469 | | | | 470 | E1 | Period energy-limited | Battery that is | 471 | | | periodically recharged or | 472 | | | replaced | 473 | | | | 474 | E2 | Lifetime energy-limited | Non-replaceable primary | 475 | | | battery | 476 | | | | 477 | E9 | No direct quantitative | Mains powered | 478 | | limitations to available | | 479 | | energy | | 480 +------+------------------------------+-----------------------------+ 482 Table 3: Classes of Energy Limitation 484 4.3. Strategies of Using Power for Communication 486 Especially when wireless transmission is used, the radio often 487 consumes a big portion of the total energy consumed by the device. 488 Design parameters such as the available spectrum, the desired range, 489 and the bitrate aimed for, influence the power consumed during 490 transmission and reception; the duration of transmission and 491 reception (including potential reception) influence the total energy 492 consumption. 494 Based on the type of the energy source (e.g., battery or mains power) 495 and how often device needs to communicate, it may use different kinds 496 of strategies for power usage and network attachment. 498 The general strategies for power usage can be described as follows: 500 Always-on: This strategy is most applicable if there is no reason 501 for extreme measures for power saving. The device can stay on in 502 the usual manner all the time. It may be useful to employ power- 503 friendly hardware or limit the number of wireless transmissions, 504 CPU speeds, and other aspects for general power saving and cooling 505 needs, but the device can be connected to the network all the 506 time. 508 Normally-off: Under this strategy, the device sleeps such long 509 periods at a time that once it wakes up, it makes sense for it to 510 not pretend that it has been connected to the network during 511 sleep: The device re-attaches to the network as it is woken up. 512 The main optimization goal is to minimize the effort during such 513 re-attachment process and any resulting application 514 communications. 516 If the device sleeps for long periods of time, and needs to 517 communicate infrequently, the relative increase in energy 518 expenditure during reattachment may be acceptable. 520 Low-power: This strategy is most applicable to devices that need to 521 operate on a very small amount of power, but still need to be able 522 to communicate on a relatively frequent basis. This implies that 523 extremely low power solutions needs to be used for the hardware, 524 chosen link layer mechanisms, and so on. Typically, given the 525 small amount of time between transmissions, despite their sleep 526 state these devices retain some form of network attachment to the 527 network. Techniques used for minimizing power usage for the 528 network communications include minimizing any work from re- 529 establishing communications after waking up, tuning the frequency 530 of communications (including "duty cycling", where components are 531 switched on and off in a regular cycle), and other parameters 532 appropriately. 534 In summary, we distinguish (Table 4): 536 +--------+--------------------+-------------------------------------+ 537 | Name | Strategy | Ability to communicate | 538 +--------+--------------------+-------------------------------------+ 539 | P0 | Normally-off | Re-attach when required | 540 | | | | 541 | P1 | Low-power | Appears connected, perhaps with | 542 | | | high latency | 543 | | | | 544 | P9 | Always-on | Always connected | 545 +--------+--------------------+-------------------------------------+ 547 Table 4: Strategies of Using Power for Communication 549 Note that the discussion above is at the device level; similar 550 considerations can apply at the communications interface level. This 551 document does not define terminology for the latter. 553 A term often used to describe power-saving approaches is "duty- 554 cycling". This describes all forms of periodically switching off 555 some function, leaving it on only for a certain percentage of time 556 (the "duty cycle"). 558 [I-D.ietf-roll-terminology] only distinguishes two levels, defining a 559 Non-sleepy Node as a node that always remains in a fully powered on 560 state (always awake) where it has the capability to perform 561 communication (P9), and a Sleepy Node as a node that may sometimes go 562 into a sleep mode (a low power state to conserve power) and 563 temporarily suspend protocol communication (P0); there is no explicit 564 mention of P1. 566 5. Security Considerations 568 This document introduces common terminology that does not raise any 569 new security issue. Security considerations arising from the 570 constraints discussed in this document need to be discussed in the 571 context of specific protocols. For instance, [I-D.ietf-core-coap] 572 section 11.6, "Constrained node considerations", discusses 573 implications of specific constraints on the security mechanisms 574 employed. A wider view at security in constrained node networks is 575 provided in [I-D.garcia-core-security]. 577 6. IANA Considerations 579 This document has no actions for IANA. 581 7. Acknowledgements 583 Dominique Barthel and Peter van der Stok provided useful comments; 584 Charles Palmer provided a full editorial review. 586 Peter van der Stok insisted that we should have power terminology, 587 hence Section 4. The text for Section 4.3 is mostly lifted from a 588 previous version of [I-D.ietf-lwig-cellular] and has been adapted for 589 this document. 591 8. Informative References 593 [FALL] Fall, K., "A Delay-Tolerant Network Architecture for 594 Challenged Internets", SIGCOMM 2003, 2003. 596 [I-D.brandt-6man-lowpanz] 597 Brandt, A. and J. Buron, "Transmission of IPv6 packets 598 over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02 599 (work in progress), June 2013. 601 [I-D.garcia-core-security] 602 Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and 603 R. Struik, "Security Considerations in the IP-based 604 Internet of Things", draft-garcia-core-security-06 (work 605 in progress), September 2013. 607 [I-D.hui-vasseur-roll-rpl-deployment] 608 Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL 609 deployment experience in large scale networks", draft-hui- 610 vasseur-roll-rpl-deployment-01 (work in progress), July 611 2012. 613 [I-D.ietf-6lowpan-btle] 614 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 615 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 616 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 617 (work in progress), February 2013. 619 [I-D.ietf-core-coap] 620 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 621 Application Protocol (CoAP)", draft-ietf-core-coap-18 622 (work in progress), June 2013. 624 [I-D.ietf-lwig-cellular] 625 Arkko, J., Eriksson, A., and A. Keranen, "Building Power- 626 Efficient CoAP Devices for Cellular Networks", draft-ietf- 627 lwig-cellular-00 (work in progress), August 2013. 629 [I-D.ietf-roll-terminology] 630 Vasseur, J., "Terms used in Routing for Low power And 631 Lossy Networks", draft-ietf-roll-terminology-13 (work in 632 progress), October 2013. 634 [I-D.mariager-6lowpan-v6over-dect-ule] 635 Mariager, P., Petersen, J., and Z. Shelby, "Transmission 636 of IPv6 Packets over DECT Ultra Low Energy", draft- 637 mariager-6lowpan-v6over-dect-ule-03 (work in progress), 638 July 2013. 640 [ISQ-13] International Electrotechnical Commission, "International 641 Standard -- Quantities and units -- Part 13: Information 642 science and technology", IEC 80000-13, March 2008. 644 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 645 793, September 1981. 647 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 648 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 649 Networking Architecture", RFC 4838, April 2007. 651 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 652 over Low-Power Wireless Personal Area Networks (6LoWPANs): 653 Overview, Assumptions, Problem Statement, and Goals", RFC 654 4919, August 2007. 656 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 657 Barthel, "Routing Metrics Used for Path Calculation in 658 Low-Power and Lossy Networks", RFC 6551, March 2012. 660 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 661 Statement and Requirements for IPv6 over Low-Power 662 Wireless Personal Area Network (6LoWPAN) Routing", RFC 663 6606, May 2012. 665 [RFC6650] Falk, J. and M. Kucherawy, "Creation and Use of Email 666 Feedback Reports: An Applicability Statement for the Abuse 667 Reporting Format (ARF)", RFC 6650, June 2012. 669 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 670 Internet", ISBN 9780470747995, 2009. 672 [fifty-billion] 673 Ericsson, "More Than 50 Billion Connected Devices", 674 Ericsson White Paper 284 23-3149 Uen, February 2011, 675 . 678 Authors' Addresses 680 Carsten Bormann 681 Universitaet Bremen TZI 682 Postfach 330440 683 D-28359 Bremen 684 Germany 686 Phone: +49-421-218-63921 687 Email: cabo@tzi.org 689 Mehmet Ersue 690 Nokia Siemens Networks 691 St.-Martinstrasse 76 692 81541 Munich 693 Germany 695 Phone: +49 172 8432301 696 Email: mehmet.ersue@nsn.com 698 Ari Keranen 699 Ericsson 700 Hirsalantie 11 701 02420 Jorvas 702 Finland 704 Email: ari.keranen@ericsson.com