idnits 2.17.1 draft-arkko-core-sleepy-sensors-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2011) is 4679 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-05 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-02 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-00 == Outdated reference: A later version (-10) exists of draft-jennings-senml-05 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft H. Rissanen 4 Intended status: Informational S. Loreto 5 Expires: January 6, 2012 Z. Turanyi 6 O. Novo 7 Ericsson 8 July 5, 2011 10 Implementing Tiny COAP Sensors 11 draft-arkko-core-sleepy-sensors-01 13 Abstract 15 The authors are developing COAP and IPv6-based sensor networks for 16 environments where lightweight implementations, long battery 17 lifetimes, and minimal management burden are important. The memo 18 shows how different communication models supported by COAP affect 19 implementation complexity and energy consumption, far more so than 20 mere changes in message syntax. Our prototype implements a 21 multicast-based IPv6, UDP, COAP, and XML protocol stack in less than 22 50 assembler instructions. While this extremely minimal 23 implementation is suitable only for limited applications and makes a 24 number of assumptions, the general conclusions point to need for 25 further work in developing the COAP multicast and observation 26 frameworks. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 6, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Implementing Tiny COAP-Based Sensors . . . . . . . . . . . . . 5 65 3.1. Sleeping Nodes and Energy Use . . . . . . . . . . . . . . 6 66 3.2. Address Autoconfiguration . . . . . . . . . . . . . . . . 6 67 3.3. Using Multicast . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Using COAP . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.5. Power Usage Calculation . . . . . . . . . . . . . . . . . 9 70 3.6. Software Construction . . . . . . . . . . . . . . . . . . 10 71 3.7. UDP Checksums . . . . . . . . . . . . . . . . . . . . . . 11 72 3.8. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4. Choosing a Communication Model . . . . . . . . . . . . . . . . 12 74 4.1. End-to-End Communication and Intermediaries . . . . . . . 13 75 4.2. COAP Messaging . . . . . . . . . . . . . . . . . . . . . . 15 76 4.2.1. Client Model . . . . . . . . . . . . . . . . . . . . . 15 77 4.2.2. Server Model . . . . . . . . . . . . . . . . . . . . . 17 78 4.2.3. Observer Model . . . . . . . . . . . . . . . . . . . . 18 79 4.3. Resources and Data Formats . . . . . . . . . . . . . . . . 21 80 4.4. Configuration . . . . . . . . . . . . . . . . . . . . . . 22 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 82 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 86 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 89 1. Introduction 91 The authors are developing COAP [I-D.ietf-core-coap] and IPv6-based 92 [RFC2460] sensor networks for home, building, and other consumer 93 environments. These environments demand solutions where the sensors 94 are physically small, inexpensive, have long battery lifetimes, and 95 require minimal amount of management effort. Our prototype sensor 96 implementation requires no configuration and implements a multicast- 97 based IPv6, UDP, COAP, and XML protocol stack and an application in 98 very small amount of code. 100 Small devices are naturally preferred in most applications, but for 101 some applications small enough size is a critical concern, for 102 instance, to make devices embedded in our clothing practical, to fit 103 within the space available in buildings or everyday objects, or to 104 ensure that the devices do not cause a visual distraction. Another 105 key concern is device and battery lifetime. Sufficient battery 106 lifetime in an application with a large number of devices can be 107 surprisingly long. A home with hundred devices with ten year battery 108 lifetimes will result in a battery change operation every month. 110 The practical challenge is to increase battery lifetimes of small 111 devices by several orders of magnitude, and to enable pinhead size 112 devices connected to the Internet. These are not unattainable goals, 113 as legacy sensor networking technology can in some cases reach these 114 goals. For instance, networked 1-Wire temperature sensors are the 115 size of a packaged transistor. Our aim is to replicate this model or 116 even improve it for IP-based sensors. 118 Another challenge is to ensure that COAP-based networks are 119 interoperable in a multi-vendor environment. For instance, it is 120 important that proxies and servers can perform all the necessary 121 tasks without being programmed to support a sensor node manufactured 122 by a particular vendor, or perhaps even without being programmed to 123 support a particular class of a sensor. 125 This memo describes implementation experiences, open questions that 126 we have encountered, and areas where COAP makes it difficult to make 127 very low power implementations. The memo discusses implementation 128 techniques that are useful in these environments and what is needed 129 for fully interoperable solutions based on COAP. 131 The goals for our work are described in Section 2. Before we can 132 dwell into the high-level networking design choices, we highlight 133 some of the implications of detailed implementation strategies 134 through an example. Section 3 discusses our specific implementation 135 strategies, and describes our experiences with these choices. This 136 example is an extreme case, an attempt to minimize as much as 137 possible for a limited set of applications. However, some general 138 conclusions can still be seen. The more general discussion of the 139 different high-level approaches to communications models can be found 140 in Section 4. Different communication models supported by COAP 141 affect implementation complexity and energy consumption, far more so 142 than mere changes in message syntax. The required configuration 143 effort is also directly affected by the choice of the communications 144 model. Finally, the concluding recommendations point to need for 145 further work in developing COAP and its multicast and observation 146 frameworks [I-D.ietf-core-coap] [I-D.ietf-core-observe], as discussed 147 in Section 6. 149 2. Goals 151 The main focus of this draft is sensors that are deployed in large 152 quantities and have specific physical requirements. There are 153 similar issues with other nodes such as servers and proxies, but in 154 general these nodes have better access to power and other resources, 155 and typically can also be more easily configured by humans. 157 As discussed in the introduction, for sensors the overall 158 requirements revolve around minimizing physical size, cost, 159 management effort and maximizing battery lifetimes. More 160 specifically, we believe the following goals are key in achieving 161 fulfilling these requirements: 163 o Natural support for sleeping nodes. There are many aspects to 164 power usage in small devices, but we believe this one is the most 165 significant one in terms of minimizing power usage. Many of the 166 other aspects are either dictated by the environment (such as 167 choice of radio technology in a given network) or have a 168 relatively small impact (small variations in message size, for 169 instance). 171 o Communication models that fit the problem at hand. It is 172 essential that the small nodes can engage in communication 173 exchanges that suit their needs. Having to employ multiple 174 roundtrips, wait for nodes they have no control over, and so on 175 can have a large negative effect on the amount of power that the 176 node has to spend. 178 o Good design from user perspective. It is obviously undesirable to 179 require a lot of per-device configuration effort when deploying a 180 large set of small devices. In addition, direct configuration 181 efforts with the device itself may be problematic, given that 182 there is no room for any type of a user interface. For instance, 183 some of the legacy sensor devices in existing networks are just a 184 few millimeters across. It is natural that some information needs 185 to be configured, but configuration should be minimized and 186 whatever configuration is necessary should take place in nodes 187 that have the necessary user interfaces and capabilities. 189 3. Implementing Tiny COAP-Based Sensors 191 We have implemented prototypes of small sensors and a sensor gateway 192 to pass the information onwards. The main target of these 193 implementations is temperature, humidity, and other measurements in 194 home environments. Our focus is primarily in sensing. Actuators and 195 other more complex functions are outside the scope of our analysis. 197 Our prototype sensor implementation requires no configuration and 198 simply runs based on its own identity burned in the hardware. The 199 complete functionality requires only a small amount of code. Our 200 prototype platform uses a 32-bit processor architecture and the 201 hardware provides an underlying capability to send a link layer 202 frame. In this platform, our implementation is under 50 assembler 203 instructions (see Note 1). The implementation consists of a 204 Ethernet, IPv6, UDP, COAP, and XML protocol stack and the sensor 205 application. The sensor application is based on values provided by 206 an A/D converter; any analog value can be measured. 208 Note 1: This contains everything necessary for using an A/D 209 converter, constructing a complete Ethernet frame along with the 210 higher level protocol fields, and asking the link layer to send 211 it. It excludes platform specific initializations of the link 212 layer, actual emitting of bits on the wire, and putting the device 213 to sleep and waking it up. The complexity of these tasks varies 214 highly between platforms and link layer technologies. For 215 instance, one some platforms and with Ethernet, sending a frame 216 out is merely a question of setting some registers and asking the 217 hardware to send a packet. Of course, with different link layers 218 and platforms an implementation might be have to be arbitrarily 219 complex to support the intricacies of the link layer in question. 221 Even this size of the implementation is not the absolute minimum. 222 One quarter of the code in our implementation relates to specific 223 initializations required for the A/D converter that we used. Another 224 quarter relates to binary to decimal conversions on the chosen XML- 225 based payload. On a different platform and with binary data, 25 226 instructions would be achievable. 228 The following subsections outline the design choices that were taken 229 to create the small implementation we have. 231 3.1. Sleeping Nodes and Energy Use 233 As discussed earlier, choosing the right communication model is what 234 drives a good design from a power conservation perspective. 236 In our implementation, we chose to use a send-only model where the 237 device only sends messages, but never receives one. This model can 238 be applied in specialized applications under some assumptions that 239 will be discussed further later in this memo. In our case, the 240 sensor will periodically take a reading and send a COAP message to 241 the network with that reading. In order to eliminate potential 242 waiting periods where the device has to stay on, we needed to 243 eliminate the following: 245 o DHCP request - response process [RFC2131]. 247 o Router Discovery process [RFC4861]. 249 o Duplicate Address Detection process [RFC4862]. 251 o Acting as a COAP server [I-D.ietf-core-coap]. 253 o Waiting for COAP observation subscriptions 254 [I-D.ietf-core-observe]. 256 3.2. Address Autoconfiguration 258 Eliminating DHCP is easy, as we can simply use IPv6 and stateless 259 address autoconfiguration. Eliminating router discovery is harder, 260 however. To avoid having to wait for a Router Advertisement to carry 261 a prefix, we chose to employ a link-local source adress. These 262 addresses can be constructed from the well-known prefix FE80::0 and a 263 link layer hardware address burned to the hardware [RFC4862]. 265 Eliminating Duplicate Address Detection is a matter of choice. We 266 chose to behave as if DupAddrDetectTransmits had been set to zero, in 267 other words not performing any Duplicate Address Detection. It may 268 be debatable whether this is a violation of [RFC4862], but it is 269 certainly against its spirit. This choice seems to be the right 270 technical action, however, on a number of grounds: 272 o As the node is not receiving any packets, nor sending Neighbor 273 Advertisement messages, any effects of possible duplication would 274 be limited to some additional traffic in the network. No other 275 traffic would be impacted. Application-level collection of sensor 276 information can proceed even in this situation. 278 o [RFC4862] requires that upon detecting a duplicated address, 279 "autoconfiguration stops and manual configuration of the interface 280 is required". However, it is obvious that no such action is 281 possible on a small device. The device has no user interface. 282 The only interface that the device has is the network, and if the 283 network cannot be brought up, there's very little that can be 284 done. As a result, the ability to not stop in a duplication case 285 may actually be better than what is recommended by [RFC4862]. 287 o These devices are manufactured with hardware identities that are 288 expected to be unique. There are obviously no guarantees about 289 this succeeding in all cases, but non-unique identifiers would 290 represent a major failure of the manufacturing process. 292 Elimination of Duplicate Address Detection also eliminates the need 293 for the node to implement Multicast Listener Detection (MLD) protocol 294 [RFC2710] [RFC3810]. This is because it now no longer needs to 295 listen for messages to the solicited node multicast address, so there 296 is no need to send out MLD messages. 298 3.3. Using Multicast 300 To further eliminate configuration or protocol exchanges for 301 discovery, we chose to employ a multicast model where the sensor 302 sends COAP POST requests to a well-known multicast address. While 303 the type of sensors targeted here send information very infrequently, 304 one of our goals was to ensure that the architecture would scale to 305 more frequent information distribution and far larger groups of 306 sensors. As a result, it was important to ensure that the multicast 307 messages do not lead to multicast storms or unnecessary waking up 308 many nodes due to frequent messages. 310 We chose to employ an interest-based generated multicast group 311 address. These addresses are similar to those used in IPv6 Neighbor 312 Discovery [RFC4861] for sending messages to solicited node addresses 313 (FF02:0:0:0:0:1:FFXX:XXXX) [RFC4291]. The idea is that some bits 314 from the object of interest are reflected in the multicast address, 315 making it statistically likely that someone interested in a specific 316 object only has to receive packets relating to that object, and not 317 all packets. 319 We employ FF02:0:0:0:1:FEXX:XXXX, where XX:XXXX is a 6-byte value 320 representing the type of sensor. (This address is currently reserved 321 by IANA, but could be allocated for this purpose if needed.) The 322 sensor type represents a classification of different sensor to types. 323 For instance, we could let 00:0001 stand for temperature sensors. 324 Each temperature sensor would send information to the multicast 325 address FF02:0:0:0:1:FE00:0001, and only those devices that are 326 interested in temperature measurements would subscribe to this 327 multicast group. Techniques such as MLD/IGMP snooping can be used in 328 the network to ensure that multicast messages are physically 329 transmitted only in those parts of the network that actually care 330 about those messages [RFC4541]. In practice, this would mean that in 331 a star topology network with a large number of sensors and a few 332 central nodes, none of the sensors would receive any messages from 333 each other. 335 Finally, randomization of actual transmission times for the periodic 336 transmissions ensures that transmissions from different sensors are 337 not synchronized. 339 When sensors send multicast messages with link-local source and 340 destination addresses, all communication is confined to a single 341 network. We expect that there is a node in the network that listens 342 to the multicast messages, collects the data from them, and is 343 capable of relaying the information to other parties. Such a node 344 might store the latest information related to each sensor, and allow 345 other nodes in the Internet to query the latest information on a per- 346 sensor or an aggregate basis. 348 3.4. Using COAP 350 Our implementation uses non-confirmable requests at the messaging 351 layer of COAP, and sends a POST message that carries an XML payload 352 for a well-known URI. The implementation sends a message and does 353 not wait for a message at this layer. We have used a gateway to 354 store the information received from the sensors, making the gateway 355 act as a server, storing everything posted to it. The stored 356 information can be fetched from the gateway, for instance, with a 357 COAP or HTTP GET. 359 Per Section 2.8.2 of [I-D.ietf-core-coap], POST methods normally 360 generate a response at the request/response layer. If the server 361 sends a response, the sensor is already asleep and will not respond 362 to Neighbor Discovery messages or receive the actual message. The 363 message is therefore lost, but it is fine in our case given that the 364 information was already stored in the server. 366 Reliable transmission is achieved through assuming a sufficiently 367 high periodic transmission rate to account for randomly occurring 368 message loss. 370 There are several areas of concern with the above arrangements, 371 discussed further in Section 3.8 and Section 4.2. 373 3.5. Power Usage Calculation 375 Our communication model is now complete. Its effectiveness can be 376 calculated by determining what fraction of time the device would have 377 to be awake. Lets assume periodic messages once per minute, a 10 378 Mbit/s link layer interface, and a CPU running at 1 Mhz. With the 379 given link layer, sending one message takes theoretically 100 380 microseconds. Constructing the message takes 50 instructions and if 381 we for simplicity assume that each instruction takes two clock 382 cycles, the CPU needs to run for an additional 100 microseconds. 383 Since our device is only sending messages, it only has to wake up to 384 send the message. Ratio of sleeping versus being awake is now 200 385 microseconds versus 60 seconds, i.e., 300.000. Even if we assume 386 that it takes an additional 800 microseconds to power the device up 387 and let the A/D converter stabilize, the ratio is still 1000 388 microseconds vs. 60 seconds, i.e., 60.000. 390 We can compare this to some other possible implementations. A node 391 that stays awake and participates in Neighbor Discovery, Duplicate 392 Address Detection, and ARP processes would consume 60.000 times more 393 energy. One could assume that listening is less power consuming than 394 sending, however. On some link layers today this ratio can be as 395 high as listening consuming 2.500 time less power, though practical 396 implementations (talk vs. standby times) seem to be more in the range 397 of a 100-fold difference. If we assume an optimistic 1.000 time 398 difference, our implementation would still consume 60 times less 399 energy than one that stays on all the time. 401 Another possible implementation is that a node stays awake for a 402 short period of time to listen for possible messages. Some COAP 403 implementations do this to enable discovery and observe subscriptions 404 to work. If we assume one second awake time during one minute, then 405 the power consumption difference to our implementation is somewhere 406 between 1.000 and 2 times, depending on whether send/receive power 407 requirements differences are factored in. 409 While these comparisons have produced wildly different numbers, it is 410 clear that our implementation strategy is far superior to the 411 simplistic always-on model. The situation is less clear with the 412 comparison to the periodically listening approach, but even there it 413 is clear that not listening consumes less energy than listening. 414 While the actual numbers depend highly on the characteristics of the 415 link layer, even with the most optimistic assumptions for the 416 alternative approach it uses twice as much energy. This may not 417 sound like a significant difference, but if it means a ten year 418 battery lifetime instead of five year battery lifetime, it can make 419 or break a business case for building some types of sensors. 421 3.6. Software Construction 423 When memory and processing power is at a premium, the detailed 424 software design approach needs to suit the platform that the software 425 runs on. That being said, for simple send-only applications we have 426 found that a packet template-based approach works well. In this 427 approach an image of the message sent by the application is burned 428 into the read-only memory of the device, as a part of the overall 429 software image. When the device powers up, the message image is 430 copied to random access memory, necessary changes are applied, and 431 the underlying link layer hardware or the CPU emits it on the 432 outgoing interface bit by bit. 434 In case of COAP and simple sensors that output a numerical value 435 transmitted in an XML [W3C.REC-xml-19980210] or JSON [RFC4627] 436 payload, only the following changes are applicable: 438 o 16-bit COAP Message ID field (see Section 3.1 in 439 [I-D.ietf-core-coap]). This field should be set to a random 440 value, a rarely repeating value. We have found that using a 441 suitably shifted value of a real-time clock is the most convenient 442 way to generate a good value for this field. On many small 443 platforms, a real-time clock can be kept counting with a very 444 small amount of power. Note that it does not matter what value 445 the real-time clock is initially initialized to; the only thing 446 that matters for the Message ID field is that it keeps changing. 447 If a sensor sends a value every minute, shifting a seconds-from- 448 epoch counter by five bit positions is a good way to generate a 449 unique value. 451 Note that using a different value may not actually be required, 452 though it is certainly helpful for understanding network traces 453 and debugging. According to Section 4.1 of [I-D.ietf-core-coap], 454 Message IDs only have to be unique within RESPONSE_TIMEOUT * 455 RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT - 1) or 45 seconds, 456 so a sensor sending messages every minute would be allowed to send 457 them with the same Message ID. 459 o The actual sensor reading. In both XML and JSON, values can be 460 padded with leading zeros or spaces, so the overall size of the 461 packet can be kept the same in all circumstances. This greatly 462 simplifies the construction of the packet. 464 Note that binary or hexadecimal formats would make this even 465 simpler, but the savings are in the order of few instructions; the 466 difference is not big. Of course, a message that carries a text 467 is longer than a pure binary message. However, the format is not 468 so important as is avoiding including a lot of extraneous 469 information. Some XML schemas can be problematic. We advocate 470 simplicity and restraint in XML schema design for sensor data. 472 o 16-bit UDP checksum field. For computing this field, see 473 Section 3.7. 475 Note this small set of changes is only applicable when it can be 476 assumed that both source and destination IP addresses are known 477 beforehand. 479 3.7. UDP Checksums 481 Both IPv4 and IPv6 have some form of mandatory checksums, either in 482 the IP header (IPv4) or as part of upper layer protocols such as UDP 483 (IPv6). Computing the checksum is not difficult, but requires 484 looping through all the 16-bit words in a packet. Fortunately, for a 485 simple application the checksum calculation is actually very simple. 486 Following the algorithm in [RFC1624], there is no need to calculate 487 the checksum for the entire packet. The checksum can be precomputed 488 on the packet template with zero words filled in for the variable 489 parts. Lets call this precomputed checksum value C. Let NC be its 490 negation, i.e., 492 NC = ~C 494 Once the actual values are filled in the packet, the true checksum C' 495 needs to be calculated as follows: 497 T = NC + W1 + W2 + ... + Wn 498 C' = ~(T + (T >> 16)) 500 where T is a temporary variable and Wi, i = 0, 1, ..., n are the 501 words that got changed from the template. Naturally, this approach 502 makes sense only when the number of changed words is small. We have 503 found that suitable placement of spaces and string values in an XML 504 object, for instance, is helpful in aligning the changed parts to 505 word boundaries, and in sensor implementations n = 3. 507 3.8. Evaluation 509 This type of an implementation is obviously an extreme example. This 510 level of optimization may not be needed in all cases. Nevertheless, 511 it is interesting to see that COAP can be used in such small 512 implementations. 514 In general, our implementation satisfies the requirements set for the 515 special environment that it was designed for: power usage is 516 minimized, individual sensor devices do not require configuration, 517 existing legacy networks can migrate to general-purpose IP-based 518 networks, and all the necessary information can be passed in the 519 messages. 521 That being said, there are also some issues with this implementation 522 approach. The first issue is that information delivery frequency is 523 hardwired into the sensors. The chosen frequency may be sufficient 524 for a given application, but the same sensors cannot be used by 525 another application that would require a faster delivery of 526 measurements. 528 Related but more serious concern is that reliability is achieved 529 through randomized message intervals and multiple transmissions; it 530 is considered unlikely that a very large number of messages in 531 sequence are lost from the same sensor. The message transmission 532 frequency needs to be set high enough to accommodate some packet 533 loss. There is no way to actively request retransmission. We 534 believe that this is a small problem in well-designed networks and 535 for most applications that are not real-time critical, such as home, 536 weather, maintenance, and energy monitoring. However, this approach 537 may not be suitable for real-time or safety-critical applications. 539 The third and obvious limitation is that there is an assumption of a 540 network node in the same network that is capable of storing 541 information. We believe that there is little that can be done about 542 this assumption; it is fundamental for the nature of low-power 543 devices that they have to be able to sleep periodically, and there 544 are very few other options beyond implementing a time-shifting device 545 such as a cache. The location of the cache node could be outside the 546 sensor network in some other designs, however. 548 4. Choosing a Communication Model 550 COAP is a specialized web transfer protocol designed to be used in 551 various ways. The communication model of COAP is flexible and the 552 application developer has to decide the best way to use it. This 553 involves 555 o deciding which parties are in server/client roles, 557 o determining whether to use end-to-end communication or employ 558 intermediary nodes, 560 o deciding whether to use base COAP operations or the observation 561 framework, 563 o deciding whether a discovery process is required, 565 o specifying how COAP maps to lower layers, including choice of 566 source and destination addresses, and 568 o agreeing about commonly understood methods, resource identifiers 569 and data representation. 571 Note that the number of these choices alone makes it hard to achieve 572 interoperability, as we should strive for application 573 interoperability at the semantic level [arkko.iab], rather than mere 574 ability to transport correctly formed COAP packets. 576 Nevertheless, the main focus of this memo is to determine the power 577 efficiency implications for the different communications models, and 578 to identify areas where COAP limits this efficiency. The rest of 579 this section is structured as follows. Section 4.1 discusses which 580 nodes are involved. Section 4.2 discusses the specific COAP 581 messaging alternatives. Section 4.3 discusses resources and data 582 formats. Section 4.4 discusses configuration issues. 584 4.1. End-to-End Communication and Intermediaries 586 In most applications, user interactions and information requests can 587 come at any time. Some form of an intermediary that can buffer such 588 requests between a possibly sleeping device and the end user seems 589 therefore useful to provide "time-shifting" capability. Similarly, 590 an intermediary can be useful to reduce the number of transactions 591 that one has to do with the low-power device to a minimum; the 592 intermediary can answer on behalf of the device should a large number 593 of information requests be placed. 595 In its simplest form, the intermediary is a part of the application 596 server. For instance, a web-based application server is capable of 597 serving web clients at any time, but will only place a periodic 598 request to the sensor in order to take a reading. There are 599 virtually no downsides to this arrangement, and it is generally 600 recommended practice. 602 What is perhaps more controversial and interesting is the placement 603 of intermediaries elsewhere, such as requiring an intermediary in the 604 same network as the sensor devices are in. In our example 605 implementation, such an intermediary was used for both time-shifting 606 purposes and to bridge the gap between addressing domains, as the 607 sensor was only capable of sending messages to nearby devices with 608 link-local multicast addressing. For obvious reasons, sending 609 traffic to well-known multicast groups works only on the local scale. 610 Other possible reasons for using a local intermediary include 611 protocol conversion and providing TCP-based congestion control for 612 traffic passing through the Internet. Where mechanisms for dealing 613 with packet loss are limited, such as in the case of our 614 implementation, an intermediary can also shield the sensors from 615 having to deal with networks that have not been engineered for this 616 purpose. 618 There are also downsides to having to place a local intermediary. 619 The obvious downside is that such a device must now exist in the 620 local network. 622 The use of COAP intermediaries is not fully specified, however. Some 623 of the issues we have encountered include: 625 o COAP defines the roles for clients, servers, caches, and proxies, 626 but while the specification allows an intermediary to act as 627 server that stores all information sent to it, it is by no means 628 specified as something that all implementations should do. The 629 desirable behavior from the point of low-power sensors would be 630 that the local server would store the information from every POST 631 sent to it for a period of time specified in the Max-Age option 632 [I-D.ietf-core-coap], and then be able provide access to the 633 information using GET and HTTP/COAP. It would be useful to define 634 such a new server role, along with specifying the necessary 635 security and operational conditions for this practice. 637 o If designed badly, the intermediary may also limit the type of 638 communications it can relay. For instance, a gateway that is only 639 built for a particular types of sensors might only accept very 640 specific COAP messages. In particular, intermediaries need to 641 support any type of resource identifiers and data formats. 642 Further discussion of this can be found in Section 4.3. 644 o In several CoAP applications the user is interested in the latest 645 value of a resource, but historical values are also interesting in 646 several use cases, e.g. tracking the movements of a truck during 647 the day. Thus, the information stored in the cache/gateway should 648 not expire. Even if a new value is received every minute, old 649 values should be accessible and new value should not overwrite the 650 old value. For this kind of cases, schemas for representing also 651 historical values of the sensor would be useful for 652 interoperability. Of course, simple schemas are easy to implement 653 even if there did not exist any standards or recommendations, but 654 again, there will not be interoperability. 656 o If the information is such that it should expire after some time, 657 Max-Age option can be used as defined [I-D.ietf-core-coap]. 658 However, [I-D.ietf-core-coap] discusses Max-Age option only in the 659 context of responses. In the multicast use case (sensor the one 660 sending requests), Max-Age option would be needed to be supported 661 in requests, too. 663 o Multicast requests, particiularly GETs, might be forwarded by 664 several proxies and possibly even to further multicast addresses, 665 causing a storm of messages. The COAP specification does not 666 describe when the forwarding of multicast requests is appropriate 667 and when it is not. 669 4.2. COAP Messaging 671 The interaction model of COAP is similar to the client/server model 672 in HTTP. A sensor can act either as a client that sends requests 673 containing updated measurement information to a server, or as a 674 server that responds to requests from others. If the sensor is a 675 server, it can either employ the basic communication model from 676 [I-D.ietf-core-coap] or use the observation framework 677 [I-D.ietf-core-observe]. This section looks at the energy efficiency 678 implications of these models. 680 It is important to make this analysis not merely based on the data 681 transmission phase, but also based on what discovery actions and 682 related signaling may be necessary. 684 4.2.1. Client Model 686 In this model, a sensor acts as a client that periodically sends POST 687 requests containing updated measurement information to a server. 688 This is the model that we used in our example implementation. 690 User or Sensor 691 Intermediary (Client) 692 (Server) . 693 | . 694 | . 695 | wake-up 696 | | 697 | NON/POST | 698 | content | 699 +<--------------------| 700 | | 701 | power-down 702 | . 703 | NON/RSP . 704 |----------------/ . 705 | . 707 Figure 1. Send-only client model 709 In its simplest form, this model can be reduced to sending a single 710 message per observation period, however this comes at the cost of: 712 o Limited support for reliable transmission. Messages may arrive 713 out of order and they may go missing without notice. While 714 periodic retransmissions do provide a statistical likelihood that 715 the transmission eventually succeeds, they do not guarantee it. 717 o Possible spurious diagnostic or other problems caused by not being 718 able to receive the REST level response to the POST message that 719 the server will send (see Section 3.4). 721 Both of these problems can be addressed by forcing the device to wait 722 for a response, incurring the cost of having to be awake for 1 RTT 723 for each observation period. Using the assumptions from Section 3.5 724 and a 2 ms RTT for a local intermediary to respond, the power usage 725 of this model would be either two times more or 0.2% more, depending, 726 again, on whether the send/receive power differences are factored in. 728 User or Sensor 729 Intermediary (Client) 730 (Server) . 731 | . 732 | . 733 | wake-up 734 | | 735 | CON/POST | 736 | content | 737 +<--------------------| 738 | | 739 | ACK/RSP | 740 |-------------------->| 741 | | 742 | power-down 743 | . 744 | . 746 Figure 2. Send-and-confirm client model 748 (Interestingly, a similar model could be implemented even with HTTP. 749 With TCP, one additional roundtrip and one additional message would 750 be necessary to start the communications. This model would be 751 roughly twice as power hungry as the COAP alternative. Note at least 752 in the implementation strategy that was used in our example 753 implementation, the format differences between COAP and HTTP would 754 make little difference for implementation complexity, as messages are 755 created based on pre-filled packet templates. Supporting TCP would 756 require some complexity, however.) 758 In addition, there is an added factor, having to discover the right 759 peer to send messages to. In our example implementation this was 760 simply a well-known multicast address, in which case no additional 761 power is spent. The downside is that this can easily be done only 762 with local multicast, necessitating the existence of suitable 763 intermediary in the same network. Alternatively, the sensor could 764 run a discovery phase at installation time to find the addresses of 765 the peers wishing to receive the information. This discovery would 766 have to repeated in order to account for changes and new equipment. 767 Nevertheless, if discovery is run once a day and uses the same amount 768 of power as sending one data observation, the increased power 769 requirements are in the order of 0.1%, i.e., negligible. 771 The COAP specification has also a few more detailed issues around the 772 use of the client model: 774 o Section 4.2 of [I-D.ietf-core-coap] indicates that multiple 775 transmissions can be used to increase the reliability of non- 776 confirmable requests. However, no rules are given about how many 777 repetions can be made or how quickly they can follow each other. 778 The specification also does not say if the rules are the same for 779 unicast and multicast. 781 o Section 4.4 of [I-D.ietf-core-coap] does not explain the 782 congestion control rules for multicast requests. There is an 783 informative reference to another draft, but even that draft does 784 not specify the behavior for multicast. 786 4.2.2. Server Model 788 In the basic server model as defined in [I-D.ietf-core-coap], the 789 sensor waits for requests from a client. The power requirements for 790 this model have been analyzed in Section 3.5 and are substantially 791 higher than in any other model, even if one takes into account that 792 listening is less power intensive than sending. 794 User or Sensor 795 Intermediary (Server) 796 (Client) 797 | | 798 | CON/GET | 799 +-------------------->| 800 | | 801 | ACK/RSP | 802 | content | 803 |<--------------------+ 804 | | 806 Figure 3. Server model. 808 There may be an additional discovery exchange where the sensor 809 responds to requests sent for the well-known resources defined in 810 [I-D.ietf-core-link-format]. However, these additional exchanges do 811 not change power requirements significantly, as the sensor already 812 has to be awake at all times. A more relevant concern is perhaps 813 unwanted or accidental traffic to the sensor or one of the multicast 814 addresses it belongs to (such as all-nodes [RFC4291]). Such traffic 815 may have to be replied to or ICMP error messages may have to be sent, 816 consuming additional energy. 818 The server model is not recommended. Variations of the model may be 819 a little bit more efficient, however. For instance, a local server 820 could send multiple requests in an effort to randomly hit a period 821 when the sensor is powered up. However, such practices would still 822 generate a lot of traffic in the network, which might not be 823 desirable. For instance, if the network involves low-powered RPL 824 routers [I-D.ietf-roll-rpl], extra traffic would be harmful. 826 4.2.3. Observer Model 828 The observer model [I-D.ietf-core-observe] allows clients to decide 829 what information they want and servers to decide when to send that 830 information. The model involves an initial registration, followed by 831 the server sending periodic notifications. These notifications can 832 be timed appropriately, so that the sensor only needs to wake up at 833 suitable times. 835 User or Sensor 836 Intermediary (Server) 837 (Client) 838 | | 839 | NON/GET | 840 | observe registration | 841 +---------------------->| 842 | | 843 | power-down 844 | . 845 | . 846 | . 847 | NON/RSP wake-up 848 | content | 849 |<----------------------+ 850 | | 851 | power-down 852 | . 853 | . 854 | . 855 | NON/RSP wake-up 856 | content | 857 |<----------------------+ 858 | | 859 | power-down 860 | . 861 | . 863 Figure 4. Observer model. 865 On the face of it, this is a very efficient model. Unfortunately, 866 one has to take into account the registration phase. For this model 867 to work, the sensor has to first be able to receive a registration 868 request, and later be able to receive further requests in case there 869 are changes or additional clients that want information. As a 870 result, a straightforward implementation of the observe framework 871 would appear to save no energy at all compared to the server model. 872 The sensor would still have to stay awake all the time. Again, this 873 model is not recommended. 875 Optimizations of the observer model are of course possible. 876 Transmitting multiple registration requests is less damaging than 877 transmitting multiple data requests, as the registration is only a 878 one-time event. Nevertheless, for interoperability, it would be 879 useful to understand what timelines and retransmission counts should 880 be followed by both servers and clients. For instance, a sensor 881 could assume that it has to be up one second out of every minute. 882 This would increase power consumption compared to the send-only model 883 as described in Section 3.5. Users or intermediaries interested in 884 subscribing to the information from the sensor would on the average 885 have to re-transmit registration requests thirty times to randomly 886 hit the period that a particular sensor is awake. 888 Another possible optimization would be the definition of implicit 889 subscriptions where for some application a certain subscription would 890 always be assumed so that a sensor can start sending periodic 891 notifications immediately to a well-known address. With such a model 892 the notifications are carried as responses and an intermediary can 893 act as a COAP cache, avoiding most of the issues from the above 894 paragraphs. 896 In addition, we have found a few more specific issues with the 897 observer model: 899 o There is no well-defined termination period. The consumer of the 900 information can observe that information is still flowing to it as 901 expected. However, when non-confirmable messages are used, the 902 sensor sending the notifications has no knowledge if the receiver 903 is still even in the network. As a result, a simple 904 implementation that keeps sending information until an explicit 905 unsubscription is not desirable, as the sensor may have to send 906 more messages than is necessary. 908 o Section 3.2 of [I-D.ietf-core-observe] specifies that a 909 registration request from the same source address but a different 910 port is considered a new, additional request. This can be 911 problematic if the client reboots and assigns a different port 912 number for its communication with the server. 914 o Section 3.3 of [I-D.ietf-core-observe] makes it optional for a 915 server to terminate the observation request when a GET request is 916 sent without the Observe option. This makes it hard for a client 917 to indicate to the server that it is no longer interested in the 918 resource. 920 o Section 3.3 of [I-D.ietf-core-observe] specifies that a 921 subscription can be terminated using a RST message. This makes it 922 impossible to know if the receiver rejects a confirmable 923 notification because some context was missing or because the 924 receiver wants to terminate the subscription. 926 o Section 3.3 of [I-D.ietf-core-observe] specifies that a timeout 927 when sending a notification may be used to terminate a 928 subscription. This seems like a drastic action for situations 929 where it is important that the listener gets the information. For 930 instance, using the observe model with a fire alarm would probably 931 not be a good idea if a temporary network problem could suddenly 932 terminate a subscription. 934 o A server may receive more subscription messages than it can 935 handle. The base specification defines an error code (5.03 936 Service Unavailable) that could perhaps be used to reply in such 937 situations, but it would be better if the behavior was explicitly 938 specified and if it used a separate error code to make it clearer 939 what the issue is. 941 4.3. Resources and Data Formats 943 The choice of resource identifiers (URIs) and data formats is 944 important to achieve semantic interoperability between a sensor and 945 an application using it. It is not enough to transport some data for 946 some object, the parties involved in the application have to 947 understand that the information comes from, say, a particular 948 temperature sensor and that the information contains a temperature 949 value encoded in a particular way. 951 The choice of URIs is clear as far as COAP transport is concerned in 952 the server model. Here the Link Format [I-D.ietf-core-link-format] 953 can be used by clients to find out what URIs exist. Nevertheless, 954 there are two remaining concerns: 956 o The authors of this memo found it desirable to implement a new URI 957 type to represent device identities, such as MAC addresses or 958 1-wire device identifiers. While UUIDs [RFC4122] can also be used 959 for this purpose, they are more complex for no additional value 960 from the point of view of our application. UUIDs are required to 961 contain a time component, which would cause both additional 962 implementation complexity, as well as make it more difficult to 963 correlate identifiers from a manufacturer's list or printed on the 964 outside of the sensor to the ones actually sent in the network. 965 (Such correlation is often required in order to configure the 966 real-world location of various sensors.). The new URI type is 967 simply of the form "device:ID", where ID is the hardware address 968 associated with the device. Such an URI could have uses not only 969 in sensor networks, but also in cataloging network equipment, etc. 971 o While the Link Format provides a way to determine what resources 972 exist, the semantics of those resources and data formats still 973 require standardization. Some work regarding such standardization 974 is ongoing, e.g. in ZigBee IP Smart Energy 2.0 Profile, but it 975 remains to be seen how much work is needed overall. This problem 976 might become even more real when sensors from particular 977 application areas, such as electrical cars or lightning, are being 978 implemented. Without any common schemas or data models no 979 interoperability can be provided. 981 o It is also important to care about the size and complexity of the 982 data models developed for low-power applications. Even if moving 983 from HTTP to COAP and some form of compression saves some number 984 of bytes, complicated XML models can easily consume the savings 985 and more. The authors have found [I-D.jennings-senml] a workable, 986 simple model. 988 In addition, in the client model it becomes important that the server 989 (local intermediary) is capable of storing information about any 990 resource when it receives a POST request. This is not necessarily 991 the case. First, it is unclear what resource identifiers the client 992 should use, particularly when multicast is used. Our example 993 implementation employed a well-known URI "/publish" and placed the 994 identity of the device sending the request inside the payload part of 995 the request along with the sensor readings. But it is not clear that 996 this is the best approach, and furthermore, such an approach has not 997 been standardized so it may not work with all devices. As an 998 example, in one of the COAP stacks that we tried, it is only possible 999 to generate resources by a user under a root resource called 1000 "storage". This requirement makes it incompatible with other 1001 implementations we tried. 1003 4.4. Configuration 1005 One overriding concern in networks with large number of sensors is 1006 configuration effort. In addition, the sensors are typically 1007 deployed in homes and other environments where the necessary skills 1008 for installation and operational tasks cannot be assumed. As a 1009 result, it is important that at installation of individual sensors 1010 leads to little or no configuration effort. Furthermore, given the 1011 small physical size and lack of user interfaces, it is essential that 1012 any configuration be doable on other devices on behalf of the 1013 sensors. 1015 A good model for configuration is that the sensors are fully factory- 1016 configured with respect to their identities and capable of operating 1017 autonomously in any IP network with suitable network interfaces. 1018 Typically, some configuration information is required but this can be 1019 provided as additional information associated with a particular 1020 sensor identity, and configured in the application server or 1021 intermediary. For instance, the physical location of a sensor can be 1022 configured in this manner. 1024 From the point of view of the COAP protocol and its communication 1025 model, this means that the sensors should operate as much as possible 1026 based on autoconfigured addresses, well-known destinations and/or 1027 resource discovery [I-D.ietf-core-link-format] 1028 [I-D.shelby-core-resource-directory]. COAP should also allow 1029 configuration and passing of additional information in 1030 intermediaries. 1032 5. Security Considerations 1034 Support for authentication of sensors, integrity of messages sent by 1035 sensors, or protection of the data objects carried by the messages 1036 would be useful in some environments, while physical security and 1037 link-layer protection may be sufficient in others. Mechanisms for 1038 these security mechanisms are for further study. 1040 6. Conclusions 1042 This memo has analyzed the power requirements for sensor applications 1043 through an example implementation that runs on absolute minimum power 1044 and through an analysis of various different more general 1045 communications models. 1047 The general conclusion is that the chosen communications model and 1048 overall system and network architecture is far more important for low 1049 power usage than details of the message formats. Much of the work in 1050 COAP has focused on the latter rather than the former. Even the 1051 difference between COAP and HTTP transactions is small compared to 1052 the difference between choosing the optimal and worst communications 1053 model. 1055 In particular, we would like to draw attention to system-level 1056 analysis to ensure that nodes can stay asleep for as long as 1057 necessary. This is particularly important when designing power- 1058 efficient data transmission models such as the observe framework. It 1059 is not enough for the data transmission itself to be efficient if the 1060 device needs to stay awake or communicate for other reasons 1061 (Section 4.2.3). Several other more detailed observations about the 1062 COAP specifications were also noted in Section 3.3, Section 4.1, 1063 Section 4.2, Section 4.3, and Section 4.4. 1065 The communication model is also not just about finding the most 1066 efficient sequence of messages. It is very much also an 1067 architectural decision. The authors believe that an information- 1068 centric or delay-tolerant networking model is appropriate for 1069 collecting information from sensor networks. These models allow 1070 communications based on identities, support intermittent 1071 connectivity, focus on data rather than the location of the data, and 1072 have the natural ability for nodes to aggregate, store, and process 1073 data. Some of the tasks for ensuring that such models can be 1074 employed with COAP include 1076 o Definition of URI types suitable to be used in sensor networks. 1078 o Accurate specification of multicast support. 1080 o Specifications for intermediary behavior so that they can store 1081 and process data from sensors. 1083 o Further standardization of data formats and application semantics. 1085 Finally, it should be noted that the conclusions in this memo should 1086 not be interpreted to apply too widely. Actuators and other, non- 1087 sensor low-power device implementations have likely very different 1088 requirements and may require different solutions. 1090 7. References 1092 7.1. Normative References 1094 [I-D.ietf-core-coap] 1095 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1096 "Constrained Application Protocol (CoAP)", 1097 draft-ietf-core-coap-06 (work in progress), May 2011. 1099 [I-D.ietf-core-link-format] 1100 Shelby, Z., "CoRE Link Format", 1101 draft-ietf-core-link-format-05 (work in progress), 1102 May 2011. 1104 [I-D.ietf-core-observe] 1105 Hartke, K. and Z. Shelby, "Observing Resources in CoAP", 1106 draft-ietf-core-observe-02 (work in progress), March 2011. 1108 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 1109 Incremental Update", RFC 1624, May 1994. 1111 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1112 (IPv6) Specification", RFC 2460, December 1998. 1114 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1115 Architecture", RFC 4291, February 2006. 1117 7.2. Informative References 1119 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1120 RFC 2131, March 1997. 1122 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1123 Listener Discovery (MLD) for IPv6", RFC 2710, 1124 October 1999. 1126 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1127 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1129 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1130 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1131 July 2005. 1133 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1134 "Considerations for Internet Group Management Protocol 1135 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1136 Switches", RFC 4541, May 2006. 1138 [RFC4627] Crockford, D., "The application/json Media Type for 1139 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1141 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1142 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1143 September 2007. 1145 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1146 Address Autoconfiguration", RFC 4862, September 2007. 1148 [W3C.REC-xml-19980210] 1149 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 1150 Recommendation", World Wide Web Consortium 1151 FirstEdition REC-xml-19980210, February 1998, 1152 . 1154 [I-D.shelby-core-resource-directory] 1155 Shelby, Z. and S. Krco, "CoRE Resource Directory", 1156 draft-shelby-core-resource-directory-00 (work in 1157 progress), June 2011. 1159 [I-D.ietf-roll-rpl] 1160 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 1161 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 1162 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 1163 Lossy Networks", draft-ietf-roll-rpl-19 (work in 1164 progress), March 2011. 1166 [I-D.jennings-senml] 1167 Jennings, C., "Media Type for Sensor Markup Language 1168 (SENML)", draft-jennings-senml-05 (work in progress), 1169 March 2011. 1171 [arkko.iab] 1172 Arkko, J., "Interoperability Concerns in the Internet of 1173 Things", Position paper at the IAB workshop on Smart 1174 Objects , March 2011, . 1177 Appendix A. Acknowledgments 1179 The authors would like to thank to Magnus Westerlund, Ari Keranen, 1180 Stig Venaas, Zach Shelby, Cullen Jennings, Vlasios Tsiatsis, Jan 1181 Holler, Anders Eriksson, and Joel Halpern for their help and for 1182 interesting discussions in this problem space. 1184 Authors' Addresses 1186 Jari Arkko 1187 Ericsson 1188 Jorvas 02420 1189 Finland 1191 Email: jari.arkko@piuha.net 1193 Heidi-Maria Rissanen 1194 Ericsson 1195 Jorvas 02420 1196 Finland 1198 Email: heidi-maria.rissanen@ericsson.com 1200 Salvatore Loreto 1201 Ericsson 1202 Jorvas 02420 1203 Finland 1205 Email: salvatore.loreto@ericsson.com 1206 Zoltan Turanyi 1207 Ericsson 1208 Irinyi Jozsef u. 4-20. 1209 Budabest 1210 Hungary 1212 Email: zoltan.turanyi@ericsson.com 1214 Oscar Novo 1215 Ericsson 1216 Jorvas 02420 1217 Finland 1219 Email: oscar.novo@ericsson.com