CoAP Requirements and Features
draft-shelby-core-coap-req-01

Abstract

This document considers the requirements for the design of the Constrained Application Protocol (CoAP). The goal of the document is to provide a basis for protocol design and related discussion.

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 October 22, 2010.

Copyright Notice

Copyright (c) 2010 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 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.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction
2.  CoAP Requirements
3.  Applicability
    3.1.  Energy Applications
    3.2.  Building Automation
    3.3.  General M2M Applications
4.  Conclusions
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgments
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

The use of web services on the Internet has become ubiquitous in most applications, and depends on the fundamental Representational State Transfer (REST) architecture of the web. The proposed Constrained RESTful Environments (CoRE) working group aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g. 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). One of the main goals of CoRE is to design a generic RESTful protocol for the special requirements of this constrained environment, especially considering energy and building automation applications. The result of this work should be a Constrained Application Protocol (CoAP) which easily traslates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity.

This document first analyzes the requirements for CoAP from the proposed charter and related application requirement drafts in Section 2 (CoAP Requirements). The applicability of these requirements to energy, building automation and general M2M applications is considered in Section 3 (Applicability).

2.  CoAP Requirements

The following requirements for CoAP have been identified in the proposed charter of the working group (Feb 13, 2010 version), in the 6lowapp problem statement [I‑D.bormann‑6lowpan‑6lowapp‑problem] (Bormann, C., Sturek, D., and Z. Shelby, “6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols,” July 2009.), or in the application specific requirement documents. This section is not meant to introduce new requirements, only to summarize the requirements from other sources. The requirements relevant to CoAP can be summarizes as follows:

REQ1:

CoRE solutions must be of appropriate complexity for use by nodes have limited code size and limited RAM (e.g. microcontrollers used in low-cost wireless devices typically have on the order of 64-256K of flash and 4-12K of RAM). [charter], [I‑D.sturek‑6lowapp‑smartenergy] (Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. Ashton, “Smart Energy Requiements for 6LowApp,” October 2009.)

REQ2:

Protocol overhead and performance must be optimized for constrained networks, which may exhibit extremely limited throughput and a high degree of packet loss. For example, multihop 6LoWPAN networks often exhibit application throughput on the order of tens of kbits/s with a typical payload size of 70-90 octets after transport layer headers. [charter]

REQ3:

The ability to deal with sleeping nodes. Devices may be powered off at any point in time but periodically "wake up" for brief periods of time. [charter], [I‑D.sturek‑6lowapp‑smartenergy] (Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. Ashton, “Smart Energy Requiements for 6LowApp,” October 2009.), [I‑D.gold‑6lowapp‑sensei] (Gold, R., Krco, S., Gluhak, A., and Z. Shelby, “SENSEI 6lowapp Requirements,” October 2009.)

REQ4:

Protocol must support the caching of recent resource requests, along with caching subscriptions to sleeping nodes. [charter]

REQ5:

Must support the manipulation of simple resources on constrained nodes and networks. The architecture requires push, pull and a notify approach to manipulating resources. CoAP will be able to create, read, update and delete a Resource on a Device. [charter], [I‑D.sturek‑6lowapp‑smartenergy] (Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. Ashton, “Smart Energy Requiements for 6LowApp,” October 2009.), [I‑D.martocci‑6lowapp‑building‑applications] (Martocci, J. and A. Schoofs, “Commercial Building Applications Requirements,” October 2009.), [I‑D.gold‑6lowapp‑sensei] (Gold, R., Krco, S., Gluhak, A., and Z. Shelby, “SENSEI 6lowapp Requirements,” October 2009.)

REQ6:

The ability to allow a Device to publish a value or event to another Device that has subscribed to be notified of changes, as well as the way for a Device to subscribe to receive publishes from another Device. [charter]

REQ7:

Must define a mapping from CoAP to a HTTP REST API; this mapping will not depend on a specific application and must be as transparent as possible using standard protocol response and error codes where possible. [charter], [I‑D.sturek‑6lowapp‑smartenergy] (Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. Ashton, “Smart Energy Requiements for 6LowApp,” October 2009.), [I‑D.gold‑6lowapp‑sensei] (Gold, R., Krco, S., Gluhak, A., and Z. Shelby, “SENSEI 6lowapp Requirements,” October 2009.)

REQ8:

A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. [charter]

REQ9:

CoAP will support a non-reliable IP multicast message to be sent to a group of Devices to manipulate a resource on all the Devices simultaneously [charter]. The use of multicast to query and advertise descriptions must be supported, along with the support of unicast responses [I‑D.sturek‑6lowapp‑smartenergy] (Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. Ashton, “Smart Energy Requiements for 6LowApp,” October 2009.).

REQ10:

The core CoAP functionality must operate well over UDP and UDP must be implemented on CoAP Devices. There may be optional functions in CoAP (e.g. delivery of larger chunks of data) which if implemented are implemented over TCP. [charter], [I‑D.sturek‑6lowapp‑smartenergy] (Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. Ashton, “Smart Energy Requiements for 6LowApp,” October 2009.), [I‑D.martocci‑6lowapp‑building‑applications] (Martocci, J. and A. Schoofs, “Commercial Building Applications Requirements,” October 2009.)

REQ11:

Reliability must be possible for unicast application layer messages over UDP [I‑D.sturek‑6lowapp‑smartenergy] (Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. Ashton, “Smart Energy Requiements for 6LowApp,” October 2009.).

