Internet DRAFT - draft-shelby-core-coap-req
draft-shelby-core-coap-req
CoRE Z. Shelby
Internet-Draft Sensinode
Intended status: Informational M. Garrison Stuber
Expires: November 3, 2011 Itron
D. Sturek
Pacific Gas & Electric
B. Frank
Tridium, Inc
R. Kelsey
Ember
May 2, 2011
CoAP Requirements and Features
draft-shelby-core-coap-req-04
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 3, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Shelby, et al. Expires November 3, 2011 [Page 1]
Internet-Draft CoAP Requirements and Features May 2011
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 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 November 3, 2011 [Page 2]
Internet-Draft CoAP Requirements and Features May 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. CoAP Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Energy Applications . . . . . . . . . . . . . . . . . . . . 5
3.2. Building Automation . . . . . . . . . . . . . . . . . . . . 6
3.3. General M2M Applications . . . . . . . . . . . . . . . . . 7
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Shelby, et al. Expires November 3, 2011 [Page 3]
Internet-Draft CoAP Requirements and Features May 2011
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 (Feb 13, 2010 version), 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.
[charter]
Shelby, et al. Expires November 3, 2011 [Page 4]
Internet-Draft CoAP Requirements and Features May 2011
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], [I-D.gold-6lowapp-sensei]
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],
[I-D.martocci-6lowapp-building-applications],
[I-D.gold-6lowapp-sensei]
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], [I-D.gold-6lowapp-sensei]
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].
Shelby, et al. Expires November 3, 2011 [Page 5]
Internet-Draft CoAP Requirements and Features May 2011
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],
[I-D.martocci-6lowapp-building-applications]
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.
[I-D.sturek-6lowapp-smartenergy]
REQ13: A subset of Internet media types must be supported.
[I-D.sturek-6lowapp-smartenergy], [I-D.gold-6lowapp-sensei]
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
Shelby, et al. Expires November 3, 2011 [Page 6]
Internet-Draft CoAP Requirements and Features May 2011
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]. 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 November 3, 2011 [Page 7]
Internet-Draft CoAP Requirements and Features May 2011
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].
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 November 3, 2011 [Page 8]
Internet-Draft CoAP Requirements and Features May 2011
8.1. Normative References
[I-D.gold-6lowapp-sensei]
Gold, R., Krco, S., Gluhak, A., and Z. Shelby, "SENSEI
6lowapp Requirements", draft-gold-6lowapp-sensei-00 (work
in progress), October 2009.
[I-D.martocci-6lowapp-building-applications]
Martocci, J. and A. Schoofs, "Commercial Building
Applications Requirements",
draft-martocci-6lowapp-building-applications-00 (work in
progress), October 2009.
[I-D.sturek-6lowapp-smartenergy]
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
[I-D.bormann-6lowpan-6lowapp-problem]
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.
[I-D.moritz-6lowapp-dpws-enhancements]
Moritz, G., "DPWS for 6LoWPAN",
draft-moritz-6lowapp-dpws-enhancements-00 (work in
progress), December 2009.
Authors' Addresses
Zach Shelby
Sensinode
Kidekuja 2
Vuokatti 88600
FINLAND
Phone: +358407796297
Email: zach@sensinode.com
Shelby, et al. Expires November 3, 2011 [Page 9]
Internet-Draft CoAP Requirements and Features May 2011
Michael Garrison Stuber
Itron
2111 N. Molter Road
Liberty Lake, WA 99025
U.S.A.
Phone: +1.509.891.3441
Email: Michael.Stuber@itron.com
Don Sturek
Pacific Gas & Electric
77 Beale Street
San Francisco, CA
USA
Phone: +1-619-504-3615
Email: d.sturek@att.net
Brian Frank
Tridium, Inc
Richmond, VA
USA
Phone:
Email: brian.tridium@gmail.com
Richard Kelsey
Ember
47 Farnsworth Street
Boston, MA 02210
U.S.A.
Phone: +1.617.951.1201
Email: richard.kelsey@ember.com
Shelby, et al. Expires November 3, 2011 [Page 10]
