idnits 2.17.1 draft-arkko-core-cellular-00.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 == Line 717 has weird spacing: '...Android devel...' -- The document date (July 9, 2012) is 4308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.arkko-core-security-arch' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-jose-json-web-signature' is defined on line 699, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-05 == Outdated reference: A later version (-01) exists of draft-vial-core-mirror-proxy-00 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-00 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-11 == Outdated reference: A later version (-10) exists of draft-jennings-senml-05 == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-signature-01 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft A. Eriksson 4 Intended status: Informational A. Keranen 5 Expires: January 10, 2013 Ericsson 6 July 9, 2012 8 Building Power-Efficient CoAP Devices for Cellular Networks 9 draft-arkko-core-cellular-00 11 Abstract 13 This memo discusses the use of the Constrained Application Protocol 14 (CoAP) protocol in building sensors and other devices that employ 15 cellular networks as a communications medium. Building communicating 16 devices that employ these networks is obviously well known, but this 17 memo focuses specifically on techniques necessary to minimize power 18 consumption. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 10, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Goals for Low-Power Operation . . . . . . . . . . . . . . . . 4 56 3. Link-Layer Assumptions . . . . . . . . . . . . . . . . . . . . 7 57 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 5. Discovery and Registration . . . . . . . . . . . . . . . . . . 9 59 6. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 7. Real-Time Reachable Devices . . . . . . . . . . . . . . . . . 11 61 8. Sleepy Devices . . . . . . . . . . . . . . . . . . . . . . . . 12 62 8.1. Implementation Considerations . . . . . . . . . . . . . . 13 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 67 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 This memo discusses the use of the Constrained Application Protocol 74 (CoAP) protocol [I-D.ietf-core-coap] in building sensors and other 75 devices that employ cellular networks as a communications medium. 76 Building communicating devices that employ these networks is 77 obviously well known, but this memo focuses specifically on 78 techniques necessary to minimize power consumption. CoAP has many 79 advantages, including being simple to implement; a thousand lines for 80 the entire software above IP layer is plenty for a CoAP-based sensor, 81 for instance. However, while many of these advantages are obvious 82 and easily obtained, optimizing power consumption remains challenging 83 and requires careful design [I-D.arkko-core-sleepy-sensors]. 85 The memo targets primarily 3GPP cellular networks in their 2G, 3G, 86 and LTE variants and their future enhancements, including possible 87 power efficiency improvements at the radio and link layers. The 88 exact standards or details of the link layer or radios are not 89 relevant for our purposes, however. To be more precise, the material 90 in this memo is suitable for any large-scale, public network that 91 employs point-to-point communications model and radio technology. 93 Our focus is devices that need to be optimized for power usage, and 94 on devices that employ CoAP. As a general technology, CoAP is 95 similar to HTTP. It can be used in various ways and network entities 96 may take on different roles. This freedom allows the technology to 97 be used in efficient and less efficient ways. Some guidance is 98 needed to understand what communication models over CoAP are 99 recommended when low power usage is a critical goal. 101 The recommendations in this memo should be taken as complementary to 102 device hardware optimization, microelectronics improvements, and 103 further evolution of the underlying link and radio layers. Further 104 gains in power efficiency can certainly be gained on several fronts; 105 the approach that we take in this memo is to do what can be done at 106 the IP, transport, and application layers to provide the best 107 possible power efficiency. Application implementors generally have 108 to use the current generation microelectronics, currently available 109 radio networks and standards, and so on. This focus in our memo 110 should by no means be taken as an indication that further evolution 111 in these other areas is unnecessary. Such evolution is useful, is 112 ongoing, and is generally complementary to the techniques presented 113 in this memo. The evolution of underlying technologies may change 114 what techniques described here are useful for a particular 115 application, however. 117 The rest of this memo is structured as follows. Section 2 discusses 118 the need and goals for low-power devices. Section 3 outlines our 119 expectations for the low layer communications model. Section 4 120 describes the two scenarios that we address, and Section 5, 121 Section 6, Section 7 and Section 8 give guidelines for use of CoAP in 122 these scenarios. 124 2. Goals for Low-Power Operation 126 There are many situations where power usage optimization is 127 unnecessary. Optimization may not be necessary on devices that can 128 run on power feed over wired communications media, such as in Power- 129 over-Ethernet (PoE) solutions. These devices may require a 130 rudimentary level of power optimization techniques just to avoid keep 131 overall energy costs and aggregate power feed sizes at a reasonable 132 level, but more extreme techniques necessary for battery powered 133 devices are not required. The situation is similar with devices that 134 can be easily be connected to mains power. Other types of devices 135 may get an occasional charge of power from energy harvesting 136 techniques. For instance, some environmental sensors can run on 137 solar cells. Typically, these devices still have to regulate their 138 power usage in a strict manner, for instance to be able to use as 139 small and inexpensive solar cells as possible. 141 In battery operated devices the power usage is even more important. 142 For instance, one of the authors employs over a hundred different 143 sensor devices in his home network. A majority of these devices are 144 wired and run on PoE, but in most environments this would be 145 impractical because the necessary wires do not exist. The future is 146 in wireless solutions that can cover buildings and other environments 147 without assuming a pre-existing wired infrastructure. In addition, 148 in many cases it is impractical to provide a mains power source. 149 Often there are no power sockets easily available in the locations 150 that the devices need to be in, and even if there were, setting up 151 the wires and power adapters would be more complicated than 152 installing a standalone device without any wires. 154 Yet, with a large number of devices the battery lifetimes become 155 critical. Cost and practical limits dictate that devices can be 156 largely just bought and left on their own. For instance, with 157 hundred devices, even a ten-year battery lifetime results in a 158 monthly battery change for one device within the network. This may 159 be impractical in many environments. In addition, some devices may 160 be physically difficult to reach for a battery change. Or, a large 161 group of devices -- such as utility meters or environmental sensors 162 -- cannot be economically serviced too often, even if in theory the 163 batteries could be changed. 165 SENSOR COMMUNICATION INTERVAL 166 +-----------------+------------------+-----------------+ 167 POWER SOURCE | Seconds | Minutes or Hours | Days and longer | 168 +--------------+-----------------+------------------+-----------------+ 169 | | | | | 170 | Battery | Low-power | Low-power or | Always-off | 171 | | | Always-off | | 172 +--------------+-----------------+------------------+-----------------+ 173 | | | | | 174 | Harvesting | Low-power | Low-power or | Always-off | 175 | | | Always-off | | 176 +--------------+-----------------+------------------+-----------------+ 177 | | | | | 178 | Mains | Always-on | Always-on | Always-on | 179 | | | | | 180 +--------------+-----------------+------------------+-----------------+ 182 Figure 1: Power usage strategies for different classes of applications 184 Many of these situations lead to a requirement for minimizing power 185 usage and/or maximing battery lifetimes. A summary of the different 186 situations for sensor-type devices is shown in Figure 1 above. 187 Unfortunately, much of our current technology has been built with 188 different objectives in mind. Networked devices that are "always 189 on", gadgets that require humans to recharge it every couple of days, 190 and protocols that have been optimized to maximize throughput rather 191 than conserve resources. 193 Long battery lifetimes are required for many applications, however. 194 In some cases these lifetimes should be in the order of years or even 195 a decade or longer. Some communication devices already reach multi- 196 year lifetimes, and continuous improvement in low-power electronics 197 and advances in radio technology keep pushing these lifetimes longer. 198 However, it is perhaps fair to say that battery lifetimes are 199 generally too short at present time. 201 The general strategies for power usage from Figure 1 can be described 202 as follows: 204 Always-on 206 Under this strategy, there is no reason for extreme measures for 207 power saving. The device can stay on in the usual manner all the 208 time. It may be useful to employ a power-friendly hardware or 209 limit the number of wireless transmissions, CPU speeds, and other 210 aspects for general power saving and cooling needs, but the device 211 can be in the network all the time. 213 Always-off 215 Under this strategy, the device sleeps such long periods at a time 216 that once it wakes up, it makes sense for it to not pretend that 217 it is connected to the network during those times. These devices 218 re-attach to the network as they are woken up. The main 219 optimization goal is to minimize the effort during such re- 220 attachment process and any resulting application communications. 222 If the device sleeps for long periods of time, the relative 223 increase in energy expediture during reattachment for infrequent 224 communication may be acceptable. 226 Low-power 228 These devices need to operate on very small amount of power, but 229 still be able to communicate in a relatively frequent basis. This 230 implies that extremely low power solutions needs to be used for 231 the hardware, chosen link layer mechanisms, and so on. Typically, 232 given the small amount of time between transmissions, despite 233 their sleep state these devices retain some form of network 234 attachment to the network. Techniques used for minimizing power 235 usage for the network communications include minimizing any work 236 from re-establishing communications after waking up, tuning the 237 communications frequency, and paging frequency and other 238 parameters appropriately. 240 Power usage can not be evaluated solely based on lower layer 241 communications. The entire system, including upper layer protocols 242 and applications is responsible for the power consumption as a whole. 243 The lower communication layers have already adopted many techniques 244 that can be used to reduce power usage, such as scheduling device 245 wake-up times. Further reductions will likely need some co-operation 246 from the upper layers so that unnecessary communications, denial-of- 247 service attacks on power consumptions, and other power drains are 248 eliminated. 250 Of course, application requirements ultimately determine what kinds 251 of communications are necessary. For instance, some applications 252 require more data to be sent than others. The purpose of the 253 guidelines in this memo is not to prefer one or the other 254 application, but to provide guidance on how to minimize the amount of 255 communications overhead that is not directly required by the 256 application. While such optimization is generally useful, it is 257 relatively speaking most noticeable in applications that transfer 258 only a small amount of data, or operate only infrequently. 260 3. Link-Layer Assumptions 262 We assume that the underlying communications network can be any 263 large-scale, public network that employs point-to-point 264 communications model and radio technology. 2G, 3G, and LTE networks 265 are examples of such networks, but not the only possible networks 266 with these characteristics. 268 In the following we look at some of these characteristics and their 269 implications. Note that in most cases these characteristics are not 270 properties of the specific networks but rather inherent in the 271 concept of public networks. 273 Public networks 275 Using a public network service implies that applications can be 276 deployed without having to build a network to go with them. For 277 economical reasons, only the largest users (such as utility 278 companies) could afford to build their own network, and even they 279 would not be able to provide a world-wide coverage. This means 280 that applications where coverage is important can be built. For 281 instance, most transport sector applications require national or 282 even world-wide coverage to work. 284 But there are other implications, as well. By definition, the 285 network is not tailored for this application and with some 286 exceptions, the traffic passes through the Internet. One 287 implication of this is that there are generally no application- 288 specific network configurations or discovery support. For 289 instance, the public network helps devices to get on the Internet, 290 set up default routers, configure DNS servers, and so on, but does 291 nothing for configuring possible higher-layer functions, such as 292 servers the device might need to contact to perform its 293 application functions. 295 Public networks often provide web proxies, and these can in some 296 cases make a significant improvement for delays and cost of 297 communication over the wireless link. For instance, collecting 298 content from a large number of servers used to render a web page 299 and resolving their DNS names in a proxy instead of the user's 300 device may cut down on the general chattiness of the 301 communications, therefore reducing overall delay in completing the 302 entire transaction. However, as of today such proxies are 303 provided only for HTTP communications, not for CoAP. 305 Similarly, given the lack of available IPv4 addresses, the chances 306 are that many devices are behind a network address translation 307 (NAT) device. This means that they are not easily reachable as 308 servers. Alternatively, the devices may be directly on the global 309 Internet (either on IPv4 or IPv6) and easily reachable as servers. 310 Unfortunately, this may mean that they also receive unwanted 311 traffic, which may have implications for both power consumption 312 and service costs. 314 Point-to-point link model 316 This is a common link model in cellular networks. One implication 317 of this model is that there will be no other nodes on the same 318 link, except maybe for the service provider's router. As a 319 result, multicast discovery can not be reasonably used for any 320 local discovery purposes. While the configuration of the service 321 provider's router for specific users is theoretically possible, in 322 practice this is difficult to achieve, at least for any small user 323 that can not afford a network-wide contract for a private APN. 324 The public network access service has little per-user tailoring. 326 Radio technology 328 The use of radio technology means that power is needed to operate 329 the radios. Transmission generally requires more power than 330 reception. However, radio protocols have generally been designed 331 so that a device checks periodically whether it has messages. In 332 a situation where messages arrive seldomly or not at all, this 333 checking consumes energy. Research has shown that these periodic 334 checks (such as LTE paging message reception) are often a far 335 bigger contributor to energy consumption than message 336 transmission. 338 Note that for situations where there are several applications on 339 the same device wishing to communicate with the Internet in some 340 manner, bundling those applications together at the same time can 341 be very useful. Some guidance for these techniques in the 342 smartphone context can be found in [Android-Bundle]. 344 Naturally, each device has a freedom to decide when it sends 345 messages. In addition, we assume that there is some way for the 346 devices to control when or how often it wants to receive messages. 347 Specific methods for doing this depend on the specific network being 348 used and also tend to change as improvements in the design of these 349 networks are incorporated. The reception control methods generally 350 come in two variants, fine grained mechanisms that deal with how 351 often the device needs to wake-up for paging messages, and more crude 352 mechanisms where the device simply disconnects from the network for a 353 period of time. There are associated costs and benefits to each 354 method, but those are not relevant for this memo, as long as some 355 control method exists. 357 4. Scenarios 359 Not all applications or situations are equal. They may require 360 different solutions or communication models. This memo focuses on 361 two common scenarios: 363 Real-Time Reachable Devices 365 This scenario involves all communication that requires real-time 366 or near real-time communications with a device. That is, a 367 network entity must be able to reach the device with a small time 368 lag at any time, and no pre-agreed wake-up schedule can be 369 arranged. By "real-time" we mean any reasonable end-to-end 370 communications latency, be it measured in millieconds or seconds. 371 However, unpredictable sleep states are not expected. 373 Examples of devices in this category include sensors that must be 374 measurable from a remote source at any instant in time, such as 375 process automation sensors and actuators that require immediate 376 action, such as lightbulbs or door locks. 378 Sleepy Devices 380 This scenario involves freedom to choose when device communicates. 381 The device is often expected to be able to be in a sleep state for 382 much of its time. The device itself can choose when it 383 communicates, or it lets the network assist in this task. 385 Examples of devices in this category include sensors that track 386 slowly changing values, such as temperature sensors and actuators 387 that control a relatively slow process, such as heating systems. 389 Note that there may be hard real-time requirements, but they are 390 expressed in terms of how fast the device can communicate, not in 391 terms of how fast it can respond to a network stimuli. For 392 instance, a fire detector can be classified as a sleepy device as 393 long as it can internally quickly wake up on detecting fire and 394 initiate the necessary communications without delay. 396 5. Discovery and Registration 398 In both scenarios the device will be attached to a public network. 399 Without special arrangements, the device will also get a dynamically 400 assigned IP address or an IPv6 prefix. At least one but typically 401 several router hops separate the device from its communicating peers 402 such as application servers. As a result, the address or even the 403 existence of the device is typically not immediately obvious to the 404 other nodes participating in the application. As discussed earlier, 405 multicast discovery has limited value in public networks; network 406 nodes cannot practically discover individual devices in a large 407 public network. And the devices can not discover who they need to 408 talk, as the public network offers just basic Internet connectivity. 410 Our recommendation is to initiate a discovery and registration 411 process. This allows each device to inform its peers that it has 412 connected to the network and that it is reachable at a given IP 413 address. 415 The registration part is easy; a resource directory or mirror proxy 416 can be used. The device should perform the necessary registration 417 with these devices, for instance, as specified in 418 [I-D.shelby-core-resource-directory] and 419 [I-D.vial-core-mirror-proxy]. In order to do this registration, the 420 device needs to know its CORE Link Format description, as specified 421 in [I-D.ietf-core-link-format]. In essence, the registration process 422 involves performing a GET on .well-known/core/?rt=core-rd at the 423 address of the resource directory (or rt=core-mp for mirror proxies), 424 and then doing a POST on the path of the discovered resource. 426 However, current CoAP specifications provide limited support for 427 discovering the resource directory or mirror proxy. Local multicast 428 discovery only works in LAN-type networks, but not in these public 429 cellular networks. Our recommended alternate methods for discovery 430 are the following: 432 Manual Configuration 434 The DNS name of the resource directory or mirror proxy is manually 435 configured. This approach is suitable in situations where the 436 owner of the devices has the resources and capabilities to do the 437 configuration. For instance, a utility company can typically 438 program its metering devices to point to the company servers. 440 Manufacturer Server 442 The DNS name of the directory or proxy is hardwired to the 443 software by the manufacturer, and the directory or proxy is 444 actually run by the manufacturer. This approach is suitable in 445 many consumer usage scenarios, where it would be unreasonable to 446 assume that the consumer runs any specific network services. The 447 manufacturer's web interface and the directory/proxy servers can 448 co-operate to provide the desired functionality to the end user. 449 For instance, the end user can register a device identity in the 450 manufacturer's web interface and ask specific actions to be taken 451 when the device does something. 453 Delegating Manufacturer Server 455 The DNS name of the directory or proxy is hardwired to the 456 software by the manufacturer, but this directory or proxy merely 457 redirects the request to a directory or proxy run by the whoever 458 bought the device. This approach is suitable in many enterprise 459 environments, as it allows the enterprise to be in charge of 460 actual data collection and device registries; only the initial 461 bootstrap goes through the manufacturer. In many cases there are 462 even legal requirements (such as EU privacy laws) that prevent 463 providing unnecessary information to third parties. 465 Common Global Resolution Infrastructure 467 The delegating manufacturer server model could be generalized into 468 a reverse-DNS -like discovery infrastructure that could answer the 469 question "this is device with identity ID, where is my home 470 registration server?". However, at present no such resolution 471 system exists. (Note: The EPCGlobal system for RFID resolution is 472 reminiscent of this approach.) 474 6. Data Formats 476 A variety of data formats exist for passing around data. These data 477 formats include XML, JSON, EXI, and text formats. Message lengths 478 can have a significant effect on the amount of energy required for 479 the communications, and such it is highly desirable to keep message 480 lengths minimal. At the same time, extreme optimization can affect 481 flexibility and ease of programming. The authors recommend 482 [I-D.jennings-senml] as a compact, yet easily processed and 483 extendable textual format. 485 7. Real-Time Reachable Devices 487 These devices are often best modeled as CoAP servers. The device 488 will have limited control on when it receives messages, and it will 489 have to listen actively for messages, up to the limits of the 490 underlying link layer. If the device acts also in client role in 491 some phase of its operation, it can control how many transmissions it 492 makes on its own behalf. 494 The packet reception checks should be tailored according to the 495 requirements of the application. If sub-second response time is not 496 needed, a slightly more infrequent checking process may save some 497 power. 499 For sensor-type devices, the CoAP OBSERVE extension 500 [I-D.ietf-core-observe] may be supported. This allows the sensor to 501 track changes to the sensed value, and make an immediate observation 502 response upon a change. This may reduce the amount of polling needed 503 to be done by the client. Unfortunately, it does not reduce the time 504 that the device needs to be listening for requests. Subscription 505 requests from other clients than the currently registered one may 506 come at any time, the current client may change its request, and the 507 device still needs to respond to normal queries as a server. As a 508 result, the sensor can not rely having to communicate only on its own 509 choice of observation interval. 511 In order to act as a server, the device needs to be placed in a 512 public IPv4 address, be reachable over IPv6, or hosted in a private 513 network. If the the device is hosted on a private network, then all 514 other nodes need to access this device also need to reside in the 515 same private network. There are multiple ways to provide private 516 networks over public cellular networks. One approach is to dedicate 517 a special Access Point Name or APN for the private network. 518 Corporate access via cellular networks has often been arranged in 519 this manner, for instance. Another approach is to use Virtual 520 Private Networking (VPN) technology, for instance IPsec-based VPNs. 522 Power consumption from unwanted traffic is problematic in these 523 devices, unless placed in a private network or protected by a 524 operator-provided firewall service. Devices on an IPv6 network will 525 have some protection through the nature of the 2^64 address 526 allocation for a single terminal in a 3GPP cellular network; the 527 attackers will be unable to guess the full IP address of the device. 528 However, this protects only the device from processing a packet, but 529 since the network will still deliver the packet to any of the 530 addresses within the assigned 64-bit prefix, packet reception costs 531 are still incurred. 533 Note that the the VPN approach can not prevent unwanted traffic 534 received at the tunnel endpoint address, and may require keep-alive 535 traffic. Special APNs can solve this issue, but require explicit 536 arrangement with the service provider. 538 8. Sleepy Devices 540 These devices are best modeled as devices that can delegate queries 541 to some other node. For instance, as mirror proxy clients 542 [I-D.vial-core-mirror-proxy]. When the device initializes itself, it 543 makes a registration of itself in a mirror proxy as described above 544 in Section 5 and then continues to send periodic updates of sensor 545 values. 547 As a result, the device acts only as a client, not a server, and can 548 shut down all communication channels while it is during its sleeping 549 period. The length of the sleeping period depends on power and 550 application requirements. Some environmental sensors might use a day 551 or a week as the period, while other devices may use a smaller values 552 ranging from minutes to hours. 554 Other approaches for delegation include CoAP-options described in 555 [I-D.castellani-core-alive] 556 [I-D.fossati-core-publish-monitor-options]. In this memo we use 557 mirror proxies as an example, because of their ability to work with 558 both HTTP and CoAP implementations; but the concepts are similar and 559 the IETF work is still in progress so the final protocol details are 560 yet to be decided. 562 The ability to shut down communications and act as only a client has 563 four impacts: 565 o Radio transmission and reception can be turned off during the 566 sleeping period, reducing power consumption significantly. 568 o However, some power and time is consumed by having to re-attach to 569 the network after the end of a sleep period. 571 o The window of opportunity for unwanted traffic to arrive is much 572 smaller, as the device is listening for traffic only part of the 573 time. Note that networks may cache packets for some time though. 574 On the other hand, stateful firewalls can effectively remove much 575 of unwanted traffic for client type devices. 577 o The device may exist behind a NAT or a firewall without being 578 impacted. Note that "Simple Security" basic IPv6 firewall 579 capability [RFC6092] blocks inbound UDP traffic by default, so 580 just moving to IPv6 is not direct solution to this problem. 582 For sleepy devices that represent actuators, it is also possible to 583 use the mirror proxy model. The device can make periodic polls to 584 the proxy to determine if a variable has changed. 586 8.1. Implementation Considerations 588 There are several challenges in implementing sleepy devices. They 589 need hardware that can be put to an appropriate sleep mode but yet 590 awakened when it is time to do something again. This is not always 591 easy in all hardware platforms. It is important to be able to shut 592 down as much of the hardware as possible, preferably down to 593 everything else except a clock circuit. The platform also needs to 594 support re-awakening at suitable time scales, as otherwise the device 595 needs to be powered up too frequently. 597 Most commercial cellular modem platforms do not allow applications to 598 suspend the state of the communications stack. Hence, after a power- 599 off period they need to re-establish communications, which takes some 600 amount of time and extra energy. 602 Implementations should have a coordinated understanding of the state 603 and sleeping schedule. For instance, it makes no sense to keep a CPU 604 powered up, waiting for a message when the lower layer has been told 605 that the next possible paging opportunity is some time away. 607 The cellular networks have a number of adjustable configuration 608 parameters, such as the maximum used paging interval. Proper setting 609 of these values has an impact on the power consumption of the device, 610 but with the current business practices, such settings are rarely 611 negotiated when the user's subscription is provisioned. 613 9. Security Considerations 615 There are no particular security aspects with what has been discussed 616 in this memo, except for the ability to delegate queries for a 617 resource to another node. Depending on how this is done, there are 618 obvious security issues which have largely NOT yet been addressed in 619 the relevant Internet Drafts [I-D.vial-core-mirror-proxy] 620 [I-D.castellani-core-alive] 621 [I-D.fossati-core-publish-monitor-options]. However, we point out 622 that in general, security issues in delegation can be solved either 623 through reliance on your local network support nodes (which may be 624 quite reasonable in many environments) or explict end-to-end 625 security. Explicit end-to-end security through nodes that are awake 626 at different times means in practice end-to-end data object security. 627 We have implemented one such mechanism for sleepy nodes as described 628 in [I-D.aks-crypto-sensors]. 630 The security considerations relating to CoAP [I-D.ietf-core-coap] and 631 the relevant link layers should apply. Note that cellular networks 632 universally employ per-device authentication, integrity protection, 633 and for most of the world, encryption of all their communications. 634 Additional protection of transport sessions is possible through 635 mechanisms described in [I-D.ietf-core-coap] or data objects. 637 10. IANA Considerations 639 There are no IANA impacts in this memo. 641 11. References 643 11.1. Normative References 645 [I-D.ietf-core-coap] 646 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 647 "Constrained Application Protocol (CoAP)", 648 draft-ietf-core-coap-06 (work in progress), May 2011. 650 [I-D.ietf-core-observe] 651 Hartke, K., "Observing Resources in CoAP", 652 draft-ietf-core-observe-05 (work in progress), March 2012. 654 [I-D.vial-core-mirror-proxy] 655 Vial, M., "CoRE Mirror Proxy", 656 draft-vial-core-mirror-proxy-00 (work in progress), 657 March 2012. 659 [I-D.shelby-core-resource-directory] 660 Shelby, Z. and S. Krco, "CoRE Resource Directory", 661 draft-shelby-core-resource-directory-00 (work in 662 progress), June 2011. 664 [I-D.ietf-core-link-format] 665 Shelby, Z., "CoRE Link Format", 666 draft-ietf-core-link-format-11 (work in progress), 667 January 2012. 669 [I-D.jennings-senml] 670 Jennings, C., "Media Type for Sensor Markup Language 671 (SENML)", draft-jennings-senml-05 (work in progress), 672 March 2011. 674 11.2. Informative References 676 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 677 Customer Premises Equipment (CPE) for Providing 678 Residential IPv6 Internet Service", RFC 6092, 679 January 2011. 681 [I-D.arkko-core-sleepy-sensors] 682 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 683 Novo, "Implementing Tiny COAP Sensors", 684 draft-arkko-core-sleepy-sensors-01 (work in progress), 685 July 2011. 687 [I-D.arkko-core-security-arch] 688 Arkko, J. and A. Keranen, "CoAP Security Architecture", 689 draft-arkko-core-security-arch-00 (work in progress), 690 July 2011. 692 [I-D.aks-crypto-sensors] 693 Sethi, M., Arkko, J., Keranen, A., and H. Rissanen, 694 "Practical Considerations and Implementation Experiences 695 in Securing Smart Object Networks", 696 draft-aks-crypto-sensors-02 (work in progress), 697 March 2012. 699 [I-D.ietf-jose-json-web-signature] 700 Jones, M., Bradley, J., and N. Sakimura, "JSON Web 701 Signature (JWS)", draft-ietf-jose-json-web-signature-01 702 (work in progress), March 2012. 704 [I-D.castellani-core-alive] 705 Castellani, A. and S. Loreto, "CoAP Alive Message", 706 draft-castellani-core-alive-00 (work in progress), 707 March 2012. 709 [I-D.fossati-core-publish-monitor-options] 710 Fossati, T., Giacomin, P., and S. Loreto, "Publish and 711 Monitor Options for CoAP", 712 draft-fossati-core-publish-monitor-options-01 (work in 713 progress), March 2012. 715 [Android-Bundle] 716 Developer.Android.Com, "Optimizing Downloads for Efficient 717 Network Access", Android developer note http:// 718 developer.android.com/training/efficient-downloads/ 719 efficient-network-access.html, . 723 Appendix A. Acknowledgments 725 The authors would like to thank Zach Shelby, Jan Holler, Salvatore 726 Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim 727 Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran, 728 Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes 729 Tschofenig, and Anna Larmo for interesting discussions in this 730 problem space. 732 Authors' Addresses 734 Jari Arkko 735 Ericsson 736 Jorvas 02420 737 Finland 739 Email: jari.arkko@piuha.net 741 Anders Eriksson 742 Ericsson 743 Stockholm 164 83 744 Sweden 746 Email: anders.e.eriksson@ericsson.com 748 Ari Keranen 749 Ericsson 750 Jorvas 02420 751 Finland 753 Email: ari.keranen@ericsson.com