idnits 2.17.1 draft-kovatsch-lwig-class1-coap-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 : ---------------------------------------------------------------------------- ** 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 (October 15, 2012) is 4210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6550' is defined on line 432, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-fossati-core-publish-option-00 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-09 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-12 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-06 == Outdated reference: A later version (-03) exists of draft-ietf-lwig-guidance-02 == Outdated reference: A later version (-05) exists of draft-rahman-core-sleepy-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Light-Weight Implementation Guidance M. Kovatsch 3 Internet-Draft ETH Zurich 4 Intended status: Informational October 15, 2012 5 Expires: April 18, 2013 7 Implementing CoAP for Class 1 Devices 8 draft-kovatsch-lwig-class1-coap-00 10 Abstract 12 The Constrained Application Protocol (CoAP) is designed for resource- 13 constrained nodes and networks, e.g., sensor nodes in low-power lossy 14 networks (LLNs). Still, to implement this Internet protocol on Class 15 1 devices, i.e., ~10KiB of RAM and ~100KiB of ROM, light-weight 16 implementation techniques are necessary. This document provides the 17 lessons learned from implementing CoAP for Contiki, an operating 18 system for tiny, battery-operated networked embedded systems. The 19 information may become part of the Light-Weight Implementation 20 Guidance document planned by the IETF working group LWIG. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 18, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Implementing CoAP . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Memory Management . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Message Buffers . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 5 61 2.4. Separate Responses . . . . . . . . . . . . . . . . . . . . 5 62 2.5. Deduplication . . . . . . . . . . . . . . . . . . . . . . 5 63 2.6. Observing . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.7. Blockwise Transfers . . . . . . . . . . . . . . . . . . . 6 65 2.8. Developer API . . . . . . . . . . . . . . . . . . . . . . 7 66 3. Low-power Wireless . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1. Radio Duty Cycling . . . . . . . . . . . . . . . . . . . . 8 68 3.2. Sleepy Nodes . . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 5. Informative References . . . . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 The Internet protocol suite is a suitable solution to realize an 76 Internet of Things (IoT), a network of tiny networked embedded 77 devices that create a link to the physical world. The narrow waist 78 of IP can be used to directly access sensor readings throughout a 79 sustainable city, acquire the necessary information for the smart 80 grid, or control smart homes, buildings, and factories---seamlessly 81 from the existing IT infrastructure. The layered architecture helps 82 to manage the complexity, as multiple aspects such as routing over 83 lossy links, link layer adaption, and low-power communication have to 84 be addressed. Nonetheless, attention has to be given to achieve 85 light-weight implementations that can run on resource-constrained 86 devices such as sensor nodes with only microcontroller units (MCUs), 87 ~10KiB of RAM, and ~100KiB of ROM [I-D.ietf-lwig-guidance]. Figure 1 88 depicts a typical stack configuration for such Class 1 devices. This 89 document discusses a light-weight implementation of CoAP at the 90 application layer in Section 2 and techniques for energy-efficiency 91 such as radio duty cycling in Section 3. 93 +--------------------+--------------------------+ 94 | Layer | Protocol | 95 +--------------------+--------------------------+ 96 | Application | CoAP | 97 | Transport | UDP | 98 | Network | IPv6 / RPL | 99 | Adaptation | 6LoWPAN | 100 | MAC | CSMA / link-layer bursts | 101 | Radio Duty Cycling | ContikiMAC | 102 | Physical | IEEE 802.15.4 | 103 +--------------------+--------------------------+ 104 A typical stack configuration for Class 1 devices. 106 Figure 1 108 2. Implementing CoAP 110 The following experience stems from implementing CoAP for the Contiki 111 operating system [ERBIUM], but is generalized for any embedded OS. 112 The information is not meant to be a final solution, but a first step 113 towards a Light-Weight Implementation Guidance contribution. 114 Alternatives will be incorporated throughout the merging process. 115 The document assumes detailed knowledge of CoAP, its message format 116 and interaction model. For more information, please refer to to 117 [I-D.ietf-core-coap], [I-D.ietf-core-block], and 118 [I-D.ietf-core-observe]. 120 2.1. Memory Management 122 For embedded systems, it is common practice to allocate memory 123 statically to ensure stable behavior, as no memory management unit 124 (MMU) or other abstractions are available. For a CoAP node, the two 125 key parameters are the number of (re)transmission buffers and the 126 maximum message size that must be supported by each buffer. It is 127 common practice to set the maximum message size far below the 1280- 128 byte MTU of 6LoWPAN to allow more than one open confirmable 129 transmissions at a time (in particular for observe notifications). 130 Note that implementations on constrained platforms often not even 131 support the full MTU. Larger messages must then use blockwise 132 transfers [I-D.ietf-core-block], while a good trade-off between 133 6LoWPAN fragmentation and CoAP header overhead must be found. 134 Usually the amount of available free RAM dominates this decision, on 135 current platforms ending up at a maximum message size of 128 or 256 136 bytes plus maximum estimated header size. 138 2.2. Message Buffers 140 Class 1 devices usually run an OS or event loop system with 141 cooperative multi-threading. This allows to optimize memory usage 142 through in-place processing and reuse of buffers. Incoming payload 143 and byte strings of the header can be directly accessed in the IP 144 buffer, which is provided by the OS, using pointers. For numeric 145 options, there are two alternatives: Either process the header on the 146 fly when an option is accessed or initially parse/allocate all values 147 into a local data structure. Although the latter choice requires an 148 additional amount of memory, it is preferable. First, local 149 processing anyway requires integers in host byte order and stored in 150 a variable of corresponding type. Second, on-the-fly processing 151 might force developers to set options for outgoing messages in a 152 specific order or cause extensive memmove operations due to CoAP's 153 delta encoding. 155 CoAP servers can significantly benefit from in-place processing, as 156 they can create responses directly in the incoming IP buffer. When a 157 CoAP server only sends piggy-backed or non-confirmable responses, no 158 additional buffer is required in the application layer. This, 159 however, requires an elaborated timing so that no incoming data is 160 overwritten before it was processed. Note that an embedded OS 161 usually reuses a single buffer for incoming and outgoing IP packets. 162 So, either care or a buffer to save the incoming data has to be spent 163 in any case. 165 For clients, this is only an option for non-reliable requests that do 166 not need to be kept for retransmission. Using the IP also for 167 retransmissions would require to forbid any packet reception during 168 an open request, but could be applied in some cases. 170 Empty ACKs and RST messages can promptly be assembled and sent using 171 the IP buffer. The first few bytes are usually parsed into the local 172 data structure and can be overwritten without harm. 174 2.3. Retransmissions 176 CoAP's reliable transmissions require the before-mentioned 177 retransmission buffers. For clients, obviously the request has to be 178 stored, preferably already serialized. For servers, retransmissions 179 apply for confirmable separate responses and confirmable 180 notifications [I-D.ietf-core-observe]. As separate responses stem 181 from long-lasting resource handlers, the response should be stored 182 for retransmission instead of re-dispatching a stored request (which 183 would allow for updating the representation). For confirmable 184 notifications, please see Section 2.6, as simply storing the response 185 can break the concept of eventual consistency. 187 String payloads such as JSON require a buffer to print to. By 188 splitting the retransmission buffer into header and payload part, it 189 can be reused. First to generate the payload and then storing the 190 CoAP message by serializing into the same memory. Thus, providing a 191 retransmission for any message type can save the need for a separate 192 application buffer. This, however, requires an estimation about the 193 maximum expected header size to split the buffer and a memmove to 194 concatenate the two parts. 196 2.4. Separate Responses 198 Separate responses are required for long-lasting resource handlers 199 that are too expensive to continuously update in the background to 200 instantly answer from a fresh cache. If possible, those handlers 201 should be realized with split phase execution (e.g., enable a slow 202 sensor, return, and wait for a callback) to not fully block the 203 server during that time. A convenient mechanism to store required 204 data such as the client address and to automatically send the empty 205 ACK could be provided by the implementation. This avoids code 206 duplication when the server has multiple separate resource handlers. 208 2.5. Deduplication 210 Deduplication is heavy for Class 1 devices, as the number of peer 211 addresses can be vast. Servers should be kept stateless, i.e., the 212 REST API should be designed idempotent whenever possible. When this 213 is not the case, the resource handler could perform an optimized 214 deduplication by exploiting knowledge about the application. 215 Another, server-wide strategy is to only keep track of non-idempotent 216 requests. 218 2.6. Observing 220 At the server, the list of observers should be stored per resource to 221 only have a handle per observable resource in a superordinate list 222 instead of one resource handle per observer entry. Then for each 223 observer, at least address, port, token, and the last outgoing 224 message ID has to be stored. The latter is needed to match incoming 225 RST messages and cancel the observe relationship. 227 Besides the list of observers, it is best to have one retransmission 228 buffer per observable resource. Each notification is serialized once 229 into this buffer and only address, port, and token are changed when 230 iterating over the observer list (note that different token lengths 231 might require realignment). The advantage becomes clear for 232 confirmable notifications: Instead of one retransmission buffer per 233 observer, only one buffer and only individual retransmission counters 234 and timers in the list entry need to be stored. When the 235 notifications can be sent fast enough, even a single timer would 236 suffice. Furthermore, per-resource buffers simplify the update with 237 a new resource state during open deliveries. 239 2.7. Blockwise Transfers 241 Blockwise transfers have the main purpose of providing fragmentation 242 at the application layer, where partial information can be processed. 243 This is not possible at lower layers such as 6LoWPAN, as only 244 assembled packets can be passed up the stack. While 245 [I-D.ietf-core-block] also anticipates atomic handling of blocks, 246 i.e., only fully received CoAP messages, this is not possible on 247 Class 1 devices. 249 When receiving a blockwise transfer, each blocks is usually passed to 250 a handler function that for instance performs stream processing or 251 writes the blocks to external memory such as flash. Although there 252 are no restrictions in [I-D.ietf-core-block], it is beneficial for 253 Class 1 devices to only allow ordered transmission of blocks. 254 Otherwise on-the-fly processing would not be possible. 256 When sending a blockwise transfer, Class 1 devices usually do not 257 have sufficient memory to print the full message into a buffer, and 258 slice and send it in a second step. When transferring the CoRE Link 259 Format from /.well-known/core for instance, a generator function is 260 required that generates slices of a large string with a specific 261 offset length (a 'sonprintf()'). This functionality is required 262 recurrently and should be included in a library. 264 2.8. Developer API 266 Bringing a Web transfer protocol to constrained environments does not 267 only change the networking of the corresponding systems, but also the 268 way they should be programmed. A CoAP implementation should provide 269 a developer API similar to REST frameworks in traditional computing. 270 A server should not be created around an event loop with several 271 function calls, but rather by implementing handlers following the 272 resource abstraction. 274 So far, the following types of RESTful resources were identified: 276 NORMAL A normal resource defined by a static Uri-Path that is 277 associated with a resource handler function. Allowed methods 278 could already be filtered by the implementation based on flags. 279 This is the basis for all other resource types. 281 PARENT A parent resource manages several sub-resources by 282 programmatically evaluating the Uri-Path, which may be longer than 283 that of the parent resource. Defining a URI templates (see 284 [RFC6570]) would be a convenient way to pre-parse arguments given 285 in the Uri-Path. 287 PERIODIC A resource that has an additional handler function that is 288 triggered periodically by the CoAP implementation with a resource- 289 defined interval. It can be used to sample a sensor or perform 290 similar periodic updates. Usually, a periodic resource is 291 observable and sends the notifications in the periodic handler 292 function. These periodic tasks are quite common for sensor nodes, 293 thus it makes sense to provide this functionality in the CoAP 294 implementation and avoid redundant code in every resource. 296 EVENT An event resource is similar to an periodic resource, only 297 that the second handler is called by an irregular event such as a 298 button. 300 3. Low-power Wireless 302 The Internet of wireless things needs power-efficient protocols, but 303 existing protocols have typically been designed without explicit 304 power-efficiency. CoAP is optimized to run over low-power link 305 layers such IEEE 802.15.4, but in low-power wireless systems, 306 ultimate power-efficiency translates into the ability to keep the 307 radio off as much as possible, as the radio transceiver is typically 308 the most power-consuming component. This can be achieved in two 309 ways: So called radio duty cycling (RDC) aims to keep the radio off 310 as much as possible, but performs periodic channel checks to realize 311 a virtual always-on link. Sleepy nodes instead put the radio into 312 hibernation for a long period during which the node is fully 313 disconnected from the network. 315 3.1. Radio Duty Cycling 317 RDC can be achieved through a separate, independent layer between PHY 318 and MAC as depicted in Figure 1. The upper layers can remain more or 319 less untouched and only experience a higher latency, which might 320 require tweaking the timeout parameters. State-of-the-art RDC layers 321 can achieve an idle duty cycling way below 1% while checking the 322 channel several times per second. ContikiMAC for instance achieves a 323 0.3% cycle with a channel check rate of 4 Hz, which results in a 324 worst-case delay of 250ms per hop. While saving energy, ContikiMAC 325 also makes link-layer transmissions more robust due to its 326 retransmission policy. Please refer to [CONMAC] for details. 328 In general, RDC can be divided into two approaches: sender initiated 329 (e.g., ContikiMAC) and receiver initiated (e.g., A-MAC [AMAC]). In 330 the first approach, the sender enables the radio first and 331 continuously transmits its message in a strobe until a link-layer ACK 332 is received (note that for IEEE 802.15.4 transceivers, transmitting 333 consumes less energy than receiving). Receivers turn on their radio 334 only periodically to check for these announcements. If they sense a 335 busy channel, the radio is kept on to receive a potential message and 336 finally acknowledge it. In the other approach, the receiver 337 periodically announces that it will keep the radio on for receiving 338 for a while. The senders turns on its radio and listens for an 339 announcement of the recipient. When that is received, it transmits 340 the message (following the scheme of the above MAC layer of course, 341 while back-offs must match the awake time after announcements). 342 Which approach is optimal mainly depends on the communication pattern 343 of the application. Sender initiated RDCs are more efficient for 344 IEEE 802.15.4, but the strobes can congest a busy channel. 346 3.2. Sleepy Nodes 348 Going to sleep for a longer time is not transparent for the 349 application layer, as nodes need to re-synchronize and maybe re- 350 associate with the network. Several drafts in the IETF CoRE working 351 group cover this strategy for low-power wireless networking (cf. 352 [I-D.vial-core-mirror-proxy], [I-D.fossati-core-publish-option], 353 [I-D.fossati-core-monitor-option], and [I-D.rahman-core-sleepy]). 354 Such features will have to be integrated into the nodes CoAP 355 implementation as well as the back-end systems. In addition, 356 alternatives to standard diagnosis tools such as ICMP ping will have 357 to be provided, e.g., heartbeats by the application. 359 This strategy is particular useful for communications other than IEEE 360 802.15.4. Low-power Wi-Fi for instance is mainly based on long 361 sleeping periods with short wake-up cycles. Although the data rate 362 would be high enough for HTTP over TCP, low-power Wi-FI can greatly 363 benefit from CoAP and its shorter round trip times. For further 364 information about sleepy nodes based on low-power Wi-Fi see [LPWIFI]. 366 4. Security Considerations 368 T.B.D. 370 5. Informative References 372 [AMAC] Dutta, P., Dawson-Haggerty, S., Y., A., Liang, C., and A. 373 Terzis, "Designand Evaluation of a Versatile and Efficient 374 Receiver-Initiated Link Layer for Low-Power Wireless", 375 In Proceedings of the International Conference on Embedded 376 Networked Sensor Systems (SenSys 2010). Zurich, 377 Switzerland, November 2010. 379 [CONMAC] Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol", 380 SICS Technical Report T2011:13, ISSN 1100-3154, 381 December 2011. 383 [ERBIUM] Kovatsch, M., Duquennoy, S., and A. Dunkels, "A Low-Power 384 CoAP for Contiki", In Proceedings of the 8th IEEE 385 International Conference on Mobile Ad-hoc and Sensor 386 Systems (MASS 2011). Valencia, Spain, October 2011. 388 [I-D.fossati-core-monitor-option] 389 Fossati, T., Giacomin, P., and S. Loreto, "Monitor Option 390 for CoAP", draft-fossati-core-monitor-option-00 (work in 391 progress), July 2012. 393 [I-D.fossati-core-publish-option] 394 Fossati, T., Giacomin, P., and S. Loreto, "Publish Option 395 for CoAP", draft-fossati-core-publish-option-00 (work in 396 progress), July 2012. 398 [I-D.ietf-core-block] 399 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 400 draft-ietf-core-block-09 (work in progress), August 2012. 402 [I-D.ietf-core-coap] 403 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 404 "Constrained Application Protocol (CoAP)", 405 draft-ietf-core-coap-12 (work in progress), October 2012. 407 [I-D.ietf-core-observe] 408 Hartke, K., "Observing Resources in CoAP", 409 draft-ietf-core-observe-06 (work in progress), 410 September 2012. 412 [I-D.ietf-lwig-guidance] 413 Bormann, C., "Guidance for Light-Weight Implementations of 414 the Internet Protocol Suite", draft-ietf-lwig-guidance-02 415 (work in progress), August 2012. 417 [I-D.rahman-core-sleepy] 418 Rahman, A., "Enhanced Sleepy Node Support for CoAP", 419 draft-rahman-core-sleepy-00 (work in progress), July 2012. 421 [I-D.vial-core-mirror-proxy] 422 Vial, M., "CoRE Mirror Server", 423 draft-vial-core-mirror-proxy-01 (work in progress), 424 July 2012. 426 [LPWIFI] Ostermaier, B., Kovatsch, M., and S. Santini, "Connecting 427 Things to the Web using Programmable Low-power WiFi 428 Modules", In Proceedings of the 2nd International Workshop 429 on the Web of Things (WoT 2011). San Francisco, CA, USA, 430 June 2011. 432 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 433 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 434 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 435 Lossy Networks", RFC 6550, March 2012. 437 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 438 and D. Orchard, "URI Template", RFC 6570, March 2012. 440 Author's Address 442 Matthias Kovatsch 443 ETH Zurich 444 Universitaetstrasse 6 445 Zurich, CH-8092 446 Switzerland 448 Phone: +41 44 632 06 87 449 Email: kovatsch@inf.ethz.ch