idnits 2.17.1 draft-ietf-lwig-terminology-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2013) is 3937 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-arkko-lwig-cellular-00 == Outdated reference: A later version (-11) exists of draft-clausen-lln-rpl-experiences-06 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-12 == Outdated reference: A later version (-03) exists of draft-mariager-6lowpan-v6over-dect-ule-02 -- 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: January 10, 2014 Nokia Siemens Networks 6 A. Keranen 7 Ericsson 8 July 09, 2013 10 Terminology for Constrained Node Networks 11 draft-ietf-lwig-terminology-05 13 Abstract 15 The Internet Protocol Suite is increasingly used on small devices 16 with severe constraints, creating constrained node networks. This 17 document provides a number of basic terms that have turned out to be 18 useful in the standardization work for constrained environments. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 10, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 4 58 2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 5 59 2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 5 60 2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 6 61 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 6 62 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8 63 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 10 65 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 10 66 4.3. Strategies of Using Power for Communication . . . . . . . 11 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 70 8. Informative References . . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 Small devices with limited CPU, memory, and power resources, so 76 called constrained devices (also known as sensor, smart object, or 77 smart device) can constitute a network, becoming "constrained nodes" 78 in that network. Such a network may itself exhibit constraints, e.g. 79 with unreliable or lossy channels, limited and unpredictable 80 bandwidth, and a highly dynamic topology. 82 Constrained devices might be in charge of gathering information in 83 diverse settings including natural ecosystems, buildings, and 84 factories and sending the information to one or more server stations. 85 Constrained devices may work under severe resource constraints such 86 as limited battery and computing power, little memory, as well as 87 insufficient wireless bandwidth and ability to communicate. Other 88 entities on the network, e.g., a base station or controlling server, 89 might have more computational and communication resources and could 90 support the interaction between the constrained devices and 91 applications in more traditional networks. 93 Today diverse sizes of constrained devices with different resources 94 and capabilities are becoming connected. Mobile personal gadgets, 95 building-automation devices, cellular phones, Machine-to-machine 96 (M2M) devices, etc. benefit from interacting with other "things" 97 nearby or somewhere in the Internet. With this, the Internet of 98 Things (IoT) becomes a reality, built up out of uniquely identifiable 99 and addressable objects (things). And over the next decade, this 100 could grow to large numbers [fifty-billion] of Internet-connected 101 constrained devices, greatly increasing the Internet's size and 102 scope. 104 The present document provides a number of basic terms that have 105 turned out to be useful in the standardization work for constrained 106 environments. The intention is not to exhaustively cover the field, 107 but to make sure a few core terms are used consistently between 108 different groups cooperating in this space. 110 In this document, the term "byte" is used in its now customary sense 111 as a synonym for "octet". Where sizes of semiconductor memory are 112 given, the prefix "kibi" (1024) is combined with "byte" to 113 "kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13]. 115 2. Terminology 117 The main focus of this field of work appears to be _scaling_: 119 o Scaling up Internet technologies to a large number [fifty-billion] 120 of inexpensive nodes, while 122 o scaling down the characteristics of each of these nodes and of the 123 networks being built out of them, to make this scaling up 124 economically and physically viable. 126 The need for scaling down the characteristics of nodes leads to 127 _constrained nodes_. 129 2.1. Constrained Nodes 131 The term "constrained node" is best defined by contrasting the 132 characteristics of a constrained node with certain widely held 133 expectations on more familiar Internet nodes: 135 Constrained Node: A node where some of the characteristics that are 136 otherwise pretty much taken for granted for Internet nodes in 2013 137 are not attainable, often due to cost constraints and/or physical 138 constraints on characteristics such as size, weight, and available 139 power and energy. 141 While this is less than satisfying as a rigorous definition, it is 142 grounded in the state of the art and clearly sets apart constrained 143 nodes from server systems, desktop or laptop computers, powerful 144 mobile devices such as smartphones etc. There may be many design 145 considerations that lead to these constraints, including cost, size, 146 weight, and other scaling factors. 148 (An alternative name, when the properties as a network node are not 149 in focus, is "constrained device".) 151 There are multiple facets to the constraints on nodes, often applying 152 in combination, e.g.: 154 o constraints on the maximum code complexity (ROM/Flash); 156 o constraints on the size of state and buffers (RAM); 158 o constraints on the available power. 160 Section 3 defines a small number of interesting classes ("class-N" 161 for N=0,1,2) of constrained nodes focusing on relevant combinations 162 of the first two constraints. With respect to available power, 163 [RFC6606] distinguishes "power-affluent" nodes (mains-powered or 164 regularly recharged) from "power-constrained nodes" that draw their 165 power from primary batteries or by using energy harvesting; more 166 detailed power terminology is given in Section 4. 168 The use of constrained nodes in networks often also leads to 169 constraints on the networks themselves. However, there may also be 170 constraints on networks that are largely independent from those of 171 the nodes. We therefore distinguish _constrained networks_ and 172 _constrained node networks_. 174 2.2. Constrained Networks 176 We define "constrained network" in a similar way: 178 Constrained Network: A network where some of the characteristics 179 pretty much taken for granted with link layers in common use in 180 the Internet by 2013, are not attainable. 182 Again, there may be several reasons for this: 184 o cost constraints on the network, 186 o constraints of the nodes (for constrained node networks), 188 o physical constraints (e.g., power constraints, environmental 189 constraints, media constraints such as underwater operation, 190 limited spectrum for very high density, electromagnetic 191 compatibility), 193 o regulatory constraints, such as very limited spectrum availability 194 (including limits on effective radiated power and duty cycle), or 195 explosion safety, 197 o technology constraints, such as older and lower speed technologies 198 that are still operational and may need to stay in use for some 199 more time. 201 Constraints may include: 203 o low achievable bit rate (including limits on duty cycle), 205 o high packet loss, packet loss (delivery rate) variability, 207 o severe penalties for using larger packets (e.g., high packet loss 208 due to link layer fragmentation), 210 o lack of (or severe constraints on) advanced services such as IP 211 multicast. 213 2.2.1. Challenged Networks 215 A constrained network is not necessarily a _challenged_ network 216 [FALL]: 218 Challenged Network: A network that has serious trouble maintaining 219 what an application would today expect of the end-to-end IP model, 220 e.g., by: 222 o not being able to offer end-to-end IP connectivity at all; 224 o exhibiting serious interruptions in end-to-end IP connectivity; 226 o exhibiting delay well beyond the Maximum Segment Lifetime (MSL) 227 defined by TCP [RFC0793]. 229 All challenged networks are constrained networks in some sense, but 230 not all constrained networks are challenged networks. There is no 231 well-defined boundary between the two, though. Delay-Tolerant 232 Networking (DTN) has been designed to cope with challenged networks 233 [RFC4838]. 235 2.3. Constrained Node Networks 237 Constrained Node Network: A network whose characteristics are 238 influenced by being composed of a significant portion of 239 constrained nodes. 241 A constrained node network always is a constrained network because of 242 the network constraints stemming from the node constraints, but may 243 also have other constraints that already make it a constrained 244 network. 246 2.3.1. LLN ("low-power lossy network") 248 A related term that has been used recently is "low-power lossy 249 network" (LLN). In its terminology document, the ROLL working group 250 is saying [I-D.ietf-roll-terminology]: 252 LLN: Low power and Lossy networks (LLNs) are typically composed of 253 many embedded devices with limited power, memory, and processing 254 resources interconnected by a variety of links, such as IEEE 255 802.15.4 or Low Power WiFi. There is a wide scope of application 256 areas for LLNs, including industrial monitoring, building 257 automation (HVAC, lighting, access control, fire), connected home, 258 healthcare, environmental monitoring, urban sensor networks, 259 energy management, assets tracking and refrigeration.. [sic] 261 In common usage, LLN often stands for "the network characteristics 262 that RPL has been designed for". Beyond what is said in the ROLL 263 terminology document, LLNs do appear to have significant loss at the 264 physical layer, with significant variability of the delivery rate, 265 and some short-term unreliability, coupled with some medium term 266 stability that makes it worthwhile to construct medium-term stable 267 directed acyclic graphs for routing and do measurements on the edges 268 such as ETX [RFC6551]. Actual "low power" does not seem to be 269 required for an LLN [I-D.hui-vasseur-roll-rpl-deployment], and the 270 positions on scaling of LLNs appear to vary widely 271 [I-D.clausen-lln-rpl-experiences]. 273 The ROLL terminology document states that LLNs typically are composed 274 of constrained nodes; this is also supported by the design of 275 operation modes such as RPL's "non-storing mode". So, in the 276 terminology of the present document, an LLN seems to be a constrained 277 node network with certain network characteristics, which include 278 constraints on the network as well. 280 2.3.2. LoWPAN, 6LoWPAN 282 One interesting class of a constrained network often used as a 283 constrained node network is the "LoWPAN" [RFC4919], a term inspired 284 from the name of the IEEE 802.15.4 working group (low-rate wireless 285 personal area networks (LR-WPANs)). The expansion of that acronym, 286 "Low-Power Wireless Personal Area Network" contains a hard to justify 287 "Personal" that is due to the history of task group naming in IEEE 288 802 more than due to an orientation of LoWPANs around a single 289 person. Actually, LoWPANs have been suggested for urban monitoring, 290 control of large buildings, and industrial control applications, so 291 the "Personal" can only be considered a vestige. Maybe the term is 292 best read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI]. 293 Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6, 294 "6LoWPAN") is now also being used for networks built from similarly 295 constrained link layer technologies [I-D.ietf-6lowpan-btle] 296 [I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz]. 298 3. Classes of Constrained Devices 300 Despite the overwhelming variety of Internet-connected devices that 301 can be envisioned, it may be worthwhile to have some succinct 302 terminology for different classes of constrained devices. In this 303 document, the class designations in Table 1 may be used as rough 304 indications of device capabilities: 306 +-------------+-----------------------+-------------------------+ 307 | Name | data size (e.g., RAM) | code size (e.g., Flash) | 308 +-------------+-----------------------+-------------------------+ 309 | Class 0, C0 | << 10 KiB | << 100 KiB | 310 | | | | 311 | Class 1, C1 | ~ 10 KiB | ~ 100 KiB | 312 | | | | 313 | Class 2, C2 | ~ 50 KiB | ~ 250 KiB | 314 +-------------+-----------------------+-------------------------+ 316 Table 1: Classes of Constrained Devices (KiB = 1024 bytes) 318 As of the writing of this document, these characteristics correspond 319 to distinguishable clusters of commercially available chips and 320 design cores for constrained devices. While it is expected that the 321 boundaries of these classes will move over time, Moore's law tends to 322 be less effective in the embedded space than in personal computing 323 devices: Gains made available by increases in transistor count and 324 density are more likely to be invested in reductions of cost and 325 power requirements than into continual increases in computing power. 327 Class 0 devices are very constrained sensor-like motes. Most likely 328 they will not be able to communicate directly with the Internet in a 329 secure manner. Class 0 devices will participate in Internet 330 communications with the help of larger devices acting as proxies, 331 gateways or servers. Class 0 devices generally cannot be secured or 332 managed comprehensively in the traditional sense. They will most 333 likely be preconfigured (and will be reconfigured rarely, if at all), 334 with a very small data set. For management purposes, they could 335 answer keepalive signals and send on/off or basic health indications. 337 Class 1 devices cannot easily talk to other Internet nodes employing 338 a full protocol stack such as using HTTP, TLS and related security 339 protocols and XML-based data representations. However, they have 340 enough power to use a protocol stack specifically designed for 341 constrained nodes (e.g., CoAP over UDP) and participate in meaningful 342 conversations without the help of a gateway node. In particular, 343 they can provide support for the security functions required on a 344 large network. Therefore, they can be integrated as fully developed 345 peers into an IP network, but they need to be parsimonious with state 346 memory, code space, and often power expenditure for protocol and 347 application usage. 349 Class 2 can already support mostly the same protocol stacks as used 350 on notebooks or servers. However, even these devices can benefit 351 from lightweight and energy-efficient protocols and from consuming 352 less bandwidth. Furthermore, using fewer resources for networking 353 leaves more resources available to applications. Thus, using the 354 protocol stacks defined for very constrained devices also on Class 2 355 devices might reduce development costs and increase the 356 interoperability. 358 Constrained devices with capabilities significantly beyond Class 2 359 devices exist. They are less demanding from a standards development 360 point of view as they can largely use existing protocols unchanged. 361 The present document therefore does not make any attempt to define 362 classes beyond Class 2. These devices can still be constrained by a 363 limited energy supply. 365 With respect to examining the capabilities of constrained nodes, 366 particularly for Class 1 devices, it is important to understand what 367 type of applications they are able to run and which protocol 368 mechanisms would be most suitable. Because of memory and other 369 limitations, each specific Class 1 device might be able to support 370 only a few selected functions needed for its intended operation. In 371 other words, the set of functions that can actually be supported is 372 not static per device type: devices with similar constraints might 373 choose to support different functions. Even though Class 2 devices 374 have some more functionality available and may be able to provide a 375 more complete set of functions, they still need to be assessed for 376 the type of applications they will be running and the protocol 377 functions they would need. To be able to derive any requirements, 378 the use cases and the involvement of the devices in the application 379 and the operational scenario need to be analyzed. Use cases may 380 combine constrained devices of multiple classes as well as more 381 traditional Internet nodes. 383 4. Power Terminology 385 Devices not only differ in their computing capabilities, but also in 386 available electrical power and/or energy. While it is harder to find 387 recognizable clusters in this space, it is still useful to introduce 388 some common terminology. 390 4.1. Scaling Properties 392 The power and/or energy available to a device may vastly differ, from 393 kilowatts to microwatts, from essentially unlimited to hundreds of 394 microjoules. 396 Instead of defining classes or clusters, we propose simply stating, 397 in SI units, an approximate value for one or both of the quantities 398 listed in Table 2: 400 +--------+---------------------------------------------+------------+ 401 | Name | Definition | SI Unit | 402 +--------+---------------------------------------------+------------+ 403 | Ps | Sustainable average power available for the | W (Watt) | 404 | | device over the time it is functioning | | 405 | | | | 406 | Et | Total electrical energy available before | J (Joule) | 407 | | the energy source is exhausted | | 408 +--------+---------------------------------------------+------------+ 410 Table 2: Quantities Relevant to Power and Energy 412 The value of Et may need to be interpreted in conjunction with an 413 indication over which period of time the value is given; see the next 414 subsection. 416 4.2. Classes of Energy Limitation 418 As discussed above, some devices are limited in available energy as 419 opposed to (or in addition to) being limited in available power. 420 Where no relevant limitations exist with respect to energy, the 421 device is classified as E3. The energy limitation may be in total 422 energy available in the usable lifetime of the device (e.g. a device 423 with a non-replaceable primary battery, which is discarded when this 424 battery is exhausted), classified as E2. Where the relevant 425 limitation is for a specific period, this is classified as E1, e.g. 426 a limited amount of energy available for the night with a solar- 427 powered device, or for the period between recharges with a device 428 that is manually connected to a charger, or by a periodic (primary) 429 battery replacement interval. Finally, there may be a limited amount 430 of energy available for a specific event, e.g. for a button press in 431 an energy harvesting light switch; this is classified as E0. Note 432 that many E1 devices in a sense also are E2, as the rechargeable 433 battery has a limited number of useful recharging cycles. 435 In summary, we distinguish (Table 3): 437 +------+------------------------------+-----------------------------+ 438 | Name | Type of energy limitation | Example Power Source | 439 +------+------------------------------+-----------------------------+ 440 | E0 | Event energy-limited | Event-based harvesting | 441 | | | | 442 | E1 | Period energy-limited | Battery that is | 443 | | | periodically recharged or | 444 | | | replaced | 445 | | | | 446 | E2 | Lifetime energy-limited | Non-replaceable primary | 447 | | | battery | 448 | | | | 449 | E3 | No direct quantitative | Mains powered | 450 | | limitations to available | | 451 | | energy | | 452 +------+------------------------------+-----------------------------+ 454 Table 3: Classes of Energy Limitation 456 4.3. Strategies of Using Power for Communication 458 Especially when wireless transmission is used, the radio often 459 consumes a big portion of the total energy consumed by the device. 460 Design parameters such as the available spectrum, the desired range, 461 and the bitrate aimed for, influence the power consumed during 462 transmission and reception; the duration of transmission and 463 reception (including potential reception) influence the total energy 464 consumption. 466 Based on the type of the energy source (e.g., battery or mains power) 467 and how often device needs to communicate, it may use different kinds 468 of strategies for power usage and network attachment. 470 The general strategies for power usage can be described as follows: 472 Always-on: This strategy is most applicable if there is no reason 473 for extreme measures for power saving. The device can stay on in 474 the usual manner all the time. It may be useful to employ power- 475 friendly hardware or limit the number of wireless transmissions, 476 CPU speeds, and other aspects for general power saving and cooling 477 needs, but the device can be connected to the network all the 478 time. 480 Always-off: Under this strategy, the device sleeps such long periods 481 at a time that once it wakes up, it makes sense for it to not 482 pretend that it has been connected to the network during sleep: 483 The device re-attaches to the network as it is woken up. The main 484 optimization goal is to minimize the effort during such re- 485 attachment process and any resulting application communications. 487 If the device sleeps for long periods of time, and needs to 488 communicate infrequently, the relative increase in energy 489 expenditure during reattachment may be acceptable. 491 Low-power: This strategy is most applicable to devices that need to 492 operate on a very small amount of power, but still need to be able 493 to communicate on a relatively frequent basis. This implies that 494 extremely low power solutions needs to be used for the hardware, 495 chosen link layer mechanisms, and so on. Typically, given the 496 small amount of time between transmissions, despite their sleep 497 state these devices retain some form of network attachment to the 498 network. Techniques used for minimizing power usage for the 499 network communications include minimizing any work from re- 500 establishing communications after waking up, tuning the frequency 501 of communications, and other parameters appropriately. 503 In summary, we distinguish (Table 4): 505 +------+------------+----------------------------------------------+ 506 | Name | Strategy | Ability to communicate | 507 +------+------------+----------------------------------------------+ 508 | S0 | Always-off | Re-attach when required | 509 | | | | 510 | S1 | Low-power | Appears connected, perhaps with high latency | 511 | | | | 512 | S2 | Always-on | Always connected | 513 +------+------------+----------------------------------------------+ 515 Table 4: Strategies of Using Power for Communication 517 Note that the discussion above is at the device level; similar 518 considerations can apply at the communications interface level. This 519 document does not define terminology for the latter. 521 5. Security Considerations 523 This document introduces common terminology that does not raise any 524 new security issue. Security considerations arising from the 525 constraints discussed in this document need to be discussed in the 526 context of specific protocols. For instance, [I-D.ietf-core-coap] 527 section 11.6, "Constrained node considerations", discusses 528 implications of specific constraints on the security mechanisms 529 employed. 531 6. IANA Considerations 533 This document has no actions for IANA. 535 7. Acknowledgements 537 Dominique Barthel and Peter van der Stok provided useful comments; 538 Charles Palmer provided a full editorial review. 540 Peter van der Stok insisted that we should have power terminology, 541 hence Section 4. The text for Section 4.3 is mostly lifted from 542 [I-D.arkko-lwig-cellular] and has been adapted for this document. 544 8. Informative References 546 [FALL] Fall, K., "A Delay-Tolerant Network Architecture for 547 Challenged Internets", SIGCOMM 2003, 2003. 549 [I-D.arkko-lwig-cellular] 550 Arkko, J., Eriksson, A., and A. Keraenen, "Building Power- 551 Efficient CoAP Devices for Cellular Networks", draft- 552 arkko-lwig-cellular-00 (work in progress), February 2013. 554 [I-D.brandt-6man-lowpanz] 555 Brandt, A. and J. Buron, "Transmission of IPv6 packets 556 over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02 557 (work in progress), June 2013. 559 [I-D.clausen-lln-rpl-experiences] 560 Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y. 561 Igarashi, "Observations of RPL: IPv6 Routing Protocol for 562 Low power and Lossy Networks", draft-clausen-lln-rpl- 563 experiences-06 (work in progress), February 2013. 565 [I-D.hui-vasseur-roll-rpl-deployment] 566 Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL 567 deployment experience in large scale networks", draft-hui- 568 vasseur-roll-rpl-deployment-01 (work in progress), July 569 2012. 571 [I-D.ietf-6lowpan-btle] 572 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 573 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 574 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 575 (work in progress), February 2013. 577 [I-D.ietf-core-coap] 578 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 579 Application Protocol (CoAP)", draft-ietf-core-coap-18 580 (work in progress), June 2013. 582 [I-D.ietf-roll-terminology] 583 Vasseur, J., "Terminology in Low power And Lossy 584 Networks", draft-ietf-roll-terminology-12 (work in 585 progress), March 2013. 587 [I-D.mariager-6lowpan-v6over-dect-ule] 588 Mariager, P. and J. Petersen, "Transmission of IPv6 589 Packets over DECT Ultra Low Energy", draft-mariager- 590 6lowpan-v6over-dect-ule-02 (work in progress), May 2012. 592 [ISQ-13] International Electrotechnical Commission, "International 593 Standard -- Quantities and units -- Part 13: Information 594 science and technology", IEC 80000-13, March 2008. 596 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 597 793, September 1981. 599 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 600 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 601 Networking Architecture", RFC 4838, April 2007. 603 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 604 over Low-Power Wireless Personal Area Networks (6LoWPANs): 605 Overview, Assumptions, Problem Statement, and Goals", RFC 606 4919, August 2007. 608 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 609 Barthel, "Routing Metrics Used for Path Calculation in 610 Low-Power and Lossy Networks", RFC 6551, March 2012. 612 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 613 Statement and Requirements for IPv6 over Low-Power 614 Wireless Personal Area Network (6LoWPAN) Routing", RFC 615 6606, May 2012. 617 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 618 Internet", ISBN 9780470747995, 2009. 620 [fifty-billion] 621 Ericsson, "More Than 50 Billion Connected Devices", 622 Ericsson White Paper 284 23-3149 Uen, February 2011, 623 . 626 Authors' Addresses 628 Carsten Bormann 629 Universitaet Bremen TZI 630 Postfach 330440 631 D-28359 Bremen 632 Germany 634 Phone: +49-421-218-63921 635 Email: cabo@tzi.org 637 Mehmet Ersue 638 Nokia Siemens Networks 639 St.-Martinstrasse 76 640 81541 Munich 641 Germany 643 Phone: +49 172 8432301 644 Email: mehmet.ersue@nsn.com 646 Ari Keranen 647 Ericsson 648 Hirsalantie 11 649 02420 Jorvas 650 Finland 652 Email: ari.keranen@ericsson.com