One document matched: draft-shelby-core-coap-req-00.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 "reference.RFC.0792.xml">
<!ENTITY RFC4944 SYSTEM "reference.RFC.4944.xml">
<!ENTITY RFC2045 SYSTEM "reference.RFC.2045.xml">
<!ENTITY RFC2046 SYSTEM "reference.RFC.2046.xml">
<!ENTITY RFC3986 SYSTEM "reference.RFC.3986.xml">
<!ENTITY I-D.bormann-6lowpan-6lowapp-problem SYSTEM "reference.I-D.bormann-6lowpan-6lowapp-problem.xml">
<!ENTITY I-D.shelby-6lowapp-encoding SYSTEM "reference.I-D.shelby-6lowapp-encoding.xml">
<!ENTITY I-D.frank-6lowapp-chopan SYSTEM "reference.I-D.frank-6lowapp-chopan.xml">
<!ENTITY I-D.gold-6lowapp-sensei SYSTEM "reference.I-D.draft-gold-6lowapp-sensei-00.xml">
<!ENTITY I-D.martocci-6lowapp-building-applications SYSTEM "reference.I-D.draft-martocci-6lowapp-building-applications-00.xml">
<!ENTITY I-D.sturek-6lowapp-smartenergy SYSTEM "reference.I-D.draft-sturek-6lowapp-smartenergy-00.xml">
<!ENTITY I-D.moritz-6lowapp-dpws-enhancements SYSTEM "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-00">
<?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 and resulting features needed for the design of the Constrained Application Protocol (CoAP). Starting from requirements for energy and building automation applications, the basic features are identified along with an analysis of possible realizations. 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 key features needed for the CoAP protocol are then identified in <xref target="coap"/>. Possible ways of realizing each feature are considered and recommendations made where possible. Finally, the applicability of these features to energy, building automation and general M2M applications is considered in <xref target="applicability"/>.
</t>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='requirements' title="CoAP Requirements">
<t>
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 <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 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 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 and a single response message. <xref target="I-D.sturek-6lowapp-smartenergy"/></t>
<t>Internet media type and transfer encoding type support. <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>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='coap' title="CoAP Feature Analysis">
<t>
This section introduces the minimum set of features needed to realize CoAP, and looks at the possible options for realizing them. These features are considered in light of the requirements listed in <xref target="requirements"/>. The goal is to consider the cross-dependencies, benefits and drawbacks of alternatives for realizing CoAP and to narrow down the options where obvious.
</t>
<section anchor='header' title="Compact Header">
<t>
There is a requirement for a header overhead appropriate for constrained networks and with limited complexity due to node limitations. The following header design options are considered:
<list style="hanging" hangIndent="6">
<t hangText="Fixed approach:"> The simplest approach is to assume as fixed set of byte-aligned fields. The use of variable length fields should be avoided if possible, one obvious exception being a string URL (see <xref target="url"/>). This results in a simple header that can be represented as a struct and easily parsed/created. The disadvantages are difficult evolvability and the tendency to design missing tranport features on-top of CoAP.
</t>
<t hangText="Extensible approach:"> The approach of <xref target="I-D.frank-6lowapp-chopan"/> is to encode HTTP headers as binary tuples, assuming that a large number of optional headers will be needed. A similar approach could be takenin CoAP, giving total header flexibility. The disadvantage is header parsing complexity.
</t>
<t hangText="Hybrid approach:"> It is unclear how much extensibility is really required from the headers of CoAP. Some of the fields in the protocol will obviously require a sufficient value space for future extensions, such as for indicating content type. Other headers are clearly optional, such as those related to cache control (see <xref target="caching"/>) or even the URL (see <xref target="url"/>). A hybrid approach would be to design a small fixed header, with the ability to include extension headers, such as in ICMP <xref target="RFC0792"/>.
</t>
</list>
</t>
<t>
Considering the features foreseen by this document, some kind of extensible hybrid approach is recommended. Many features are fixed for messages, whereas some are expected to be optional.
</t>
</section>
<section anchor='messages' title="Basic Messages">
<t>
It is assumed that basic Request and Response messages will be required by the CoAP protocol. This also provides a natural mapping to HTTP (See <xref target="http"/>) and the response may be useful as an acknowledgement in UDP reliability (See <xref target="udp"/>). It can be considered that CoAP methods are different kinds of Request messages, therefore a separate Request message is not needed.
</t>
</section>
<section anchor='rest' title="REST Methods">
<t>
The core methods of REST must be supported within CoAP. To minimize confusion with HTTP methods, having their own protocol semantics, in CoAP we call the basic REST methods CREATE, READ, UPDATE, DELETE (CRUD) [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete].
</t>
<t>
Additionally, CoAP must support a light-weight
Subscribe/Notify mechanism (see <xref target="sub-notify"/>). This may require a new NOTIFY method. The discovery mechanism of CoAP may also require a new method called DISCOVER which has different semantics than a READ (see <xref target="discovery"/>). In order to maintain compatibility with HTTP,
these new messages must be mapped to a standard HTTP method. See <xref target="http"/> for more about HTTP mapping.
</t>
</section>
<section anchor='content-type' title="Content-type encoding">
<t>
In order to support hetergenous uses, it is important that CoAP is transparent to the use of different application payloads. In order for the application process receiving a packet to properly parse a payload, its content-type and encoding should be explicitly known from the header (as e.g. with HTTP). The use of typical binary encodings for XML is discussed in <xref target="I-D.shelby-6lowapp-encoding"/>, which includes recommendations for header indication. The draft recommends the indication of at least 10 Internet media types (MIME) <xref target="RFC2046"/> and 2 content transfer encodings.
</t>
<t>
It is obvious that string names of Internet media types <xref target="RFC2046"/> are not appropriate for use in the CoAP header. But then how to make this small yet extensible? One possible solution is to simply assign codes to a small subset of common MIME and content transfer encoding types and have IANA maintain that. A field of 16-bits should be sufficient for encoding both media and content transfer encoding types. For extending some types, magic numbers can also be used from the beginning of the payload (as defined in associated Internet media type RFCs). This could be indicated by a header value something like "See magic numbers".
</t>
</section>
<section anchor='url' title="URLs">
<t>
The Universal Resource Locator (URL) <xref target="RFC3986"/> is an important feature of the REST architecture, the relative part of the URL indicates which resource on the server is being manipulated. It is surely useful for CoAP to support string URLs, which requires a variable length-value field. Although URLs can be designed for compactness, this still often results in 10s of bytes of overhead. The encoding of the URL string also needs to be considered, as this is becoming increasingly complex. It is recommended that only US-ASCII is supported in URL strings for CoAP as defined in <xref target="RFC3986"/>, or even a stricter subset as URL parsing is complex and may result in security problems on constrained devices.
</t>
<t>
Constrained devices are not general purpose web servers, and thus often won't host but a small set of resources with fixed URLs. Thus in addition to string URLs a feature for compressing fixed URLs would be useful.
</t>
<t>One way of achieving this would be to assign an integer identifier (7-8 bits should be sufficient) to each fixed URL in an off-line interface description (e.g. Web Application Description Langauge (WADL)) or in its description. This identifier could be encoded in the URL length field instead of the string length with a flag.</t>
</section>
<section anchor='caching' title="Caching">
<t>
The cachability of CoAP messages will be important, especially with the sleeping node configurations and power limitations typically found in constrained networks and nodes. What features of cachability are really required and how much energy are we willing to spend on it? Roughly 50% of the HTTP specifications are dedicated to sohpisticated caching. With CoAP we should look at the bare minimum caching feature possible.
</t>
<t>
Before talking about caching solutiongs, we should consider in what scenarios caching will actually be required. The following two scenarios have been identified:
<list style="symbols">
<t>An intermediate CoAP proxy may cache resources and answer READ requests using a cached version. The resource may be cached from previous responses or notifications. This requires at least Max-Age cache control information about each resource. </t>
<t>An intermediate CoAP proxy may cache subscriptions to a sleeping node. This requires at least Max-Age information about the subscription.</t>
</list>
</t>
<t>
Three possible approaches have been identified for caching support.
<list style="hanging" hangIndent="6">
<t hangText="In-band approach:"> One approach is suggested in <xref target="I-D.frank-6lowapp-chopan"/>, which analyses the subset of features from HTTP that could be used for simple sensor data purposes. The proposal is that simply using the using the HTTP Age header (for resource age) and Cache-Control header (for max-age). Max-age may also be applied in requests. Both headers make use of a 2-byte value in seconds. The advantage of this approach is that cache control information is easily available from the header. The disadvantage is some header overhead.
</t>
<t hangText="Out-of-band approach:"> Here the CoAP protocol would be agnostic to the cachability of the resources it is carrying, instead leaving the definition of cache control parameters to the body of the resources in an application specific way. The disadvantage is that this makes proxies dependent on the application.
</t>
<t hangText="Discovery approach:"> In this approach the cache control information for resources is defined off-line in the list of a Device's resources. This approach is used e.g. in the SENSEI system <xref target="I-D.gold-6lowapp-sensei"/>. The disadvantage is that the caching is dependent on the profile, which may not be a problem if the cache information is in a universal format (see <xref target="discovery"/>).
</t>
</list>
</t>
<t>
Based on the current analysis the In-band approach would be reasonable for CoAP considering the requirements. This doesn't prevent the inclusion of cachability information in a resource description as well.
</t>
</section>
<section anchor='sub-notify' title="Subscribe/Notify">
<t>
CoAP is required to integrate a push model for interaction in addition to traditional request/response. This means that interested clients could subscribe to a resource (a URL), and receive notifications to a call-back URL of their choice. In its most basic form a notification would be sent each time the resource changes. There are many issues to consider including managing subscription leasing and timeouts, how to batch multiple changes and how to tune notification times. Before considering the details, there are a two general models possible for realizing the Subscribe/Notify mechanism:
<list style="hanging" hangIndent="6">
<t hangText="Resource:">Subscribe is realized using CREATE on a well known resource (e.g. /subsribe) with the URL of the resource of interest and a URL call-back in the body). Notifications would be made using a NOTIFY (or alternatively UPDATE) message to the call-back URL. Likewise, de-subscribe is realized using DELETE on the same well known resource with the URL in the body. Notifications would cease after the DELETE.</t>
<t hangText="Watch:">This method would require a CREATE to a new URI to "create" a new watch resource. UPDATE is then used to add/remove a set of URIs being "watched" along with call-backs.</t>
<t hangText="Subscribe:">An alternative to using CREATE on /subscribe or to make a new watch resource, would be to develop an explicit SUBSCRIBE method which is used directly on the URL of interest. The body of the SUBSCRIBE would include the call-back URL and other subscription information.</t>
</list>
</t>
<t>
The mapping requirement of CoAP with HTTP requires that the mapping between methods should be as simple as possible. Therefore the addition of new methods such as NOTIFY and SUBSCRIBE should be done with care. As NOTIFY is a push concept, this may at least be justified. </t>
<t>
The complexity of subscription management should also be carefully considered when working with constrained devices. An increasing number of subscription options leads to greater complexity, especially when dealing with multiple subscriptions to a resource. Subscription options to a proxy via HTTP may be quite a bit more complex than those via CoAP to a constrained device.
</t>
</section>
<section anchor='transport' title="Transport Binding">
<t>
The CoAP protocol will operate by default over UDP. There may be OPTIONAL functions in CoAP (e.g. delivery of larger chunks of data) which if implemented are implemented over TCP. In this section we look at transport issues.
</t>
<section anchor='udp' title="UDP">
<t>
The goal of binding CoAP to UDP is to provide the bare minimum features for the protocol to operate over UDP, going nowhere near trying to re-create the full feature set of TCP. The bare minimum features required would be:
<list style="symbols">
<t>Stop-and-wait would be sufficient for reliability. A simple response message itself would suffice as an acknowledgement with retransmission support. Not all requests require reliability, thus this should be optional. Performance is not the key here and for more sophisticated reliability and flow control TCP could be used.</t>
<t>A sequence number (transaction ID) is needed to match responses to open requests and would be generated by the client. A 12-16 bit unsigned interger would be sufficient. <xref target="I-D.frank-6lowapp-chopan"/> also considered this solution.</t>
<t>Multicast support. Providing reliability with a multicast destination address would be very complex. Therefore the goal is to provide a non-reliable multicast service. In many cases there may not be a response to a multicast message. A multicast command might result in an action being taken at a device, but no response being sent. Therefore a multicast request may be answered with a unicast response, however without reliability (retransmission e.g.).</t>
</list>
</t>
</section>
<section anchor='tcp' title="TCP">
<t>
The CoAP protocol also may also make use of TCP for some features. As TCP provides a reliable stream this binding does not require anything special from the CoAP protcol design. The same basic messages could be applied over TCP without stop-and-wait. A transaction ID should still be used over TCP. The question is for which features, or in which configurations would TCP be recommended? The following have been identified so far:
<list style="symbols">
<t>Delivering a large chunk of data.</t>
<t>Delivering a continuous stream of data, for example streaming sensor readings for a long period.</t>
<t>TCP may also be useful for providing congestion control if CoAP is being applied across the wider Internet.</t>
</list>
</t>
</section>
</section>
<section anchor='discovery' title="Resource Discovery">
<t>
This document assumes that an application either a) knows that CoAP services are running on a default or pre-configured port in the network or b) a service discovery method has already been used to locate CoAP services. Thus service discovery is not considered in this document.
</t>
<t>
CoAP is required to support the querying and advertisement of resources offered by CoAP services. In order to achieve this, the protocol would need to suport multicast with optional responses for discovery, along with unicast or multicast advertisement of resource descriptions. A well-known resource (e.g. /resources) could be used to enable discovery through a new DISCOVER method (or alternatively a READ). The response to a DISCOVER message would include a list of resource URLs available, an optional URI to an interface description and an optional name or identifier. CoAP services could also advertise their description by sending e.g. a multicast NOTIFY to /resources, or by posting their description to a central place (e.g. a proxy) with a CREATE to /resources.
</t>
<t>
In order to save overhead as descriptions for some nodes could become long, nodes could apply a technique similar to that used in XMPP. By default Devices would advertise a hash of their description or a hash of each resource in the description. A receiver would be able to match hashes of already known resources, and could DISCOVER the resource for its full description.
</t>
</section>
<section anchor='http' title="HTTP Mapping">
<t>
It shall be possible to map from CoAP directly to HTTP, CoAP however
only offers a small subset of the HTTP protocol features. As a result, programs implementing translation between HTTP and CoAP must either implement
other HTTP 1.1 commands on behalf of the CoAP nodes (e.g. LINK, TRACE,
OPTIONS), or must reject such request. The primary responsibility of a
program translating between HTTP and CoAP is to rewrite the headers,
translating between the highly optimized CoAP headers and plain text
HTTP headers. It must also manage/maintain TCP sessions necessary for HTTP. Depending on how some of the features of CoAP are realized, the mapping may also need to make further translations for subscription or caching.
</t>
<t>
Subscription (see the exampe below) will require a proxy mapping CoAP-HTTP to support some kind of LONG POLL method as being defined in the HyBi WG in order to avoid continuous polling of a subscription status [draft-loreto-http-bidirectional-01].
</t>
<figure anchor='mapping_1' title="Example CoAP-HTTP mapping for subscription.">
<artwork><![CDATA[
Sensor <------ coap ------> Proxy <------- http --------> Client
CREATE /subscribe <- <- POST /subscribe
OK -> -> OK (/sub1)
<- LONG GET /sub1
GET stays open
Resource changes
NOTIFY /temp -> -> OK (/temp)
OK <-
]]></artwork>
</figure>
</section>
</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>
<!-- [ZS] More contribution needed here still. -->
</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 [ref], 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>
<!-- [ZS] More contribution needed here still. -->
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Conclusions">
<t>
This document analyzed the requirements associated with the design of the foreseen Constrained Application Protocol (CoAP). Based on these requirements a list of minumum features was analyzed along with different options for realizing them. If possible a recommendation was also made where obvious. Finally, the identified features 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>
<t>
CoAP is proposed as a transport agnostic extension of REST for
deployment in confined computing environments. The intent is to
align CoAP with HTTP wherever possible to leverage the web services
computing environment already in place.</t>
<t>
Whereas REST envisions just 4 primitives (CRUD),
CoAP may propose to extend this paradigm with e.g. a NOTIFY primitive to
enable publish/subscribe along with a DISCOVER primitive to support
multicast discovery of services denoted by URL. The main
architectural difference between READ and the new discovery primitive
is the support for multicast and a possible matching feature.</t>
<t>
Finally, CoAP seeks to preserve the caching facilities of HTTP and
extend that capability for power saving devices that are not always
active on the network.</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Security Considerations">
<t>
Some of the features considered in this document will need further security considerations during a protocol design. For example the use of string URLs may have entail security risks due to complex processing on limited microcontroller implementations.
</t>
<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 and Salvatore Loreto for helpful comments and discussions.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2046;
&RFC3986;
&I-D.frank-6lowapp-chopan;
&I-D.shelby-6lowapp-encoding;
&I-D.martocci-6lowapp-building-applications;
&I-D.sturek-6lowapp-smartenergy;
&I-D.gold-6lowapp-sensei;
</references>
<references title='Informative References'>
&RFC0792;
&I-D.bormann-6lowpan-6lowapp-problem;
&I-D.moritz-6lowapp-dpws-enhancements;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:30:45 |