REQ12:

Latency times should be mimimized of the Home Area Network (HAN), and ideally a typical exchange should consist of just a single request/response exchange. [I‑D.sturek‑6lowapp‑smartenergy] (Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. Ashton, “Smart Energy Requiements for 6LowApp,” October 2009.)

REQ13:

A subset of Internet media types must be supported. [I‑D.sturek‑6lowapp‑smartenergy] (Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S. Ashton, “Smart Energy Requiements for 6LowApp,” October 2009.), [I‑D.gold‑6lowapp‑sensei] (Gold, R., Krco, S., Gluhak, A., and Z. Shelby, “SENSEI 6lowapp Requirements,” October 2009.)

REQ14:

Consider operational and manageability aspects of the protocol and at a minimum provide a way to tell if a Device is powered on or not. [charter]

3.  Applicability

This sections looks at the applicability of the CoAP features for energy, building automation and other macine-to-machine (M2M) applications.

3.1.  Energy Applications

Rising energy prices, concerns about global warming and energy resource depletion, and societal interest in more ecologically friendly living have resulted in government mandates for Smart Energy solutions. In a Smart Energy environment consumers of energy have direct, immediate access to information about their consumption, and are able to take action based on that information. Smart Energy systems also allow device to device communication to optimize the transport, reliability, and safety of energy delivery systems. While often Smart Energy solutions are electricity-centric, i.e. Smart Grid, gas and water are also subject to the same pressures, and can benefit from the same technology.

Smart Energy Transactions typically include the exchange of current consumption information, text messages from providers to consumers, and control signals requesting a reduction in consumption. Advanced features such as billing information, energy prepayment transactions, management of distributed energy resources (e.g. generators and photo-voltaics), and management of electric vehicles are also being developed.

Smart Energy benefits from Metcalfe's Law. The more devices that are part of a smart energy network within the home or on the grid, the more valuable it becomes. Showing a consumer how much energy they are using is useful. Combining that with specific information about their major appliances, and enabling them to adjust their consumption based on current pricing and system demand is much much more powerful. To do this however requires a system that is resillient, low cost, and easy to install. In many areas this is being done with systems built around IEEE 802.15.4 radios. In the United States, there are over 30 million electric meters that will be deployed with these radios. These radios will be combined to form a mesh network, enabling Smart Energy communication within the home. The maximum packet size for IEEE 802.15.4 is only 127 bytes. Additionally, there is the well known issue of how TCP manages congestion working sub-optimally over wireless networks. IEEE 802.15.4 is ideal for these applications because of its low cost and its support for battery powered devices; however, it is not as well suited for heavier protocols like HTTP. These technical issues with IEEE 802.15.4 networks combined with a desire to facilitate broader compatibility, makes a protocol like CoAP desireable. Its REST architecture will allow seamless compatibility with the rest of the Internet, allowing it to be easily integrated with web browsers and web-based service providers, while at the same time being appropriately sized for the low-cost networks necessary for its success.

3.2.  Building Automation

Building automation applications were analyzed in detail including use cases in [I‑D.martocci‑6lowapp‑building‑applications] (Martocci, J. and A. Schoofs, “Commercial Building Applications Requirements,” October 2009.). Although many of the embedded control solutions for building automation make use of industry-specific application protocols like BACnet over IP, there is a growing use of web services in building monitoring, remote control and IT integration. The OASIS oBIX standard [ref] is one example of the use of web services for the monitoring and interconnection of heterogeneous building systems. Several of the CoAP requirements have been taken from [I‑D.martocci‑6lowapp‑building‑applications] (Martocci, J. and A. Schoofs, “Commercial Building Applications Requirements,” October 2009.). The resulting features should allow for peer-to-peer interactions as well as node-server request/response and push interfactions for monitoring and some control purposes. For building automation control with very strict timing requirements using e.g. multicast, further features may be required on top of CoAP.

3.3.  General M2M Applications

CoAP provides a natural extension of the REST architecture into the domain of constrained nodes and networks, aiming at requirements from automation applications in energy and building automation. A very wide range of machine-to-machine (M2M) applications have similar requirements to those considered in this document, and thus it is foreseen that CoAP may be widely applied in the industry. One standardization group considering a general M2M architecture and API is the ETSI M2M TC, which considers a wide range of applications including energy. Another group developing solutions for general embedded device control is the OASIS Device Proile Web Services (DPWS) group. The consideration of DPWS over 6LoWPAN is available in [I‑D.moritz‑6lowapp‑dpws‑enhancements] (Moritz, G., “DPWS for 6LoWPAN,” December 2009.).

4.  Conclusions

This document analyzed the requirements associated with the design of the foreseen Constrained Application Protocol (CoAP). The identified requirements of CoAP are considered for energy, building automation and M2M applications. This document is meant to serve as a basis for the design of the CoAP protocol and relevant discussion.

5.  Security Considerations

The CoAP protocol will be designed for use with e.g. (D)TLS or object security. A protocol design should consider how integration with these security methods will be done, how to secure the CoAP header and other implications.

6.  IANA Considerations

This draft requires no IANA consideration.

7.  Acknowledgments

Thanks to Cullen Jennings, Guido Moritz, Peter Van Der Stok, Adriano Pezzuto, Lisa Dussealt, Gilbert Clark, Salvatore Loreto, Alexey Melnikov and Bob Dolin for helpful comments and discussions.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses