One document matched: draft-shelby-core-coap-req-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC2045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml">
<!ENTITY RFC2046 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2046.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY I-D.bormann-6lowpan-6lowapp-problem SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-6lowpan-6lowapp-problem.xml">
<!ENTITY I-D.shelby-6lowapp-encoding SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shelby-6lowapp-encoding.xml">
<!ENTITY I-D.frank-6lowapp-chopan SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.frank-6lowapp-chopan.xml">
<!ENTITY I-D.gold-6lowapp-sensei SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gold-6lowapp-sensei-00.xml">
<!ENTITY I-D.martocci-6lowapp-building-applications SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-martocci-6lowapp-building-applications-00.xml">
<!ENTITY I-D.sturek-6lowapp-smartenergy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-sturek-6lowapp-smartenergy-00.xml">
<!ENTITY I-D.moritz-6lowapp-dpws-enhancements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-moritz-6lowapp-dpws-enhancements-00.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" ipr="pre5378Trust200902" docName="draft-shelby-core-coap-req-02">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>CoAP Requirements and Features</title>
<author initials="Z" surname="Shelby" fullname="Zach Shelby">
<organization>
Sensinode
</organization>
<address>
<postal>
<street>Kidekuja 2</street>
<city>Vuokatti</city>
<code>88600</code>
<country>FINLAND</country>
</postal>
<phone>+358407796297</phone>
<email>zach@sensinode.com</email>
</address>
</author>
<author initials="M" surname="Garrison Stuber" fullname="Michael Garrison Stuber">
<organization>
Itron
</organization>
<address>
<postal>
<street>2111 N. Molter Road</street>
<city>Liberty Lake, WA</city>
<code>99025</code>
<country>U.S.A.</country>
</postal>
<phone>+1.509.891.3441</phone>
<email>Michael.Stuber@itron.com</email>
</address>
</author>
<author initials="D" surname="Sturek" fullname="Don Sturek">
<organization>
Pacific Gas & Electric
</organization>
<address>
<postal>
<street>77 Beale Street</street>
<city>San Francisco, CA</city>
<code></code>
<country>USA</country>
</postal>
<phone>+1-619-504-3615</phone>
<email>d.sturek@att.net</email>
</address>
</author>
<author initials="B" surname="Frank" fullname="Brian Frank">
<organization>
Tridium, Inc
</organization>
<address>
<postal>
<street></street>
<city>Richmond, VA</city>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>brian.tridium@gmail.com</email>
</address>
</author>
<author initials="R" surname="Kelsey" fullname="Richard Kelsey">
<organization>
Ember
</organization>
<address>
<postal>
<street>47 Farnsworth Street</street>
<city>Boston, MA</city>
<code>02210</code>
<country>U.S.A.</country>
</postal>
<phone>+1.617.951.1201</phone>
<email>richard.kelsey@ember.com</email>
</address>
</author>
<date year="2010"/>
<area>Internet</area>
<workgroup>CoRE</workgroup>
<keyword>Requirements, CoAP</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<t>
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.
</t>
<t>
This document first analyzes the requirements for CoAP from the proposed charter and related application requirement drafts in <xref target="requirements"/>. The applicability of these requirements to energy, building automation and general M2M applications is considered in <xref target="applicability"/>.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='requirements' title="CoAP Requirements">
<t>
The following requirements for CoAP have been identified in the proposed charter of the working group, in the 6lowapp problem statement <xref target="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:
<list style="format REQ%d:">
<t anchor="req-node">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], <xref target="I-D.sturek-6lowapp-smartenergy"/></t>
<t>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]</t>
<t>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], <xref target="I-D.sturek-6lowapp-smartenergy"/>, <xref target="I-D.gold-6lowapp-sensei"/></t>
<t>Protocol must support the caching of recent resource requests, along with caching subscriptions to sleeping nodes. [charter] </t>
<t>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], <xref target="I-D.sturek-6lowapp-smartenergy"/>, <xref target="I-D.martocci-6lowapp-building-applications"/>, <xref target="I-D.gold-6lowapp-sensei"/></t>
<t>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]</t>
<t>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], <xref target="I-D.sturek-6lowapp-smartenergy"/>, <xref target="I-D.gold-6lowapp-sensei"/></t>
<t>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]</t>
<t>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 <xref target="I-D.sturek-6lowapp-smartenergy"/>.</t>
<t>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], <xref target="I-D.sturek-6lowapp-smartenergy"/>, <xref target="I-D.martocci-6lowapp-building-applications"/></t>
<t>Reliability must be possible for unicast application layer messages over UDP <xref target="I-D.sturek-6lowapp-smartenergy"/>. </t>
<t>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. <xref target="I-D.sturek-6lowapp-smartenergy"/></t>
<t>A subset of Internet media types must be supported. <xref target="I-D.sturek-6lowapp-smartenergy"/>, <xref target="I-D.gold-6lowapp-sensei"/></t>
<t>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]</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='applicability' title="Applicability">
<t>
This sections looks at the applicability of the CoAP features for energy, building automation and other macine-to-machine (M2M) applications.
</t>
<section anchor='energy' title="Energy Applications">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor='ba' title="Building Automation">
<t>
Building automation applications were analyzed in detail including use cases in
<xref target="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 <xref target="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.
</t>
</section>
<section anchor='m2m' title="General M2M Applications">
<t>
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 <xref target="I-D.moritz-6lowapp-dpws-enhancements"/>. </t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Conclusions">
<t>
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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Security Considerations">
<t>
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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA Considerations">
<t>
This draft requires no IANA consideration.
</t>
</section>
<!------------------------------------------------------>
<!-- SECTION: ACKNOWLEDGMENTS -->
<!------------------------------------------------------>
<section title="Acknowledgments">
<t>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.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&I-D.martocci-6lowapp-building-applications;
&I-D.sturek-6lowapp-smartenergy;
&I-D.gold-6lowapp-sensei;
</references>
<references title='Informative References'>
&I-D.bormann-6lowpan-6lowapp-problem;
&I-D.moritz-6lowapp-dpws-enhancements;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:48:33 |