App Area Wiki

concluded…

Applications are being developed for networks that have very limited
packet sizes, exhibit a high degree of packet loss, and where a
substantial number of devices may be powered off at any point in
time but periodically "wake up" for brief periods of time.  These
networks, and the nodes within those, are characterized by severe
limits on throughput and range, available power, and particularly on
the complexity that can be supported with limited code size and
limited RAM per node.  Nonetheless, they form part of IP networks.
More generally, we speak of constrained-node/network (CNN)
environments (or constrained environments for short)
whenever at least some of the nodes and networks involved
exhibit these characteristics.  This WG is concentrating on
requirements from energy (e.g. Smart Energy 2.0) and building
management applications.

Low-Power Wireless Personal Area Networks (LoWPANs) are an example of
this type of network. These networks are becoming increasing important
for applications such as home automation and building automation,
energy management, and the Internet of Things. This working group will
define a framework for a limited class of applications that deal with
manipulation of simple resources on CNN devices. This includes
applications to monitor simple sensors such as a temperature sensor,
light switch, or power meter and control an actuator such as a light
switch/dim actuator, heating system, or door lock.

The general architecture consists of nodes on the CNN, called Devices,
that have one or more Resources that may represent sensors and
actuators or other parameters. Devices send message to change and
query resources on other Devices. Devices can send notifications about
changed resource values to subscribed Devices. In other words, the
architecture requires push, pull and a notify approach to manipulating
resources. As part of the framework for building these applications,
the WG will define a Constrained-node/network Application Protocol
(CoAP) for manipulation of Resources on Devices. The framework will
also specify specify a way to support interface profiles, extensible
by vendors and other standards bodies, which define the particular
Resources on a Device and what manipulations are possible.

CoAP will be designed to be used between Devices (intra- or inter-CNN)
as well as between Devices and general nodes on the Internet.

There also may be nodes called Constrained-to-General-Internet
Intermediates (CoGII) that interconnect between other protocols
typically used by applications on the Internet and the CoAP protocol
used on the CNN.  E.g., an application on a general Internet-based
network can use HTTP REST to communicate with the CoGII which will use
CoAP to interact with Resource on the Device.  The WG will define a
mapping on the CoGII from CoAP to a HTTP REST API; this mapping
will not depend on a specific application.  Each interface profile
will define the Resources on the Device that applications can
manipulate and what manipulations are possible.  This will determine
the HTTP REST APIs on the CoGIIs and the CoAP protocol encoding to
manipulate the Resources on the Device; it will also specify an XML
MIME type for each class of Device that can be used to describe the
Resource state in the body of HTTP REST messages. The WG may also work
on a mapping to SNMP on the CoGII. It is worth noting that the CoGII
does not have to be deployed at the boundary of the CNN and the more
general network but can be deployed at various locations in the
network.

CoGIIs can provide 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 CoGII that subscribed, when the
CoGII 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 CoGIIs may also provide support
for discovering Devices that may not be currently responding as they
are temporarily asleep.

The initial work items of the WG are to define:

1) An "objectives and architecture" document that documents the high
   level boxes and arrows view of the protocol along with high level
   description of how the security, particular for commissioning of
   new Devices into the network, and the operations and management
   will work. The WG may also produce a document that describes
   various use cases that help motivate the requirements; many of
   these use cases will be described by references to existing
   documents from IETF WGs such as 6LoWPAN, ROLL, or from other SDOs.

2) Specification of the framework for defining interface profiles and
   defining CoAP. CoAP will be able to set and query a resource on a
   Device. It will allow a Device to publish a value or event to
   another Device. It will support a non-reliable multicast message to
   be sent to a group of Devices to manipulate a resource on all the
   Devices simultaneously (roughly within 50 ms of each other). The
   protocol will operate by default over UDP, with a header size
   on the order of 10 bytes, and assume an underlying network
   bandwidth of several dozen kbit/s; it may optionally be bound to
   TCP or other reliable transports.  This specification will also
   define how to use CoAP to discover Devices on the CNN and to
   interrogate them to find out which interface profiles they support.
   Devices will have a way to providing a pointer to the general
   schema information so that a CoGII does not need any code changes
   to support new Devices classes.

3) Specification for the HTTP REST based API and mapping on the CoGII
   to communicate with Devices.

4) A small set of basic interface profiles to illustrate how this is
   done. Interface profiles will be done for a power meter, a light
   and a light switch, and a temperature sensor.

Security, particularly keying of new Devices, is very challenging for
these applications. On one hand this needs to support models where an
end user can introduce a new Device onto their network that may have
no display or not input capability's. On the other end this may
transport information about alarm systems or controlling door locks to
a building over a wireless network.

This WG will support three commissioning methodologies:

1) Duckling mode. One Device is put in a "mother duck" mode where it
   listens for broadcasts of Devices trying to imprint. Other Devices are
   put in a "duckling" mode where they broad cast to the "mother duck"
   Device then "imprint" by forming a new shared secret between the two
   Devices. Once this is complete the Devices are taken out of this mode
   and can be use in a secure fashion.

2) Out of Band Key mode. Each Device in manufactured with an initial
   symmetric key physically printed on the side in numeric and barcode
   form. Alternatively the Device could have a barcode that forms a URL
   which when dereferenced with appropriate authorization provides a
   secure access to the key. A human can enter or scan this into a
   computer that can then be used form a secure connection with the
   Device. Once a secure connection is formed, the symmetric key can be
   changed.

3) Certificate mode. Each Device is manufactured with a certificate
   with an asymmetric key. The fingerprint of the certificate is printed
   on a barcode. During commissioning, a computer can scan the barcode,
   the connect to the Device and replace the certificate with a locally
   generated certificate that can be used for forming secure connections.

Modes 1 and 2 are mandatory to implement but mode 3 is optional. In
all modes, once Device A and Device B have formed a secure connection
with Device C, Device C can be used to transitively introduce A and B
so now A and B have a secure connection with C. This transitive trust
introduction can be used during commissioning even if A and B do not
yet have network connectivity to each other.

Security can be achieved using other session security or object
security.  For session security, existing standards such as DTLS and
TLS can be used; the WG will work with the security area to select
ciphersuites most useful for CNNs.  For object security, CoAP will use
CMS. The WG will request the security area to define a subset of CMS
along with an EXI encoding instead of ASN.1 that is appropriate for a
CNN and for these types of Devices. It will have one mandatory to
implement crypto profile with no public key cryptography to support
modes 1 and 2 and additional crypto profile with public key
cryptography for support of mode 3. In mode 3, it will (or will not
TBD) require support for Elliptical Curve Cryptography (ECC).

The WG will coordinate on requirements from TBD (OpenSG/NIST,
ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI; 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.

Milestone:

Jan 2010 - Select WG document for basis of CoAP protocol

Jun 2010 - Objectives and Architecture to IESG as Info

Dec 2010 - Core CoAP protocol specification to IESG as PS

Dec 2010 - Specification of HTTP Rest API and mapping to IESG as PS

Mar 2011 - Specifications of basic interface profiles to IESG as PS

$Revision: 1.12 $

App Area Wiki

Context Navigation

6LowApp

Mailing List

Contribution

More Resources

BOF at IETF-76 Hiroshima

CoRE Working Group Charter Proposal

Download in other formats: