Light-Weight Implementation Guidance M. Kovatsch Internet-Draft ETH Zurich Intended status: Informational October 15, 2012 Expires: April 18, 2013 Implementing CoAP for Class 1 Devices draft-kovatsch-lwig-class1-coap-00 Abstract The Constrained Application Protocol (CoAP) is designed for resource- constrained nodes and networks, e.g., sensor nodes in low-power lossy networks (LLNs). Still, to implement this Internet protocol on Class 1 devices, i.e., ~10KiB of RAM and ~100KiB of ROM, light-weight implementation techniques are necessary. This document provides the lessons learned from implementing CoAP for Contiki, an operating system for tiny, battery-operated networked embedded systems. The information may become part of the Light-Weight Implementation Guidance document planned by the IETF working group LWIG. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Kovatsch Expires April 18, 2013 [Page 1] Internet-Draft Implementing CoAP for Class 1 Devices October 2012 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Implementing CoAP . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Memory Management . . . . . . . . . . . . . . . . . . . . 4 2.2. Message Buffers . . . . . . . . . . . . . . . . . . . . . 4 2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 5 2.4. Separate Responses . . . . . . . . . . . . . . . . . . . . 5 2.5. Deduplication . . . . . . . . . . . . . . . . . . . . . . 5 2.6. Observing . . . . . . . . . . . . . . . . . . . . . . . . 6 2.7. Blockwise Transfers . . . . . . . . . . . . . . . . . . . 6 2.8. Developer API . . . . . . . . . . . . . . . . . . . . . . 7 3. Low-power Wireless . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Radio Duty Cycling . . . . . . . . . . . . . . . . . . . . 8 3.2. Sleepy Nodes . . . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Informative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Kovatsch Expires April 18, 2013 [Page 2] Internet-Draft Implementing CoAP for Class 1 Devices October 2012 1. Introduction The Internet protocol suite is a suitable solution to realize an Internet of Things (IoT), a network of tiny networked embedded devices that create a link to the physical world. The narrow waist of IP can be used to directly access sensor readings throughout a sustainable city, acquire the necessary information for the smart grid, or control smart homes, buildings, and factories---seamlessly from the existing IT infrastructure. The layered architecture helps to manage the complexity, as multiple aspects such as routing over lossy links, link layer adaption, and low-power communication have to be addressed. Nonetheless, attention has to be given to achieve light-weight implementations that can run on resource-constrained devices such as sensor nodes with only microcontroller units (MCUs), ~10KiB of RAM, and ~100KiB of ROM [I-D.ietf-lwig-guidance]. Figure 1 depicts a typical stack configuration for such Class 1 devices. This document discusses a light-weight implementation of CoAP at the application layer in Section 2 and techniques for energy-efficiency such as radio duty cycling in Section 3. +--------------------+--------------------------+ | Layer | Protocol | +--------------------+--------------------------+ | Application | CoAP | | Transport | UDP | | Network | IPv6 / RPL | | Adaptation | 6LoWPAN | | MAC | CSMA / link-layer bursts | | Radio Duty Cycling | ContikiMAC | | Physical | IEEE 802.15.4 | +--------------------+--------------------------+ A typical stack configuration for Class 1 devices. Figure 1 2. Implementing CoAP The following experience stems from implementing CoAP for the Contiki operating system [ERBIUM], but is generalized for any embedded OS. The information is not meant to be a final solution, but a first step towards a Light-Weight Implementation Guidance contribution. Alternatives will be incorporated throughout the merging process. The document assumes detailed knowledge of CoAP, its message format and interaction model. For more information, please refer to to [I-D.ietf-core-coap], [I-D.ietf-core-block], and [I-D.ietf-core-observe]. Kovatsch Expires April 18, 2013 [Page 3] Internet-Draft Implementing CoAP for Class 1 Devices October 2012 2.1. Memory Management For embedded systems, it is common practice to allocate memory statically to ensure stable behavior, as no memory management unit (MMU) or other abstractions are available. For a CoAP node, the two key parameters are the number of (re)transmission buffers and the maximum message size that must be supported by each buffer. It is common practice to set the maximum message size far below the 1280- byte MTU of 6LoWPAN to allow more than one open confirmable transmissions at a time (in particular for observe notifications). Note that implementations on constrained platforms often not even support the full MTU. Larger messages must then use blockwise transfers [I-D.ietf-core-block], while a good trade-off between 6LoWPAN fragmentation and CoAP header overhead must be found. Usually the amount of available free RAM dominates this decision, on current platforms ending up at a maximum message size of 128 or 256 bytes plus maximum estimated header size. 2.2. Message Buffers Class 1 devices usually run an OS or event loop system with cooperative multi-threading. This allows to optimize memory usage through in-place processing and reuse of buffers. Incoming payload and byte strings of the header can be directly accessed in the IP buffer, which is provided by the OS, using pointers. For numeric options, there are two alternatives: Either process the header on the fly when an option is accessed or initially parse/allocate all values into a local data structure. Although the latter choice requires an additional amount of memory, it is preferable. First, local processing anyway requires integers in host byte order and stored in a variable of corresponding type. Second, on-the-fly processing might force developers to set options for outgoing messages in a specific order or cause extensive memmove operations due to CoAP's delta encoding. CoAP servers can significantly benefit from in-place processing, as they can create responses directly in the incoming IP buffer. When a CoAP server only sends piggy-backed or non-confirmable responses, no additional buffer is required in the application layer. This, however, requires an elaborated timing so that no incoming data is overwritten before it was processed. Note that an embedded OS usually reuses a single buffer for incoming and outgoing IP packets. So, either care or a buffer to save the incoming data has to be spent in any case. For clients, this is only an option for non-reliable requests that do not need to be kept for retransmission. Using the IP also for retransmissions would require to forbid any packet reception during Kovatsch Expires April 18, 2013 [Page 4] Internet-Draft Implementing CoAP for Class 1 Devices October 2012 an open request, but could be applied in some cases. Empty ACKs and RST messages can promptly be assembled and sent using the IP buffer. The first few bytes are usually parsed into the local data structure and can be overwritten without harm. 2.3. Retransmissions CoAP's reliable transmissions require the before-mentioned retransmission buffers. For clients, obviously the request has to be stored, preferably already serialized. For servers, retransmissions apply for confirmable separate responses and confirmable notifications [I-D.ietf-core-observe]. As separate responses stem from long-lasting resource handlers, the response should be stored for retransmission instead of re-dispatching a stored request (which would allow for updating the representation). For confirmable notifications, please see Section 2.6, as simply storing the response can break the concept of eventual consistency. String payloads such as JSON require a buffer to print to. By splitting the retransmission buffer into header and payload part, it can be reused. First to generate the payload and then storing the CoAP message by serializing into the same memory. Thus, providing a retransmission for any message type can save the need for a separate application buffer. This, however, requires an estimation about the maximum expected header size to split the buffer and a memmove to concatenate the two parts. 2.4. Separate Responses Separate responses are required for long-lasting resource handlers that are too expensive to continuously update in the background to instantly answer from a fresh cache. If possible, those handlers should be realized with split phase execution (e.g., enable a slow sensor, return, and wait for a callback) to not fully block the server during that time. A convenient mechanism to store required data such as the client address and to automatically send the empty ACK could be provided by the implementation. This avoids code duplication when the server has multiple separate resource handlers. 2.5. Deduplication Deduplication is heavy for Class 1 devices, as the number of peer addresses can be vast. Servers should be kept stateless, i.e., the REST API should be designed idempotent whenever possible. When this is not the case, the resource handler could perform an optimized deduplication by exploiting knowledge about the application. Another, server-wide strategy is to only keep track of non-idempotent Kovatsch Expires April 18, 2013 [Page 5] Internet-Draft Implementing CoAP for Class 1 Devices October 2012 requests. 2.6. Observing At the server, the list of observers should be stored per resource to only have a handle per observable resource in a superordinate list instead of one resource handle per observer entry. Then for each observer, at least address, port, token, and the last outgoing message ID has to be stored. The latter is needed to match incoming RST messages and cancel the observe relationship. Besides the list of observers, it is best to have one retransmission buffer per observable resource. Each notification is serialized once into this buffer and only address, port, and token are changed when iterating over the observer list (note that different token lengths might require realignment). The advantage becomes clear for confirmable notifications: Instead of one retransmission buffer per observer, only one buffer and only individual retransmission counters and timers in the list entry need to be stored. When the notifications can be sent fast enough, even a single timer would suffice. Furthermore, per-resource buffers simplify the update with a new resource state during open deliveries. 2.7. Blockwise Transfers Blockwise transfers have the main purpose of providing fragmentation at the application layer, where partial information can be processed. This is not possible at lower layers such as 6LoWPAN, as only assembled packets can be passed up the stack. While [I-D.ietf-core-block] also anticipates atomic handling of blocks, i.e., only fully received CoAP messages, this is not possible on Class 1 devices. When receiving a blockwise transfer, each blocks is usually passed to a handler function that for instance performs stream processing or writes the blocks to external memory such as flash. Although there are no restrictions in [I-D.ietf-core-block], it is beneficial for Class 1 devices to only allow ordered transmission of blocks. Otherwise on-the-fly processing would not be possible. When sending a blockwise transfer, Class 1 devices usually do not have sufficient memory to print the full message into a buffer, and slice and send it in a second step. When transferring the CoRE Link Format from /.well-known/core for instance, a generator function is required that generates slices of a large string with a specific offset length (a 'sonprintf()'). This functionality is required recurrently and should be included in a library. Kovatsch Expires April 18, 2013 [Page 6] Internet-Draft Implementing CoAP for Class 1 Devices October 2012 2.8. Developer API Bringing a Web transfer protocol to constrained environments does not only change the networking of the corresponding systems, but also the way they should be programmed. A CoAP implementation should provide a developer API similar to REST frameworks in traditional computing. A server should not be created around an event loop with several function calls, but rather by implementing handlers following the resource abstraction. So far, the following types of RESTful resources were identified: NORMAL A normal resource defined by a static Uri-Path that is associated with a resource handler function. Allowed methods could already be filtered by the implementation based on flags. This is the basis for all other resource types. PARENT A parent resource manages several sub-resources by programmatically evaluating the Uri-Path, which may be longer than that of the parent resource. Defining a URI templates (see [RFC6570]) would be a convenient way to pre-parse arguments given in the Uri-Path. PERIODIC A resource that has an additional handler function that is triggered periodically by the CoAP implementation with a resource- defined interval. It can be used to sample a sensor or perform similar periodic updates. Usually, a periodic resource is observable and sends the notifications in the periodic handler function. These periodic tasks are quite common for sensor nodes, thus it makes sense to provide this functionality in the CoAP implementation and avoid redundant code in every resource. EVENT An event resource is similar to an periodic resource, only that the second handler is called by an irregular event such as a button. 3. Low-power Wireless The Internet of wireless things needs power-efficient protocols, but existing protocols have typically been designed without explicit power-efficiency. CoAP is optimized to run over low-power link layers such IEEE 802.15.4, but in low-power wireless systems, ultimate power-efficiency translates into the ability to keep the radio off as much as possible, as the radio transceiver is typically the most power-consuming component. This can be achieved in two ways: So called radio duty cycling (RDC) aims to keep the radio off as much as possible, but performs periodic channel checks to realize Kovatsch Expires April 18, 2013 [Page 7] Internet-Draft Implementing CoAP for Class 1 Devices October 2012 a virtual always-on link. Sleepy nodes instead put the radio into hibernation for a long period during which the node is fully disconnected from the network. 3.1. Radio Duty Cycling RDC can be achieved through a separate, independent layer between PHY and MAC as depicted in Figure 1. The upper layers can remain more or less untouched and only experience a higher latency, which might require tweaking the timeout parameters. State-of-the-art RDC layers can achieve an idle duty cycling way below 1% while checking the channel several times per second. ContikiMAC for instance achieves a 0.3% cycle with a channel check rate of 4 Hz, which results in a worst-case delay of 250ms per hop. While saving energy, ContikiMAC also makes link-layer transmissions more robust due to its retransmission policy. Please refer to [CONMAC] for details. In general, RDC can be divided into two approaches: sender initiated (e.g., ContikiMAC) and receiver initiated (e.g., A-MAC [AMAC]). In the first approach, the sender enables the radio first and continuously transmits its message in a strobe until a link-layer ACK is received (note that for IEEE 802.15.4 transceivers, transmitting consumes less energy than receiving). Receivers turn on their radio only periodically to check for these announcements. If they sense a busy channel, the radio is kept on to receive a potential message and finally acknowledge it. In the other approach, the receiver periodically announces that it will keep the radio on for receiving for a while. The senders turns on its radio and listens for an announcement of the recipient. When that is received, it transmits the message (following the scheme of the above MAC layer of course, while back-offs must match the awake time after announcements). Which approach is optimal mainly depends on the communication pattern of the application. Sender initiated RDCs are more efficient for IEEE 802.15.4, but the strobes can congest a busy channel. 3.2. Sleepy Nodes Going to sleep for a longer time is not transparent for the application layer, as nodes need to re-synchronize and maybe re- associate with the network. Several drafts in the IETF CoRE working group cover this strategy for low-power wireless networking (cf. [I-D.vial-core-mirror-proxy], [I-D.fossati-core-publish-option], [I-D.fossati-core-monitor-option], and [I-D.rahman-core-sleepy]). Such features will have to be integrated into the nodes CoAP implementation as well as the back-end systems. In addition, alternatives to standard diagnosis tools such as ICMP ping will have to be provided, e.g., heartbeats by the application. Kovatsch Expires April 18, 2013 [Page 8] Internet-Draft Implementing CoAP for Class 1 Devices October 2012 This strategy is particular useful for communications other than IEEE 802.15.4. Low-power Wi-Fi for instance is mainly based on long sleeping periods with short wake-up cycles. Although the data rate would be high enough for HTTP over TCP, low-power Wi-FI can greatly benefit from CoAP and its shorter round trip times. For further information about sleepy nodes based on low-power Wi-Fi see [LPWIFI]. 4. Security Considerations T.B.D. 5. Informative References [AMAC] Dutta, P., Dawson-Haggerty, S., Y., A., Liang, C., and A. Terzis, "Designand Evaluation of a Versatile and Efficient Receiver-Initiated Link Layer for Low-Power Wireless", In Proceedings of the International Conference on Embedded Networked Sensor Systems (SenSys 2010). Zurich, Switzerland, November 2010. [CONMAC] Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol", SICS Technical Report T2011:13, ISSN 1100-3154, December 2011. [ERBIUM] Kovatsch, M., Duquennoy, S., and A. Dunkels, "A Low-Power CoAP for Contiki", In Proceedings of the 8th IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2011). Valencia, Spain, October 2011. [I-D.fossati-core-monitor-option] Fossati, T., Giacomin, P., and S. Loreto, "Monitor Option for CoAP", draft-fossati-core-monitor-option-00 (work in progress), July 2012. [I-D.fossati-core-publish-option] Fossati, T., Giacomin, P., and S. Loreto, "Publish Option for CoAP", draft-fossati-core-publish-option-00 (work in progress), July 2012. [I-D.ietf-core-block] Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", draft-ietf-core-block-09 (work in progress), August 2012. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", Kovatsch Expires April 18, 2013 [Page 9] Internet-Draft Implementing CoAP for Class 1 Devices October 2012 draft-ietf-core-coap-12 (work in progress), October 2012. [I-D.ietf-core-observe] Hartke, K., "Observing Resources in CoAP", draft-ietf-core-observe-06 (work in progress), September 2012. [I-D.ietf-lwig-guidance] Bormann, C., "Guidance for Light-Weight Implementations of the Internet Protocol Suite", draft-ietf-lwig-guidance-02 (work in progress), August 2012. [I-D.rahman-core-sleepy] Rahman, A., "Enhanced Sleepy Node Support for CoAP", draft-rahman-core-sleepy-00 (work in progress), July 2012. [I-D.vial-core-mirror-proxy] Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-proxy-01 (work in progress), July 2012. [LPWIFI] Ostermaier, B., Kovatsch, M., and S. Santini, "Connecting Things to the Web using Programmable Low-power WiFi Modules", In Proceedings of the 2nd International Workshop on the Web of Things (WoT 2011). San Francisco, CA, USA, June 2011. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, March 2012. Author's Address Matthias Kovatsch ETH Zurich Universitaetstrasse 6 Zurich, CH-8092 Switzerland Phone: +41 44 632 06 87 Email: kovatsch@inf.ethz.ch Kovatsch Expires April 18, 2013 [Page 10]