idnits 2.17.1 draft-bormann-lwig-7228bis-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 (9 March 2020) is 1471 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: 10 September 2020 6 A. Keranen 7 Ericsson 8 C. Gomez 9 UPC/i2CAT 10 9 March 2020 12 Terminology for Constrained-Node Networks 13 draft-bormann-lwig-7228bis-06 15 Abstract 17 The Internet Protocol Suite is increasingly used on small devices 18 with severe constraints on power, memory, and processing resources, 19 creating constrained-node networks. This document provides a number 20 of basic terms that have been useful in the standardization work for 21 constrained-node networks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 10 September 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Core Terminology . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5 60 2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6 61 2.3. Constrained-Node Networks . . . . . . . . . . . . . . . . 6 62 2.3.1. LLN . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7 64 2.3.3. LPWAN . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8 66 3.1. Firmware/Software upgradeability . . . . . . . . . . . . 11 67 3.2. Isolation functionality . . . . . . . . . . . . . . . . . 12 68 3.3. Shielded secrets . . . . . . . . . . . . . . . . . . . . 12 69 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 13 70 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 13 71 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 14 72 4.3. Strategies for Using Power for Communication . . . . . . 15 73 4.4. Strategies of Keeping Time over Power Events . . . . . . 16 74 5. Classes of Networks . . . . . . . . . . . . . . . . . . . . . 18 75 5.1. Classes of link layer MTU size . . . . . . . . . . . . . 19 76 5.2. Class of Internet Integration . . . . . . . . . . . . . . 20 77 5.3. Classes of physical layer bit rate . . . . . . . . . . . 20 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 80 8. Informative References . . . . . . . . . . . . . . . . . . . 22 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 84 1. Introduction 86 Small devices with limited CPU, memory, and power resources, so- 87 called "constrained devices" (often used as sensors/actuators, smart 88 objects, or smart devices) can form a network, becoming "constrained 89 nodes" in that network. Such a network may itself exhibit 90 constraints, e.g., with unreliable or lossy channels, limited and 91 unpredictable bandwidth, and a highly dynamic topology. 93 Constrained devices might be in charge of gathering information in 94 diverse settings, including natural ecosystems, buildings, and 95 factories, and sending the information to one or more server 96 stations. They might also act on information, by performing some 97 physical action, including displaying it. Constrained devices may 98 work under severe resource constraints such as limited battery and 99 computing power, little memory, and insufficient wireless bandwidth 100 and ability to communicate; these constraints often exacerbate each 101 other. Other entities on the network, e.g., a base station or 102 controlling server, might have more computational and communication 103 resources and could support the interaction between the constrained 104 devices and applications in more traditional networks. 106 Today, diverse sizes of constrained devices with different resources 107 and capabilities are becoming connected. Mobile personal gadgets, 108 building-automation devices, cellular phones, machine-to-machine 109 (M2M) devices, and other devices benefit from interacting with other 110 "things" nearby or somewhere in the Internet. With this, the 111 Internet of Things (IoT) becomes a reality, built up out of uniquely 112 identifiable and addressable objects (things). Over the next decade, 113 this could grow to large numbers of Internet-connected constrained 114 devices ([IoT-2025] predicts that by, 2025, more than 2500 devices 115 will be connected to the Internet per second), greatly increasing the 116 Internet's size and scope. 118 The present document provides a number of basic terms that have been 119 useful in the standardization work for constrained environments. The 120 intention is not to exhaustively cover the field but to make sure a 121 few core terms are used consistently between different groups 122 cooperating in this space. 124 The present document is a revision of [RFC7228]. 126 In this document, the term "byte" is used in its now customary sense 127 as a synonym for "octet". Where sizes of semiconductor memory are 128 given, the prefix "kibi" (1024) is combined with "byte" to 129 "kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13]. 131 In computing, the term "power" is often used for the concept of 132 "computing power" or "processing power", as in CPU performance. In 133 this document, the term stands for electrical power unless explicitly 134 stated otherwise. "Mains-powered" is used as a shorthand for being 135 permanently connected to a stable electrical power grid. 137 2. Core Terminology 139 There are two important aspects to _scaling_ within the Internet of 140 Things: 142 * scaling up Internet technologies to a large number [IoT-2025] of 143 inexpensive nodes, while 145 * scaling down the characteristics of each of these nodes and of the 146 networks being built out of them, to make this scaling up 147 economically and physically viable. 149 The need for scaling down the characteristics of nodes leads to 150 "constrained nodes". 152 2.1. Constrained Nodes 154 The term "constrained node" is best defined by contrasting the 155 characteristics of a constrained node with certain widely held 156 expectations on more familiar Internet nodes: 158 Constrained Node: A node where some of the characteristics that are 159 otherwise pretty much taken for granted for Internet nodes at the 160 time of writing are not attainable, often due to cost constraints 161 and/or physical constraints on characteristics such as size, 162 weight, and available power and energy. The tight limits on 163 power, memory, and processing resources lead to hard upper bounds 164 on state, code space, and processing cycles, making optimization 165 of energy and network bandwidth usage a dominating consideration 166 in all design requirements. Also, some layer-2 services such as 167 full connectivity and broadcast/multicast may be lacking. 169 While this is not a rigorous definition, it is grounded in the state 170 of the art and clearly sets apart constrained nodes from server 171 systems, desktop or laptop computers, powerful mobile devices such as 172 smartphones, etc. There may be many design considerations that lead 173 to these constraints, including cost, size, weight, and other scaling 174 factors. 176 (An alternative term, when the properties as a network node are not 177 in focus, is "constrained device".) 179 There are multiple facets to the constraints on nodes, often applying 180 in combination, for example: 182 * constraints on the maximum code complexity (ROM/Flash), 184 * constraints on the size of state and buffers (RAM), 186 * constraints on the amount of computation feasible in a period of 187 time ("processing power"), 189 * constraints on the available power, and 191 * constraints on user interface and accessibility in deployment 192 (ability to set keys, update software, etc.). 194 Section 3 defines a number of interesting classes ("class-N") of 195 constrained nodes focusing on relevant combinations of the first two 196 constraints. With respect to available power, [RFC6606] 197 distinguishes "power-affluent" nodes (mains-powered or regularly 198 recharged) from "power-constrained nodes" that draw their power from 199 primary batteries or by using energy harvesting; more detailed power 200 terminology is given in Section 4. 202 The use of constrained nodes in networks often also leads to 203 constraints on the networks themselves. However, there may also be 204 constraints on networks that are largely independent from those of 205 the nodes. We therefore distinguish "constrained networks" from 206 "constrained-node networks". 208 2.2. Constrained Networks 210 We define "constrained network" in a similar way: 212 Constrained Network: A network where some of the characteristics 213 pretty much taken for granted with link layers in common use in 214 the Internet at the time of writing are not attainable. 216 Constraints may include: 218 * low achievable bitrate/throughput (including limits on duty 219 cycle), 221 * high packet loss and high variability of packet loss (delivery 222 rate), 224 * highly asymmetric link characteristics, 226 * severe penalties for using larger packets (e.g., high packet loss 227 due to link-layer fragmentation), 229 * limits on reachability over time (a substantial number of devices 230 may power off at any point in time but periodically "wake up" and 231 can communicate for brief periods of time), and 233 * lack of (or severe constraints on) advanced services such as IP 234 multicast. 236 More generally, we speak of constrained networks whenever at least 237 some of the nodes involved in the network exhibit these 238 characteristics. 240 Again, there may be several reasons for this: 242 * cost constraints on the network, 244 * constraints posed by the nodes (for constrained-node networks), 246 * physical constraints (e.g., power constraints, environmental 247 constraints, media constraints such as underwater operation, 248 limited spectrum for very high density, electromagnetic 249 compatibility), 251 * regulatory constraints, such as very limited spectrum availability 252 (including limits on effective radiated power and duty cycle) or 253 explosion safety, and 255 * technology constraints, such as older and lower-speed technologies 256 that are still operational and may need to stay in use for some 257 more time. 259 2.2.1. Challenged Networks 261 A constrained network is not necessarily a "challenged network" 262 [FALL]: 264 Challenged Network: A network that has serious trouble maintaining 265 what an application would today expect of the end-to-end IP model, 266 e.g., by: 268 * not being able to offer end-to-end IP connectivity at all, 270 * exhibiting serious interruptions in end-to-end IP connectivity, 271 or 273 * exhibiting delay well beyond the Maximum Segment Lifetime (MSL) 274 defined by TCP [RFC0793]. 276 All challenged networks are constrained networks in some sense, but 277 not all constrained networks are challenged networks. There is no 278 well-defined boundary between the two, though. Delay-Tolerant 279 Networking (DTN) has been designed to cope with challenged networks 280 [RFC4838]. 282 2.3. Constrained-Node Networks 284 Constrained-Node Network: A network whose characteristics are 285 influenced by being composed of a significant portion of 286 constrained nodes. 288 A constrained-node network always is a constrained network because of 289 the network constraints stemming from the node constraints, but it 290 may also have other constraints that already make it a constrained 291 network. 293 The rest of this subsection introduces two additional terms that are 294 in active use in the area of constrained-node networks, without an 295 intent to define them: LLN and (6)LoWPAN. 297 2.3.1. LLN 299 A related term that has been used to describe the focus of the IETF 300 ROLL working group is "Low-Power and Lossy Network (LLN)". The ROLL 301 (Routing Over Low-Power and Lossy) terminology document [RFC7102] 302 defines LLNs as follows: 304 LLN: Low-Power and Lossy Network. Typically composed of many 305 embedded devices with limited power, memory, and processing 306 resources interconnected by a variety of links, such as IEEE 307 802.15.4 or low-power Wi-Fi. There is a wide scope of application 308 areas for LLNs, including industrial monitoring, building 309 automation (heating, ventilation, and air conditioning (HVAC), 310 lighting, access control, fire), connected home, health care, 311 environmental monitoring, urban sensor networks, energy 312 management, assets tracking, and refrigeration. 314 Beyond that, LLNs often exhibit considerable loss at the physical 315 layer, with significant variability of the delivery rate, and some 316 short-term unreliability, coupled with some medium-term stability 317 that makes it worthwhile to both construct directed acyclic graphs 318 that are medium-term stable for routing and do measurements on the 319 edges such as Expected Transmission Count (ETX) [RFC6551]. Not all 320 LLNs comprise low-power nodes [I-D.hui-vasseur-roll-rpl-deployment]. 322 LLNs typically are composed of constrained nodes; this leads to the 323 design of operation modes such as the "non-storing mode" defined by 324 RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks 325 [RFC6550]). So, in the terminology of the present document, an LLN 326 is a constrained-node network with certain network characteristics, 327 which include constraints on the network as well. 329 2.3.2. LoWPAN, 6LoWPAN 331 One interesting class of a constrained network often used as a 332 constrained-node network is "LoWPAN" [RFC4919], a term inspired from 333 the name of an IEEE 802.15.4 working group (low-rate wireless 334 personal area networks (LR-WPANs)). The expansion of the LoWPAN 335 acronym, "Low-Power Wireless Personal Area Network", contains a hard- 336 to-justify "Personal" that is due to the history of task group naming 337 in IEEE 802 more than due to an orientation of LoWPANs around a 338 single person. Actually, LoWPANs have been suggested for urban 339 monitoring, control of large buildings, and industrial control 340 applications, so the "Personal" can only be considered a vestige. 341 Occasionally, the term is read as "Low-Power Wireless Area Networks" 342 [WEI]. Originally focused on IEEE 802.15.4, "LoWPAN" (or when used 343 for IPv6, "6LoWPAN") also refers to networks built from similarly 344 constrained link-layer technologies [RFC7668] [RFC8105] [RFC7428]. 346 2.3.3. LPWAN 348 An overview over Low-Power Wide Area Network (LPWAN) technologies is 349 provided by [RFC8376]. 351 3. Classes of Constrained Devices 353 Despite the overwhelming variety of Internet-connected devices that 354 can be envisioned, it may be worthwhile to have some succinct 355 terminology for different classes of constrained devices. 357 Before we get to that, let's first distinguish two big rough groups 358 of devices based on their CPU capabilities: 360 * Microcontroller-class devices (sometimes called "M-class"). These 361 often (but not always) include RAM and code storage on chip and 362 would struggle to support more powerful general-purpose operating 363 systems, e.g., they do not have an MMU (memory management unit). 364 They use most of their pins for interfaces to application hardware 365 such as digital in/out (the latter often Pulse Width Modulation 366 (PWM)-controllable), ADC/DACs (analog-to-digital and digital-to- 367 analog converters), etc. Where this hardware is specialized for 368 an application, we may talk about "Systems on a Chip" (SOC). 369 These devices often implement elaborate sleep modes to achieve 370 microwatt- or at least milliwatt-level sustained power usage (Ps, 371 see below). 373 * General-purpose-class devices (sometimes called "A-class"). These 374 usually have RAM and Flash storage on separate chips (not always 375 separate packages), and offer support for general-purpose 376 operating systems such as Linux, e.g. an MMU. Many of the pins on 377 the CPU chip are dedicated to interfacing with RAM and other 378 memory. Some general-purpose-class devices integrate some 379 application hardware such as video controllers, these are often 380 also called "Systems on a Chip" (SOC). While these chips also 381 include sleep modes, they are usually more on the watt side of 382 sustained power usage (Ps). 384 If the distinction between these groups needs to be made in this 385 document, we distinguish group "M" (microcontroller) from group "J" 386 (general purpose). 388 In this document, the class designations in Table 1 may be used as 389 rough indications of device capabilities. Note that the classes from 390 10 upwards are not really constrained devices in the sense of the 391 previous section; they may still be useful to discuss constraints in 392 larger devices: 394 +-------+---------+-------------+---------------+-------------+ 395 | Group | Name | data size | code size | Examples | 396 | | | (e.g., RAM) | (e.g., Flash) | | 397 +=======+=========+=============+===============+=============+ 398 | M | Class | << 10 KiB | << 100 KiB | ATtiny | 399 | | 0, C0 | | | | 400 +-------+---------+-------------+---------------+-------------+ 401 | M | Class | ~ 10 KiB | ~ 100 KiB | STM32F103CB | 402 | | 1, C1 | | | | 403 +-------+---------+-------------+---------------+-------------+ 404 | M | Class | ~ 50 KiB | ~ 250 KiB | STM32F103RC | 405 | | 2, C2 | | | | 406 +-------+---------+-------------+---------------+-------------+ 407 | M | Class | ~ 100 KiB | ~ 500..1000 | STM32F103RG | 408 | | 3, C3 | | KiB | | 409 +-------+---------+-------------+---------------+-------------+ 410 | M | Class | ~ 300..1000 | ~ 1000..2000 | "Luxury" | 411 | | 4, C4 | KiB | KiB | | 412 +-------+---------+-------------+---------------+-------------+ 413 | J | Class | 4-8 MiB | (?) | OpenWRT | 414 | | 10, C10 | | | routers | 415 +-------+---------+-------------+---------------+-------------+ 416 | J | Class | 0.5..1 GiB | (lots) | Raspberry | 417 | | 15, C13 | | | PI | 418 +-------+---------+-------------+---------------+-------------+ 419 | J | Class | 1..4 GiB | (lots) | Smartphones | 420 | | 16, C15 | | | | 421 +-------+---------+-------------+---------------+-------------+ 422 | J | Class | 4..32 GiB | (lots) | Laptops | 423 | | 17, C16 | | | | 424 +-------+---------+-------------+---------------+-------------+ 425 | J | Class | (lots) | (lots) | Servers | 426 | | 19, C19 | | | | 427 +-------+---------+-------------+---------------+-------------+ 429 Table 1: Classes of Constrained Devices (KiB = 1024 bytes) 431 As of the writing of this document, these characteristics correspond 432 to distinguishable clusters of commercially available chips and 433 design cores for constrained devices. While it is expected that the 434 boundaries of these classes will move over time, Moore's law tends to 435 be less effective in the embedded space than in personal computing 436 devices: gains made available by increases in transistor count and 437 density are more likely to be invested in reductions of cost and 438 power requirements than into continual increases in computing power. 440 Class 0 devices are very constrained sensor-like motes. They are so 441 severely constrained in memory and processing capabilities that most 442 likely they will not have the resources required to communicate 443 directly with the Internet in a secure manner (rare heroic, narrowly 444 targeted implementation efforts notwithstanding). Class 0 devices 445 will participate in Internet communications with the help of larger 446 devices acting as proxies, gateways, or servers. Class 0 devices 447 generally cannot be secured or managed comprehensively in the 448 traditional sense. They will most likely be preconfigured (and will 449 be reconfigured rarely, if at all) with a very small data set. For 450 management purposes, they could answer keepalive signals and send on/ 451 off or basic health indications. 453 Class 1 devices are quite constrained in code space and processing 454 capabilities, such that they cannot easily talk to other Internet 455 nodes employing a full protocol stack such as using HTTP, Transport 456 Layer Security (TLS), and related security protocols and XML-based 457 data representations. However, they are capable enough to use a 458 protocol stack specifically designed for constrained nodes (such as 459 the Constrained Application Protocol (CoAP) over UDP [RFC7252]) and 460 participate in meaningful conversations without the help of a gateway 461 node. In particular, they can provide support for the security 462 functions required on a large network. Therefore, they can be 463 integrated as fully developed peers into an IP network, but they need 464 to be parsimonious with state memory, code space, and often power 465 expenditure for protocol and application usage. 467 Class 2 devices are less constrained and fundamentally capable of 468 supporting most of the same protocol stacks as used on notebooks or 469 servers. However, even these devices can benefit from lightweight 470 and energy-efficient protocols and from consuming less bandwidth. 471 Furthermore, using fewer resources for networking leaves more 472 resources available to applications. Thus, using the protocol stacks 473 defined for more constrained devices on Class 2 devices might reduce 474 development costs and increase the interoperability. 476 Constrained devices with capabilities significantly beyond Class 2 477 devices exist. They are less demanding from a standards development 478 point of view as they can largely use existing protocols unchanged. 479 The previous version of the present document therefore did not make 480 any attempt to define constrained classes beyond Class 2. These 481 devices, and to a certain extent even J-group devices, can still be 482 constrained by a limited energy supply. Class 3 and 4 devices are 483 less clearly defined than the lower classes; they are even less 484 constrained. In particular Class 4 devices are powerful enough to 485 quite comfortably run, e.g., JavaScript interpreters, together with 486 elaborate network stacks. Additional classes may need to be defined 487 based on protection capabilities, e.g., an MPU (memory protection 488 unit; true MMUs are typically only found in J-group devices). 490 With respect to examining the capabilities of constrained nodes, 491 particularly for Class 1 devices, it is important to understand what 492 type of applications they are able to run and which protocol 493 mechanisms would be most suitable. Because of memory and other 494 limitations, each specific Class 1 device might be able to support 495 only a few selected functions needed for its intended operation. In 496 other words, the set of functions that can actually be supported is 497 not static per device type: devices with similar constraints might 498 choose to support different functions. Even though Class 2 devices 499 have some more functionality available and may be able to provide a 500 more complete set of functions, they still need to be assessed for 501 the type of applications they will be running and the protocol 502 functions they would need. To be able to derive any requirements, 503 the use cases and the involvement of the devices in the application 504 and the operational scenario need to be analyzed. Use cases may 505 combine constrained devices of multiple classes as well as more 506 traditional Internet nodes. 508 3.1. Firmware/Software upgradeability 510 Platforms may differ in their firmware or software upgradeability. 511 The below is a first attempt at classifying this. 513 +------+------------------------------------------------------------+ 514 | Name | Firmware/Software upgradeability | 515 +======+============================================================+ 516 | F0 | no (discard for upgrade) | 517 +------+------------------------------------------------------------+ 518 | F1 | replaceable, out of service during replacement, reboot | 519 +------+------------------------------------------------------------+ 520 | F2 | patchable during operation, reboot required | 521 +------+------------------------------------------------------------+ 522 | F3 | patchable during operation, restart not visible | 523 | | externally | 524 +------+------------------------------------------------------------+ 525 | F9 | app-level upgradeability, no reboot required | 526 | | ("hitless") | 527 +------+------------------------------------------------------------+ 529 Table 2: Levels of software update capabilities 531 3.2. Isolation functionality 533 TBD. This section could discuss the ability of the platform to 534 isolate different components. The categories below are not mutually 535 exclusive; we need to build relevant clusters. 537 +------+-----------------------------------------------------------+ 538 | Name | Isolation functionality | 539 +======+===========================================================+ 540 | Is0 | no isolation | 541 +------+-----------------------------------------------------------+ 542 | Is2 | MPU (memory protection unit), at least boundary registers | 543 +------+-----------------------------------------------------------+ 544 | Is5 | MMU with Linux-style kernel/user | 545 +------+-----------------------------------------------------------+ 546 | Is7 | Virtualization-style isolation | 547 +------+-----------------------------------------------------------+ 548 | Is8 | Secure enclave isolation | 549 +------+-----------------------------------------------------------+ 551 Table 3: Levels of isolation capabilities 553 3.3. Shielded secrets 555 [Need to identify clusters] 557 Some platforms can keep shielded secrets (usually in conjunction with 558 secure enclave functionality). 560 +------+--------------------------------+ 561 | Name | Secret shielding functionality | 562 +======+================================+ 563 | Sh0 | no secret shielding | 564 +------+--------------------------------+ 565 | Sh1 | some secret shielding | 566 +------+--------------------------------+ 567 | Sh9 | perfect secret shielding | 568 +------+--------------------------------+ 570 Table 4: Levels of secret shielding 571 capabilities 573 4. Power Terminology 575 Devices not only differ in their computing capabilities but also in 576 available power and/or energy. While it is harder to find 577 recognizable clusters in this space, it is still useful to introduce 578 some common terminology. 580 4.1. Scaling Properties 582 The power and/or energy available to a device may vastly differ, from 583 kilowatts to microwatts, from essentially unlimited to hundreds of 584 microjoules. 586 Instead of defining classes or clusters, we simply state, using the 587 International System of Units (SI units), an approximate value for 588 one or both of the quantities listed in Table 5: 590 +------+--------------------------------------------+---------+ 591 | Name | Definition | SI Unit | 592 +======+============================================+=========+ 593 | Ps | Sustainable average power available for | W | 594 | | the device over the time it is functioning | (Watt) | 595 +------+--------------------------------------------+---------+ 596 | Et | Total electrical energy available before | J | 597 | | the energy source is exhausted | (Joule) | 598 +------+--------------------------------------------+---------+ 600 Table 5: Quantities Relevant to Power and Energy 602 The value of Et may need to be interpreted in conjunction with an 603 indication over which period of time the value is given; see 604 Section 4.2. 606 Some devices enter a "low-power" mode before the energy available in 607 a period is exhausted or even have multiple such steps on the way to 608 exhaustion. For these devices, Ps would need to be given for each of 609 the modes/steps. 611 4.2. Classes of Energy Limitation 613 As discussed above, some devices are limited in available energy as 614 opposed to (or in addition to) being limited in available power. 615 Where no relevant limitations exist with respect to energy, the 616 device is classified as E9. The energy limitation may be in total 617 energy available in the usable lifetime of the device (e.g., a device 618 that is discarded when its non-replaceable primary battery is 619 exhausted), classified as E2. Where the relevant limitation is for a 620 specific period, the device is classified as E1, e.g., a solar- 621 powered device with a limited amount of energy available for the 622 night, a device that is manually connected to a charger and has a 623 period of time between recharges, or a device with a periodic 624 (primary) battery replacement interval. Finally, there may be a 625 limited amount of energy available for a specific event, e.g., for a 626 button press in an energy-harvesting light switch; such devices are 627 classified as E0. Note that, in a sense, many E1 devices are also 628 E2, as the rechargeable battery has a limited number of useful 629 recharging cycles. 631 Table 6 provides a summary of the classifications described above. 633 +------+------------------------+------------------------------+ 634 | Name | Type of energy | Example Power Source | 635 | | limitation | | 636 +======+========================+==============================+ 637 | E0 | Event energy-limited | Event-based harvesting | 638 +------+------------------------+------------------------------+ 639 | E1 | Period energy-limited | Battery that is periodically | 640 | | | recharged or replaced | 641 +------+------------------------+------------------------------+ 642 | E2 | Lifetime energy- | Non-replaceable primary | 643 | | limited | battery | 644 +------+------------------------+------------------------------+ 645 | E9 | No direct quantitative | Mains-powered | 646 | | limitations to | | 647 | | available energy | | 648 +------+------------------------+------------------------------+ 650 Table 6: Classes of Energy Limitation 652 4.3. Strategies for Using Power for Communication 654 Especially when wireless transmission is used, the radio often 655 consumes a big portion of the total energy consumed by the device. 656 Design parameters, such as the available spectrum, the desired range, 657 and the bitrate aimed for, influence the power consumed during 658 transmission and reception; the duration of transmission and 659 reception (including potential reception) influence the total energy 660 consumption. 662 Different strategies for power usage and network attachment may be 663 used, based on the type of the energy source (e.g., battery or mains- 664 powered) and the frequency with which a device needs to communicate. 666 The general strategies for power usage can be described as follows: 668 Always-on: This strategy is most applicable if there is no reason 669 for extreme measures for power saving. The device can stay on in 670 the usual manner all the time. It may be useful to employ power- 671 friendly hardware or limit the number of wireless transmissions, 672 CPU speeds, and other aspects for general power-saving and cooling 673 needs, but the device can be connected to the network all the 674 time. 676 Normally-off: Under this strategy, the device sleeps such long 677 periods at a time that once it wakes up, it makes sense for it to 678 not pretend that it has been connected to the network during 679 sleep: the device reattaches to the network as it is woken up. 680 The main optimization goal is to minimize the effort during the 681 reattachment process and any resulting application communications. 682 If the device sleeps for long periods of time and needs to 683 communicate infrequently, the relative increase in energy 684 expenditure during reattachment may be acceptable. 686 Low-power: This strategy is most applicable to devices that need to 687 operate on a very small amount of power but still need to be able 688 to communicate on a relatively frequent basis. This implies that 689 extremely low-power solutions need to be used for the hardware, 690 chosen link-layer mechanisms, and so on. Typically, given the 691 small amount of time between transmissions, despite their sleep 692 state, these devices retain some form of attachment to the 693 network. Techniques used for minimizing power usage for the 694 network communications include minimizing any work from re- 695 establishing communications after waking up and tuning the 696 frequency of communications (including "duty cycling", where 697 components are switched on and off in a regular cycle) and other 698 parameters appropriately. 700 Table 7 provides a summary of the strategies described above. 702 +------+--------------+---------------------------+ 703 | Name | Strategy | Ability to communicate | 704 +======+==============+===========================+ 705 | P0 | Normally-off | Reattach when required | 706 +------+--------------+---------------------------+ 707 | P1 | Low-power | Appears connected, | 708 | | | perhaps with high latency | 709 +------+--------------+---------------------------+ 710 | P9 | Always-on | Always connected | 711 +------+--------------+---------------------------+ 713 Table 7: Strategies of Using Power for 714 Communication 716 Note that the discussion above is at the device level; similar 717 considerations can apply at the communications-interface level. This 718 document does not define terminology for the latter. 720 A term often used to describe power-saving approaches is "duty- 721 cycling". This describes all forms of periodically switching off 722 some function, leaving it on only for a certain percentage of time 723 (the "duty cycle"). 725 [RFC7102] only distinguishes two levels, defining a Non-Sleepy Node 726 as a node that always remains in a fully powered-on state (always 727 awake) where it has the capability to perform communication (P9) and 728 a Sleepy Node as a node that may sometimes go into a sleep mode (a 729 low-power state to conserve power) and temporarily suspend protocol 730 communication (P0); there is no explicit mention of P1. 732 4.4. Strategies of Keeping Time over Power Events 734 [This subsection is very drafty.] 736 Many applications for a device require it to keep some concept of 737 time. 739 Time-keeping can be relative to a previous event (last packet 740 received), absolute on a device-specific scale (e.g., last reboot), 741 or absolute on a world-wide scale ("wall-clock time"). 743 Some devices lose the concept of time when going to sleep: after 744 wakeup, they don't know how long they slept. Some others do keep 745 some concept of time during sleep, but not precise enough to use as a 746 basis for keeping absolute time. Some devices have a continuously 747 running source of a reasonably accurate time (often a 32,768 Hz watch 748 crystal). Finally, some devices can keep their concept of time even 749 during a battery change, e.g., by using a backup battery or a 750 supercapacitor to power the real-time clock (RTC). 752 The actual accuracy of time may vary, with errors ranging from tens 753 of percent from on-chip RC oscillators (not useful for keeping 754 absolute time, but still useful for, e.g., timing out some state) to 755 approximately 1e-4 to 1e-5 ("watch crystal") of error. More precise 756 timing is available with temperature compensated crystal oscillators 757 (TCXO). Further improvement requires significantly higher power 758 usage, bulk, fragility, and device cost, e.g. oven-controlled crystal 759 oscillators (OCXO) can reach 1e-8 accuracy, and Rubidium frequency 760 sources can reach 1e-11 over the short term and 1e-9 over the long 761 term. 763 A device may need to fire up a more accurate frequency source during 764 wireless communication, this may also allow it to keep more precise 765 time during the period. 767 The various time sources available on the device can be assisted by 768 external time input, e.g. via the network using the NTP protocol 769 [RFC5905]. Information from measuring the deviation between external 770 input and local time source can be used to increase the accuracy of 771 maintaining time even during periods of no network use. 773 Errors of the frequency source can be compensated if known 774 (calibrated against a known better source, or even predicted, e.g., 775 in a software TCXO). Even with errors partially compensated, an 776 uncertainty remains, which is the more fundamental characteristic to 777 discuss. 779 Battery solutions may allow the device to keep a wall-clock time 780 during its entire life, or the wall-clock time may need to be reset 781 after a battery change. Even devices that have a battery lasting for 782 their lifetime may not be set to wall-clock time at manufacture time, 783 possibly because the battery is only activated at installation time 784 where time sources may be questionable or because setting the clock 785 during manufacture is deemed too much effort. 787 Devices that keep a good approximation of wall-clock time during 788 their life may be in a better position to securely validate external 789 time inputs than devices that need to be reset episodically, which 790 can possibly be tricked by their environment into accepting a long- 791 past time, for instance with the intent of exploiting expired 792 security assertions such as certificates. 794 From a practical point of view, devices can be divided at least on 795 the two dimensions proposed in Table 8 and Table 9. Corrections to 796 the local time of a device performed over the network can be used to 797 improve the uncertainty exhibited by these basic device classes. 799 +------+---------------------------+-----------------------------+ 800 | Name | Type | Uncertainty (roughly) | 801 +======+===========================+=============================+ 802 | T0 | no concept of time | infinite | 803 +------+---------------------------+-----------------------------+ 804 | T1 | relative time while awake | (usually high) | 805 +------+---------------------------+-----------------------------+ 806 | T2 | relative time | (usually high during sleep) | 807 +------+---------------------------+-----------------------------+ 808 | T3 | relative time | 1e-4 or better | 809 +------+---------------------------+-----------------------------+ 810 | T5 | absolute time (e.g., | 1e-4 or better | 811 | | since boot) | | 812 +------+---------------------------+-----------------------------+ 813 | T7 | wall-clock time | 1e-4 or better | 814 +------+---------------------------+-----------------------------+ 815 | T8 | wall-clock time | 1e-5 or better | 816 +------+---------------------------+-----------------------------+ 817 | T9 | wall-clock time | 1e-6 or better (TCXO) | 818 +------+---------------------------+-----------------------------+ 819 | T10 | wall-clock time | 1e-7 or better (OCXO or Rb) | 820 +------+---------------------------+-----------------------------+ 822 Table 8: Strategies of Keeping Time over Power Events 824 +------+------------------------------------+-----------------+ 825 | Name | Permanency (from type T5 upwards): | Uncertainty | 826 +======+====================================+=================+ 827 | TP0 | time needs to be reset on certain | | 828 | | occasions | | 829 +------+------------------------------------+-----------------+ 830 | TP1 | time needs to be set during | (possibly | 831 | | installation | reduced... | 832 +------+------------------------------------+-----------------+ 833 | TP9 | reliable time is maintained during | ...by using | 834 | | lifetime | external input) | 835 +------+------------------------------------+-----------------+ 837 Table 9: Permanency of Keeping Time 839 5. Classes of Networks 840 5.1. Classes of link layer MTU size 842 Link layer technologies used by constrained devices can be 843 categorized on the basis of link layer MTU size. Depending on this 844 parameter, the fragmentation techniques needed (if any) to support 845 the IPv6 MTU requirement may vary. 847 We define the following classes of link layer MTU size: 849 +------+---------------------+------------------------------------+ 850 | Name | L2 MTU size (bytes) | 6LoWPAN Fragmentation applicable*? | 851 +======+=====================+====================================+ 852 | S0 | 3 - 12 | need new kind of fragmentation | 853 +------+---------------------+------------------------------------+ 854 | S1 | 13 - 127 | yes | 855 +------+---------------------+------------------------------------+ 856 | S2 | 128 - 1279 | yes | 857 +------+---------------------+------------------------------------+ 858 | S3 | >= 1280 | no fragmentation needed | 859 +------+---------------------+------------------------------------+ 861 Table 10 863 * if no link layer fragmentation is available (note: 'Sx' stands for 864 'Size x') 866 S0 technologies require fragmentation to support the IPv6 MTU 867 requirement. If no link layer fragmentation is available, 868 fragmentation is needed at the adaptation layer below IPv6. However, 869 6LoWPAN fragmentation [RFC4944] cannot be used for these 870 technologies, given the extremely reduced link layer MTU. In this 871 case, lightweight fragmentation formats must be used (e.g. 872 [I-D.ietf-lpwan-ipv6-static-context-hc]). 874 S1 and S2 technologies require fragmentation at the subnetwork level 875 to support the IPv6 MTU requirement. If link layer fragmentation is 876 unavailable or insufficient, fragmentation is needed at the 877 adaptation layer below IPv6. 6LoWPAN fragmentation [RFC4944] can be 878 used to carry 1280-byte IPv6 packets over these technologies. 880 S3 technologies do not require fragmentation to support the IPv6 MTU 881 requirement. 883 5.2. Class of Internet Integration 885 The term "Internet of Things" is sometimes confusingly used for 886 connected devices that are not actually employing Internet 887 technology. Some devices do use Internet technology, but only use it 888 to exchange packets with a fixed communication partner ("device-to- 889 cloud" scenarios, [RFC7452]). More general devices are prepared to 890 communicate with other nodes in the Internet as well. 892 We define the following classes of Internet technology level: 894 +------+--------------------------------------+ 895 | Name | Internet technology | 896 +======+======================================+ 897 | I0 | none (local interconnect only) | 898 +------+--------------------------------------+ 899 | I1 | device-to-cloud only | 900 +------+--------------------------------------+ 901 | I9 | full Internet connectivity supported | 902 +------+--------------------------------------+ 904 Table 11 906 5.3. Classes of physical layer bit rate 908 [This section is a trial balloon. We could also talk about burst 909 rate, sustained rate; bits/s, messages/s, ...] 911 Physical layer technologies used by constrained devices can be 912 categorized on the basis of physical layer (PHY) bit rate. The PHY 913 bit rate class of a technology has important implications with regard 914 to compatibility with existing protocols and mechanisms on the 915 Internet, responsiveness to frame transmissions and need for header 916 compression techniques. 918 We define the following classes of PHY bit rate: 920 +------+--------------+--------------------------------------------+ 921 | Name | PHY bit rate | Comment | 922 | | (bit/s) | | 923 +======+==============+============================================+ 924 | B0 | < 10 | Transmission time of 150-byte frame > MSL | 925 +------+--------------+--------------------------------------------+ 926 | B1 | 10 - 10^3 | Unresponsiveness if human expects reaction | 927 | | | to sent frame (frame size > 62.5 byte) | 928 +------+--------------+--------------------------------------------+ 929 | B2 | 10^3 - 10^6 | Responsiveness if human expects reaction | 930 | | | to sent frame, but header compression | 931 | | | still needed | 932 +------+--------------+--------------------------------------------+ 933 | B3 | > 10^6 | Header compression yields relatively low | 934 | | | performance benefits | 935 +------+--------------+--------------------------------------------+ 937 Table 12 939 (note: 'Bx' stands for 'Bit rate x') 941 B0 technologies lead to very high transmission times, which may be 942 close to or even greater than the Maximum Segment Lifetime (MSL) 943 assumed on the Internet [RFC0793]. Many Internet protocols and 944 mechanisms will fail when transmit times are greater than the MSL. 945 B0 technologies lead to a frame transmission time greater than the 946 MSL for a frame size greater than 150 bytes. 948 B1 technologies offer transmission times which are lower than the MSL 949 (for a frame size greater than 150 bytes). However, transmission 950 times for B1 technologies are still significant if a human expects a 951 reaction to the transmission of a frame. With B1 technologies, the 952 transmission time of a frame greater than 62.5 bytes exceeds 0.5 953 seconds, i.e. a threshold time beyond which any response or reaction 954 to a frame transmission will appear not to be immediate [RFC5826]. 956 B2 technologies do not incur responsiveness problems, but still 957 benefit from using header compression techniques (e.g. [RFC6282]) to 958 achieve performance improvements. 960 Over B3 technologies, the relative performance benefits of header 961 compression are low. For example, in a duty-cycled technology 962 offering B3 PHY bit rates, energy consumption decrease due to header 963 compression may be comparable with the energy consumed while in a 964 sleep interval. On the other hand, for B3 PHY bit rates, a human 965 user will not be able to perceive whether header compression has been 966 used or not in a frame transmission. 968 6. IANA Considerations 970 This document makes no requests to IANA. 972 7. Security Considerations 974 This document introduces common terminology that does not raise any 975 new security issues. Security considerations arising from the 976 constraints discussed in this document need to be discussed in the 977 context of specific protocols. For instance, Section 11.6 of 978 [RFC7252], "Constrained node considerations", discusses implications 979 of specific constraints on the security mechanisms employed. 980 [RFC7416] provides a security threat analysis for the RPL routing 981 protocol. Implementation considerations for security protocols on 982 constrained nodes are discussed in [RFC7815] and 983 [I-D.ietf-lwig-tls-minimal]. A wider view of security in 984 constrained-node networks is provided in [RFC8576]. 986 8. Informative References 988 [FALL] Fall, K., "A Delay-Tolerant Network Architecture for 989 Challenged Internets", DOI 10.1145/863955.863960, 990 SIGCOMM 2003, 2003, 991 . 993 [I-D.hui-vasseur-roll-rpl-deployment] 994 Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL 995 deployment experience in large scale networks", Work in 996 Progress, Internet-Draft, draft-hui-vasseur-roll-rpl- 997 deployment-01, 5 July 2012, . 1000 [I-D.ietf-lpwan-ipv6-static-context-hc] 1001 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 1002 Zuniga, "Static Context Header Compression (SCHC) and 1003 fragmentation for LPWAN, application to UDP/IPv6", Work in 1004 Progress, Internet-Draft, draft-ietf-lpwan-ipv6-static- 1005 context-hc-24, 5 December 2019, . 1009 [I-D.ietf-lwig-tls-minimal] 1010 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 1011 Guide to the (Datagram) Transport Layer Security Protocol 1012 for Smart Objects and Constrained Node Networks", Work in 1013 Progress, Internet-Draft, draft-ietf-lwig-tls-minimal-01, 1014 7 March 2014, . 1017 [IoT-2025] Rosen, M. and IDC, "Driving the Digital Agenda Requires 1018 Strategic Architecture", 16 November 2016, . Slide 11 1022 [ISQ-13] International Electrotechnical Commission, "International 1023 Standard -- Quantities and units -- Part 13: Information 1024 science and technology", IEC 80000-13, March 2008. 1026 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1027 RFC 793, DOI 10.17487/RFC0793, September 1981, 1028 . 1030 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1031 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1032 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1033 April 2007, . 1035 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1036 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1037 Overview, Assumptions, Problem Statement, and Goals", 1038 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1039 . 1041 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1042 "Transmission of IPv6 Packets over IEEE 802.15.4 1043 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1044 . 1046 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1047 Routing Requirements in Low-Power and Lossy Networks", 1048 RFC 5826, DOI 10.17487/RFC5826, April 2010, 1049 . 1051 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1052 "Network Time Protocol Version 4: Protocol and Algorithms 1053 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1054 . 1056 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1057 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1058 DOI 10.17487/RFC6282, September 2011, 1059 . 1061 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1062 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1063 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1064 Low-Power and Lossy Networks", RFC 6550, 1065 DOI 10.17487/RFC6550, March 2012, 1066 . 1068 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1069 and D. Barthel, "Routing Metrics Used for Path Calculation 1070 in Low-Power and Lossy Networks", RFC 6551, 1071 DOI 10.17487/RFC6551, March 2012, 1072 . 1074 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1075 Statement and Requirements for IPv6 over Low-Power 1076 Wireless Personal Area Network (6LoWPAN) Routing", 1077 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1078 . 1080 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1081 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1082 2014, . 1084 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1085 Constrained-Node Networks", RFC 7228, 1086 DOI 10.17487/RFC7228, May 2014, 1087 . 1089 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1090 Application Protocol (CoAP)", RFC 7252, 1091 DOI 10.17487/RFC7252, June 2014, 1092 . 1094 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1095 and M. Richardson, Ed., "A Security Threat Analysis for 1096 the Routing Protocol for Low-Power and Lossy Networks 1097 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1098 . 1100 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1101 over ITU-T G.9959 Networks", RFC 7428, 1102 DOI 10.17487/RFC7428, February 2015, 1103 . 1105 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1106 "Architectural Considerations in Smart Object Networking", 1107 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1108 . 1110 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1111 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1112 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1113 . 1115 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 1116 (IKEv2) Initiator Implementation", RFC 7815, 1117 DOI 10.17487/RFC7815, March 2016, 1118 . 1120 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1121 M., and D. Barthel, "Transmission of IPv6 Packets over 1122 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1123 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1124 2017, . 1126 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1127 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1128 . 1130 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1131 Things (IoT) Security: State of the Art and Challenges", 1132 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1133 . 1135 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 1136 Internet", DOI 10.1002/9780470686218, ISBN 9780470747995, 1137 Wiley-Blackwell monograph, 2009, 1138 . 1140 Acknowledgements 1142 TBD 1144 Authors' Addresses 1146 Carsten Bormann 1147 Universitaet Bremen TZI 1148 Postfach 330440 1149 D-28359 Bremen 1150 Germany 1152 Phone: +49-421-218-63921 1153 Email: cabo@tzi.org 1155 Mehmet Ersue 1157 Email: mersue@gmail.com 1158 Ari Keranen 1159 Ericsson 1160 Hirsalantie 11 1161 FI-02420 Jorvas 1162 Finland 1164 Email: ari.keranen@ericsson.com 1166 Carles Gomez 1167 UPC/i2CAT 1168 Escola d'Enginyeria de Telecomunicacio i Aeroespacial 1169 de Castelldefels 1170 C/Esteve Terradas, 7 1171 08860 Castelldefels 1172 Spain 1174 Phone: +34-93-413-7206 1175 Email: carlesgo@entel.upc.edu