CoRE                                                           Z. Shelby
Internet-Draft                                                 Sensinode
Intended status: Informational                        M. Garrison Stuber
Expires: April 21, 2011                                            Itron
                                                               D. Sturek
                                                  Pacific Gas & Electric
                                                                B. Frank
                                                            Tridium, Inc
                                                               R. Kelsey
                                                        October 18, 2010

                     CoAP Requirements and Features


   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

   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 21, 2011.

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
   ( in effect on the date of
   publication of this document.  Please review these documents

Shelby, et al.           Expires April 21, 2011                 [Page 1]

Internet-Draft       CoAP Requirements and Features         October 2010

   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.

Shelby, et al.           Expires April 21, 2011                 [Page 2]

Internet-Draft       CoAP Requirements and Features         October 2010

Table of Contents

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

Shelby, et al.           Expires April 21, 2011                 [Page 3]

Internet-Draft       CoAP Requirements and Features         October 2010

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.  The applicability of these requirements to energy,
   building automation and general M2M applications is considered in
   Section 3.

2.  CoAP Requirements

   The following requirements for CoAP have been identified in the
   proposed charter of the working group, in the 6lowapp problem
   statement [I-D.bormann-6lowpan-6lowapp-problem], 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]

   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.

Shelby, et al.           Expires April 21, 2011                 [Page 4]

Internet-Draft       CoAP Requirements and Features         October 2010

   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], []

   REQ4:   Protocol must support the caching of recent resource
           requests, along with caching subscriptions to sleeping nodes.

   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],

   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], []

   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

Shelby, et al.           Expires April 21, 2011                 [Page 5]

Internet-Draft       CoAP Requirements and Features         October 2010

   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],

   REQ11:  Reliability must be possible for unicast application layer
           messages over UDP [I-D.sturek-6lowapp-smartenergy].

   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.

   REQ13:  A subset of Internet media types must be supported.
           [I-D.sturek-6lowapp-smartenergy], []

   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)

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

Shelby, et al.           Expires April 21, 2011                 [Page 6]

Internet-Draft       CoAP Requirements and Features         October 2010

   photo-voltaics), and management of electric vehicles are also being

   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].  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].  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.

Shelby, et al.           Expires April 21, 2011                 [Page 7]

Internet-Draft       CoAP Requirements and Features         October 2010

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

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

Shelby, et al.           Expires April 21, 2011                 [Page 8]

Internet-Draft       CoAP Requirements and Features         October 2010

8.1.  Normative References

              Gold, R., Krco, S., Gluhak, A., and Z. Shelby, "SENSEI
              6lowapp Requirements", draft-gold-6lowapp-sensei-00 (work
              in progress), October 2009.

              Martocci, J. and A. Schoofs, "Commercial Building
              Applications Requirements",
              draft-martocci-6lowapp-building-applications-00 (work in
              progress), October 2009.

              Sturek, D., Shelby, Z., Lohman, D., Stuber, M., and S.
              Ashton, "Smart Energy Requiements for 6LowApp",
              draft-sturek-6lowapp-smartenergy-00 (work in progress),
              October 2009.

8.2.  Informative References

              Bormann, C., Sturek, D., and Z. Shelby, "6LowApp: Problem
              Statement for 6LoWPAN and LLN Application Protocols",
              draft-bormann-6lowpan-6lowapp-problem-01 (work in
              progress), July 2009.

              Moritz, G., "DPWS for 6LoWPAN",
              draft-moritz-6lowapp-dpws-enhancements-00 (work in
              progress), December 2009.

Authors' Addresses

   Zach Shelby
   Kidekuja 2
   Vuokatti  88600

   Phone: +358407796297

Shelby, et al.           Expires April 21, 2011                 [Page 9]

Internet-Draft       CoAP Requirements and Features         October 2010

   Michael Garrison Stuber
   2111 N. Molter Road
   Liberty Lake, WA  99025

   Phone: +1.509.891.3441

   Don Sturek
   Pacific Gas & Electric
   77 Beale Street
   San Francisco, CA

   Phone: +1-619-504-3615

   Brian Frank
   Tridium, Inc
   Richmond, VA


   Richard Kelsey
   47 Farnsworth Street
   Boston, MA  02210

   Phone: +1.617.951.1201

Shelby, et al.           Expires April 21, 2011                [Page 10]