IETF 80 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

Constrained RESTful Environments (core) (WG)

Minutes  | Audio Archives  |  Jabber Logs  |  Mailing List Archives

Additional information is available at tools.ietf.org/wg/core

Chair(s): Carsten Bormann Cullen Jennings Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre

Meeting Slides

• Consolidated slides (draft snapshot)

Internet-Drafts:

• Constrained Application Protocol (CoAP) (175992 bytes)
• Blockwise transfers in CoAP (47484 bytes)
• Observing Resources in CoAP (39276 bytes)
• CoRE Link Format (41356 bytes)

No Request For Comments

Charter (as of 2010-03-25)

CoRE is providing a framework for resource-oriented applications
intended to run on constrained IP networks. A constrained IP network
has limited packet sizes, may exhibit a high degree of packet loss, and
may have a substantial number of devices that may be powered off at any
point in time but periodically "wake up" for brief periods of time.
These networks and the nodes within them are characterized by severe
limits on throughput, available power, and particularly on the
complexity that can be supported with limited code size and limited RAM
per node. More generally, we speak of constrained networks whenever at
least some of the nodes and networks involved exhibit these
characteristics. Low-Power Wireless Personal Area Networks (LoWPANs)
are an example of this type of network. Constrained networks can occur
as part of home and building automation, energy management, and the
Internet of Things.

The CoRE working group will define a framework for a limited class of
applications: those that deal with the manipulation of simple resources
on constrained networks. This includes applications to monitor simple
sensors (e.g. temperature sensors, light switches, and power meters), to
control actuators (e.g. light switches, heating controllers, and door
locks), and to manage devices.

The general architecture consists of nodes on the constrained network,
called Devices, that are responsible for one or more Resources that may
represent sensors, actuators, combinations of values or other
information. Devices send messages to change and query resources on
other Devices. Devices can send notifications about changed resource
values to Devices that have subscribed to receive notification about
changes. A Device can also publish or be queried about its
resources. (Typically a single physical host on the network would have
just one Device but a host might represent multiple logical Devices.
The specific terminology to be used here is to be decided by the WG.)
As part of the framework for building these applications, the WG will
define a Constrained Application Protocol (CoAP) for the manipulation of
Resources on a Device.

CoAP will be designed for use between Devices on the same constrained
network, between Devices and general nodes on the Internet, and between
Devices on different constrained networks both joined by an
internet. CoAP targets the type of operating environments defined in the
ROLL and 6LOWPAN working groups which have additional constraints
compared to normal IP networks, but the CoAP protocol will also operate
over traditional IP networks.

There also may be proxies that interconnect between other Internet
protocols and the Devices using the CoAP protocol. The WG will define a
mapping from CoAP to an HTTP REST API; this mapping will not depend on a
specific application. It is worth noting that proxy does not have to
occur at the boundary between the constrained network and the more
general network, but can be deployed at various locations in the
unconstrained network.

CoAP will support various forms of "caching". For example, if a
temperature sensor is normally asleep but wakes up every five minutes
and sends the current temperature to a proxy that has subscribed, when
the proxy receives a request over HTTP for that temperature resource, it
can respond with the last seen value instead of trying to query the
Device which is currently asleep.

The initial work item of the WG is to define a protocol specification
for CoAP that includes:

1) The ability to create, read, update and delete a Resource on a
Device.

2) 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.

3) The ability to support a non-reliable multicast message to be sent to
a group of Devices to manipulate a resource on all the Devices in the
group.

4) 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. Applications which require the optional TCP
features will limit themselves to a narrower subset of deployment
cases.

5) 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.

6) Specification for the HTTP REST based API and translation to
communicate with Devices. Translation should make use of Device
description information and should not need code updates to deal with
new Devices.

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

The working group will not develop a reliable multicast solution, and
will not develop a general service discovery solution. There is a desire
for discovery and configuration features, but the working group has not
yet closed in on an specific approach. Thus, the WG may explore these
topics and adopt drafts that define requirements or set problem
statements, but will not adopt implementable specifications without a
recharter.

Security, particularly keying of new Devices, is very challenging for
these applications. The WG will work to select approaches to security
bootstrapping which are realistic given the constraints and requirements
of the network. To ensure that any two nodes can join together, all
nodes must implement at least one universal bootstrapping method.

Security can be achieved using either session security or object
security. For both object and session security, the WG will work with
the security area to select appropriate security framework and protocol
as well as selecting a minimal required to implement cipher suite. CoAP
will initially look at CMS (RFC 5652), TLS/DTLS, and EAP.

The WG will coordinate on requirements from many organizations including
OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI,
ASHRAE/BACnet; other SDOs and organizations. The WG will closely
coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate
groups in the IETF OPS and Security areas.

Goals and Milestones:

Apr 2010		Select WG document for basis of the CoAP protocol
Dec 2010		CoAP protocol specification with mapping to HTTP Rest API submitted to IESG as PS
Dec 2010		Constrained security bootstrapping specification submitted to IESG as PS
Jan 2011		Recharter to add things reduced out of initial scope