CoRE Working Group                                            C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Standards Track                        October 22, 2013
Expires: April 25, 2014


                 CoRE Roadmap and Implementation Guide
                     draft-bormann-core-roadmap-05

Abstract

   The CoRE set of protocols, in particular the CoAP protocol, is
   defined in draft-ietf-core-coap in conjunction with a number of
   specifications that are currently nearing completion.  There are also
   several dozen more individual Internet-Drafts in various states of
   development, with various levels of WG review and interest.

   Today, this is simply a bewildering array of documents.  Beyond the
   main four documents, it is hard to find relevant information and
   assess the status of proposals.  At the level of Internet-Drafts, the
   IETF has only adoption as a WG document to assign status - too crude
   an instrument to assess the level of development and standing for
   anyone who does not follow the daily proceedings of the WG.

   With a more long-term perspective, as additional drafts mature and
   existing specifications enter various levels of spec maintenance, the
   entirety of these specifications may become harder to understand,
   pose specific implementation problems, or be simply inconsistent.

   The present guide aims to provide a roadmap to these documents as
   well as provide specific advice how to use these specifications in
   combination.  In certain cases, it may provide clarifications or even
   corrections to the specifications referenced.

   This guide is intended as a continued work-in-progress, i.e. a long-
   lived Internet-Draft, to be updated whenever new information becomes
   available and new consensus on how to handle issues is formed.
   Similar to the ROHC implementation guide, RFC 4815, it might be
   published as an RFC at some future time later in the acceptance curve
   of the specifications.

   This document does not describe a new protocol or attempt to set a
   new standard of any kind - it mostly describes good practice in using
   the existing specifications, but it may also document emerging
   consensus where a correction needs to be made.






Bormann                  Expires April 25, 2014                 [Page 1]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   (TODO: The present version does not completely cover the new
   Internet-Drafts submitted concurrently with it; it is to be updated
   by the start of IETF88.)

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 25, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   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 Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The Main Four . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  The CoAP protocol . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Further reading . . . . . . . . . . . . . . . . . . . . .   6
   3.  Informational Drafts  . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Implementation  . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Multicast and Group Communication . . . . . . . . . . . .   7
     3.3.  Security  . . . . . . . . . . . . . . . . . . . . . . . .   8



Bormann                  Expires April 25, 2014                 [Page 2]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


     3.4.  Intermediaries  . . . . . . . . . . . . . . . . . . . . .   9
     3.5.  Congestion Control  . . . . . . . . . . . . . . . . . . .   9
   4.  CoAP over X . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Optional components of CoRE . . . . . . . . . . . . . . . . .  10
     5.1.  CoAP-misc . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Generalizing Media Types  . . . . . . . . . . . . . . . .  11
     5.3.  Patience, Leisure, Pledge, or: Timing extensions  . . . .  11
     5.4.  Extending Observe . . . . . . . . . . . . . . . . . . . .  11
     5.5.  Service discovery . . . . . . . . . . . . . . . . . . . .  11
     5.6.  Server discovery, Naming, etc.  . . . . . . . . . . . . .  12
     5.7.  More support for sleepy nodes . . . . . . . . . . . . . .  12
   6.  Replaced drafts . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   (To be written - for now please see the Abstract.)

1.1.  Terminology

   This document is a guide.  However, it might evolve to make specific
   recommendations on how to use standards-track specifications.
   Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119.  They indicate requirement levels for compliant CoRE
   implementations [RFC2119].  Note that these keywords are not only
   used where a correction or clarification is intended; the latter are
   explicitly identified as such.

   The term "byte" is used in its now customary sense as a synonym for
   "octet".

2.  The Main Four

   The main component of the CoRE architecture is the Constrained
   Application Protocol (CoAP).  It aims to provide a RESTful transfer
   service, not unlike HTTP, but radically simplified for the use on
   constrained devices on constrained networks.  REST is the
   architectural style that informed the design of HTTP [REST].  The
   terms "constrained device" and "constrained network" refer to
   limited-capability devices such as sensors operating on networks such



Bormann                  Expires April 25, 2014                 [Page 3]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   as the IEEE 802.15.4 based 6LoWPAN [RFC4919].
   [I-D.ietf-lwig-terminology] provides a more detailed discussion of
   what we mean by these terms.

2.1.  The CoAP protocol

   The CoAP protocol is defined in three specifications:

   o  [I-D.ietf-core-coap]

   o  [I-D.ietf-core-block]

   o  [I-D.ietf-core-observe]

   The first specification, [I-D.ietf-core-coap], provides the core
   transfer protocol, including the means to provide communication
   security using the DTLS protocol [RFC6347] (compare this to the way
   [RFC2616] and [RFC2818] define HTTP and HTTPS).  The protocol is
   structured into a message layer, which provides duplicate detection
   and optional message reliability on top of UDP, and a request/
   response layer, which provides the usual REST operations GET, PUT,
   POST, and DELETE.  A highly efficient protocol encoding carries the
   4-byte base header, a sequence of _Options_, and the payload (body)
   of a message.  The main extension points of CoAP are its Options,
   similar to the way new header fields are used to extend HTTP.

   Since CoAP is a very simple protocol running on top of UDP, it is
   limited in its transfer size by the datagram sizes provided by UDP.
   As a further constraint, many constrained networks do not provide
   good reliability of delivery once their small frame sizes are
   exceeded and the adaptation layer is forced to fragment [WEI].  This
   may lead to a practical limitation to payload sizes as small as 64
   bytes.  [I-D.ietf-core-block] extends the base CoAP protocol with
   three options that enable _blockwise_ transfer, i.e., splitting up a
   larger transfer into a sequence of smaller transactions, as well as
   the early determination of the overall size of the resource
   representation.

   In HTTP, transactions are always client initiated, and it is the
   responsibility of the client to perform GET operations again and
   again (polling) if it wants to stay up to date about the status of a
   resource.  This "pull model" becomes expensive in an environment with
   limited power, limited network resources, and nodes that sleep most
   of the time.  Some more or less savory workarounds have been
   developed for HTTP [RFC6202], but, as a new protocol, CoAP can do
   better.  [I-D.ietf-core-observe] extends the base CoAP protocol with
   an option that a client can use to indicate its interest in further
   updates from a resource.  If the server accepts this option, the



Bormann                  Expires April 25, 2014                 [Page 4]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   client becomes an _Observer_ of this resource and receives an
   asynchronous notification message each time it changes.  Each such
   notification message is identical in structure to the response to the
   initial GET request.

   While the "Block" and "Observe" specifications are optional additions
   to the CoAP protocol (just as the core specification already defines
   14 options most of which will not need to be used in every message),
   they together form what is now generally considered to be the CoAP
   protocol.

   The CoRE Working Group has completed its work on the base CoAP
   protocol specification [I-D.ietf-core-coap] and it has been approved
   by the IESG for publication as a Standards-Track RFC on 2013-07-15.
   The completed document is currently waiting in the RFC editor queue
   for two of its normative references in the security area,
   [I-D.mcgrew-tls-aes-ccm-ecc] and [I-D.ietf-tls-oob-pubkey], to be
   completed and approved.

   The other two CoAP specifications are, at the time of this writing,
   in the process of being updated based on the comments to the first
   Working-Group Last-Call [RFC2418], and in the second Working-Group
   Last-Call, respectively; these are prerequisites to submitting them
   to the IESG for publication as a Standards-Track RFC.

   The specifications, together with link-format (below), have been
   widely implemented in highly interoperable implementations: an ETSI
   "plugtest" event in March 2012 was attended by 15 organizations with
   20 implementations; in over 3000 tests performed only about 6 %
   failed; a second plugtest was conducted in November 2012 and led to
   some final adjustments of some details in the specifications.
   Another plugtest is planned for November 2013 [COAP3].

2.2.  Discovery

   The fourth specification in the main set now nearing completion does
   not extend the CoAP protocol but addresses a different problem.

   In the Web, a number of methods for discovery of resources are
   common.  Initially, Web discovery was just performed by humans based
   on an entry resource to a server (e.g., "/index.html").  This
   resource then includes links that directly or indirectly allow a
   human to reach the other Web resources that make up the Web site.

   Web discovery can be performed by machines if standardized interfaces
   and resource descriptions are available.  Among the component
   mechanisms for Web discovery that are standardized in the IETF are
   the well-known resource path "/.well-known/..." [RFC5785] and the



Bormann                  Expires April 25, 2014                 [Page 5]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   HTTP link header [RFC5988].  Several related techniques are in common
   use today.

   Clearly, in the machine-to-machine environments that will be typical
   of CoAP applications, it is important to enable devices to discover
   each other and their resources.  Autonomous devices and embedded
   systems necessitate uniform, interoperable resource discovery.

   A basic component for this is provided by a standardized description
   format for the resources a server provides, the _link-format_.
   Unless other methods of discovery are available, CoAP servers should
   provide such a description via the well-known URI "/.well-known/
   core", available for access via a GET request on that URI.  (More
   advanced resource discovery schemes might make the same description
   available by other means, e.g. by posting it to a resource
   directory.)

   The description format has been adapted from the format used in the
   HTTP link header [RFC5988], which is simple and easy to parse.  In
   contrast to the HTTP specification, link-format is specified as an
   Internet media type (what used to be called "MIME type") and intended
   to be carried around in the payload [RFC6690].

   [RFC6690] was the first RFC of the CoRE working group.

2.3.  Further reading

   A recent article provides a more detailed overview over the CoRE
   documents nearing completion [SB].

   While the specification documents themselves have to go into
   meticulous details on every aspect of their protocols, they are the
   ultimate reference source and are the recommended reading if this
   basic overview is not sufficient.

3.  Informational Drafts

3.1.  Implementation

   In the IETF, a separate working group is working on informational
   documents concerning guidance in lightweight implementation of
   protocols, the LWIG working group.  LWIG has several drafts pertinent
   here:

   [I-D.ietf-lwig-terminology] provides some common terms that are
   useful for discussing implementations and specification in the
   constrained node network space.  Section 2 and 3 of this document are
   quite stable at this time; a new section 4 is in preparation that



Bormann                  Expires April 25, 2014                 [Page 6]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   will include discussion of power-related terminology.
   [I-D.ietf-lwig-cellular] provides a well-founded discussion of
   methods for power conservation in CoAP nodes connected via cellular
   networks, from which some of the material will be used.

   [I-D.ietf-lwig-guidance] was originally intended as the main working
   document of the WG.  It contains some discussion about CoAP
   implementation in its section 3.4.2, including the efficient
   representation of managing duplicate detection state.
   [I-D.kovatsch-lwig-class1-coap] contains additional considerations
   that, over time, might move into [I-D.ietf-lwig-guidance].
   [I-D.castellani-lwig-coap-separate-responses] contains some examples
   for message exchanges, focusing on elaborating exchanges involving
   separate responses.  Since IETF86, work is under way to merge the
   CoAP-related information from these three drafts into a new document,
   [I-D.kovatsch-lwig-coap].

   A new working group has been established in the IETF Security Area to
   address the use of DTLS In Constrained Environments (DICE); several
   drafts are available for discussion at IETF88 in Vancouver.  On the
   implementation side, two drafts show how to build minimal
   implementations of security protocols relevant for CoAP:
   [I-D.ietf-lwig-tls-minimal] for TLS, which is relevant for CoAP's use
   of DTLS; and [I-D.ietf-lwig-ikev2-minimal] for IKEv2, the protocol
   for setting up IPsec security associations.  Similarly,
   [I-D.hartke-core-codtls] looks specifically into the use of DTLS in
   constrained networks.  It raises issues that pertain both to the LWIG
   and CoRE working groups of the IETF.

   Further drafts submitted to LWIG address energy efficient
   implementation [I-D.hex-lwig-energy-efficient] and recent
   developments in operating systems for constrained devices
   [I-D.hahm-lwig-painless-constrained-programming].

   After a somewhat slow start, LWIG is now picking up considerable
   energy.

3.2.  Multicast and Group Communication

   As it is based on UDP, CoAP easily supports the use of IP multicast
   to confer messages.  However, there are difficult issues around
   making the desirable multicast applications actually work well.

   This led to an additional milestone on the CoRE charter:

   Nov 2012:  Using CoAP for group communications to IESG as
      Informational




Bormann                  Expires April 25, 2014                 [Page 7]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   The informational WG draft [I-D.ietf-core-groupcomm] discusses
   fundamentals and use cases for group communication with CoAP.  This
   is now very close to Working Group last call.

   [I-D.dijk-core-groupcomm-misc] gives some additional considerations,
   listing requirements, providing some taxonomy, proposing deployment
   guidelines, and discussing approaches that are not (yet?) in the
   focus of the WG.  Its section 5 can serve as an overview over the
   status of multicast in constrained node/networks.

3.3.  Security

   Several individual drafts analyze the issues around the security of
   constrained devices in constrained networks.

   [I-D.garcia-core-security] in particular describes the "Thing
   Lifecycle" and discusses resulting architectural considerations.

   [I-D.sarikaya-core-secure-bootsolution] documents the approach taken
   in the ZigBee IP specification (used in Smart Energy Profile 2.0);
   the CoRE WG currently is not working on replicating this
   specification as an IETF document.
   [I-D.jennings-core-transitive-trust-enrollment] demonstrates a
   specific approach to securing the Thing Lifecycle based on defined
   roles of security players, including a Manufacturer, an Introducer,
   and a Transfer Agent.  There is considerable interest in the CoRE
   working group to complete one or more specifications in this space.

   Further work around Thing Lifecycles was expected to occur in the
   SOLACE initiative (Smart Object Lifecycle Architecture for
   Constrained Environments), with its early mailing list at
   solace@ietf.org -- developed after the model of the COMAN
   initiative (Management for Constrained Management Networks and
   Devices, coman@ietf.org, [I-D.ersue-constrained-mgmt]).

   Besides [I-D.garcia-core-security], recently, more work has been
   focused on the Authentication and Authorization aspects of CoRE:

   o  [I-D.gerdes-core-dcaf-authorize]

   o  [I-D.greevenbosch-core-authreq]

   o  [I-D.pporamba-dtls-certkey]

   o  [I-D.urien-core-racs]

   o  [I-D.schmitt-two-way-authentication-for-iot]




Bormann                  Expires April 25, 2014                 [Page 8]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   o  [I-D.seitz-core-sec-usecases]

   o  [I-D.selander-core-access-control]

   o  [I-D.zhu-core-groupauth]

3.4.  Intermediaries

   [I-D.castellani-core-http-mapping] discusses some ideas about what
   HTTP/CoAP intermediaries could do beyond the basic mapping defined in
   [I-D.ietf-core-coap]; in the IETF86 WG meeting, this document was
   agreed as a future working group item (with validation of the
   adoption on the mailing list still pending).  An earlier version of
   this draft was split into the current document describing best
   practices for mapping between HTTP and CoAP (beyond what is already
   described in [I-D.ietf-core-coap]), and one additional document that
   describes usages that serve as additional useful examples for more
   advanced forms of mapping, a first draft of the latter is available
   in [I-D.castellani-core-advanced-http-mapping].

3.5.  Congestion Control

   [I-D.ietf-core-coap] only defines a very basic congestion control
   scheme that is focused on being safe in a wide variety of
   applications.  Additional documents will define more advanced
   congestion control schemes that can provide more optimized
   performance in exchange for more implementation complexity and/or a
   narrower field of application.

   Several drafts are contributing to this active subject of discussion
   in the WG:

   | draft-bormann-core-congestion-control    | -02 | 2012-08-01 |
   | draft-bormann-core-cocoa                 | -00 | 2012-08-13 |


   [I-D.greevenbosch-core-minimum-request-interval] proposes adding an
   option that allows a server to indicate its desire for some pacing of
   the requests sent to it by one client; enabling a form of server load
   control.

4.  CoAP over X









Bormann                  Expires April 25, 2014                 [Page 9]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   [I-D.becker-core-coap-sms-gprs] shows how to run CoAP over cellular
   SMS and in mixed SMS/GPRS environments.  This draft optionally makes
   use of an SMS-oriented encoding for CoAP that is described in
   [I-D.bormann-coap-misc].
   [I-D.silverajan-core-coap-alternative-transports] discusses how to
   indicate the alternative transport in a URI.

   [I-D.li-core-coap-payload-length-option] defines a way to indicate
   the length of the payload in case the underlying transport does not
   provide a suitable definite length indication.

5.  Optional components of CoRE

   Additional sub-protocols are being discussed in the IETF that may
   become optional protocols in CoREs.

   The present document will track these sub-protocols and be amended
   once the sub-protocols reach formal status in the IETF.

   Since the WG is cautious in adopting additional work while the main
   specifications near completion, none of the additional protocols
   proposed have become WG documents yet.

5.1.  CoAP-misc

   One draft is a little different from the other drafts in this
   category: [I-D.bormann-coap-misc] is a running document capturing
   CoAP extensions that are in various states of being cooked.

   Some of these extensions may finally be adopted for the WG documents
   and then vanish from CoAP-misc.  For other extensions, we may decide
   that they are not very good ideas.  Instead of deleting them from
   CoAP-misc, they are moved to an appendix.  This documents the
   approach, the best implementation of that approach that was reached,
   and the reasons why it was not adopted.  This documentation should
   spare the WG and its contributors from the continuous reinvention of
   bad ideas.

   As of the time of writing, the main body of CoAP-misc is almost
   empty, as most urgent developments have found their way into the WG
   documents, and many other ideas wait in the "nursery" section of the
   document.









Bormann                  Expires April 25, 2014                [Page 10]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


5.2.  Generalizing Media Types

   CoAP defines a registry for combinations of an Internet Media Type
   ("MIME type") and a Content Encoding (e.g. some form of compression),
   enabling its compact encoding of this information in one or two
   bytes.  Each entry in the registry defines a single, fixed set of
   media type parameters (as in ";charset=utf-8"), if any.  This does
   not work well with media types that rely on more complex combinations
   of parameter settings.  [I-D.doi-core-parameter-option] proposes to
   add an option to carry parameters for media types.

   [I-D.fossati-core-multipart-ct] defines a new media type that can
   carry multiple embedded representations employing different media
   types using a binary type-length-value format.

5.3.  Patience, Leisure, Pledge, or: Timing extensions

   Several proposals intend to extend the amount of information
   available during an exchange about the timing requirements of the
   participants.

   | draft-li-core-coap-patience-option | -01 | 2012-10-22 |


   Another discussion is in Appendix B.4 of [I-D.bormann-coap-misc].

   The question of whether some of this functionality should be
   introduced into the main WG documents now is currently also the
   subject of an active issue tracker ticket [CoRE204].

5.4.  Extending Observe

5.5.  Service discovery

   Basic service discovery is defined in [RFC6690].  A JSON
   representation of the same information is defined in
   [I-D.ietf-core-links-json].  The intention is to make this
   information available in an equivalent format that is more accessible
   to classic Web servers, both as a file format (Internet media type)
   and as a format that can be used in e.g. a JavaScript API.

   [I-D.arkko-core-dev-urn] defines a new Uniform Resource Name (URN)
   namespace that can be used to provide hardware device identifiers in
   resource descriptions.







Bormann                  Expires April 25, 2014                [Page 11]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   [I-D.ietf-core-interfaces] provides additional semantics that can be
   used to make resource descriptions more directly machine-
   interpretable.  This ties in to a more general discussion about CoRE
   profiles that has only just begun.

   [I-D.greevenbosch-core-profile-description] ties into this and
   defines a basic JSON format for indicating what CoAP Options and what
   Content-Formats (still called media-types there) are available for a
   resource.  At IETF86 there was fairly good consensus in the CoRE WG
   that we should be working on something addressing the underlying
   problem statement, while there was not yet agreement on the specific
   solution.

   [I-D.fossati-core-fp-link-format-attribute] defines a link-format
   attribute that indicates a certain resource is best reached via a
   specific proxy.

5.6.  Server discovery, Naming, etc.

   On the boundary between service and server discovery, resource
   directory servers provide a way to collect resource descriptions from
   multiple servers into one accessible location.

   [I-D.bormann-core-simple-server-discovery] provided a basic way to
   discover such servers in a constrained node/network without
   necessarily having to resort to multicast.  It has been merged into
   [I-D.ietf-core-resource-directory], which defines protocol elements
   that can be used for setting up such a resource directory.

   An attempt to merge mDNS/DNS-SD-based discovery (colloquially known
   as zeroconf or Bonjour), including recent approaches to extend these
   for constrained networks, into the picture is documented in
   [I-D.vanderstok-core-dna]; at IETF86 the authors showed interest to
   continue work on this.

5.7.  More support for sleepy nodes

   The basic communication model of CoAP was imported from the Web.
   This applies well to some communication requirements in constrained
   node/networks, but leaves some other requirements open.

   The assumption underlying the current set of WG documents is that the
   communication layers below the application provide support functions
   for sleeping nodes.  Adding support at the application layer might be
   able to further reduce the power requirements of "sleepy nodes" that
   can sleep most of the time.





Bormann                  Expires April 25, 2014                [Page 12]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   [I-D.rahman-core-sleepy-problem-statement] summarizes the overall
   problem statement for sleepy nodes without getting into any specific
   solution.

   A number of drafts aim to extend the CoAP communication model towards
   more support for sleepy nodes.

   The base CoAP spec [I-D.ietf-core-coap] already provides some
   rudimentary support of sleepy nodes by supporting caching in
   intermediaries: resources from a sleepy node may be available from a
   caching proxy (if previously retrieved) even though the node is
   asleep.  [I-D.ietf-core-observe] enhances this support by enabling
   sleepy nodes to update caching intermediaries on their own schedule.

   A number of drafts more extensively extend the concept of an
   intermediary by introducing an additional kind of server that is
   hosting the resources of the sleepy node:

   The approach of [I-D.vial-core-mirror-server] is to store the actual
   resource representations in a special type of Resource Directory
   called the Mirror Server.  Communicating devices can then fetch the
   resource from the Mirror Server regardless of the state of the sleepy
   server.  ([I-D.vial-core-mirror-proxy] simply appears to be a
   previous version of this draft.)

   Similar to the above, the approach of
   [I-D.fossati-core-publish-option] is to temporarily delegate
   authority of its resources (when it is sleeping) to a proxy server
   that is always on.

   Also, the approach of [I-D.giacomin-core-sleepy-option] is to define
   a proxy that acts as a store-and-forward agent for a sleepy node.

   Other drafts introduce a variety of signaling based approaches to
   facilitate communicating with sleepy nodes: The approach of
   [I-D.castellani-core-alive] is to define a new CoAP message type
   (called "Alive") which the sleepy node multicasts to all interested
   devices when it wakes up.  The approach of [I-D.rahman-core-sleepy]
   is to introduce storing of sleep characteristics in the Resource
   Directory.  Communicating devices can then query the RD to learn the
   sleep status of the sleepy node before attempting communications.

   Finally, some drafts build on the concept of the Observe mechanism to
   help keep track of the sleepy node information.  The approach of
   [I-D.fossati-core-monitor-option] is to extend the Observe pattern to
   handle the scenario when both server and clients are sleepy nodes.
   Note that some of the other drafts (e.g.,
   [I-D.vial-core-mirror-server], [I-D.rahman-core-sleepy]) include



Bormann                  Expires April 25, 2014                [Page 13]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   using/extending the Observe mechanism as part of their overall
   approach.

   Support for sleepy nodes is currently a very active subject of
   discussion in the WG; it is clear that there is a high level of
   interest in the WG in addressing application-level support for sleepy
   nodes in future specifications.  See also the discussion of
   [I-D.ietf-lwig-cellular] in Section 3.1 above.

6.  Replaced drafts

   Internet-Drafts often get replaced by merged drafts or get promoted
   to WG drafts.  As the relationships between drafts are not always
   accurately captured by the secretariat tools, this table provides a
   mapping from current drafts to any previous drafts they are
   replacing:

   +------------------------------------+------------------------------+
   | current draft                      | replaced draft               |
   +------------------------------------+------------------------------+
   | [I-D.ietf-core-coap]               | draft-shelby-core-coap       |
   |                                    |                              |
   | [I-D.ietf-core-block]              | draft-bormann-core-coap-     |
   |                                    | block                        |
   |                                    |                              |
   |                                    | draft-li-core-coap-size-     |
   |                                    | option                       |
   |                                    |                              |
   | [I-D.ietf-core-observe]            | draft-hartke-coap-observe    |
   |                                    |                              |
   | [RFC6690]                          | draft-shelby-core-link-      |
   |                                    | format                       |
   |                                    |                              |
   | [I-D.ietf-core-groupcomm]          | draft-rahman-core-groupcomm  |
   |                                    |                              |
   | [I-D.becker-core-coap-sms-gprs]    | draft-li-core-coap-over-sms  |
   |                                    |                              |
   | [I-D.vanderstok-core-dna]          | draft-vanderstok-core-bc     |
   |                                    |                              |
   | [I-D.ietf-core-resource-directory] | draft-bormann-core-simple-   |
   |                                    | server-discovery             |
   |                                    |                              |
   | [I-D.greevenbosch-core-minimum-    | draft-greevenbosch-core-     |
   | request-interval]                  | block-minimum-time           |
   +------------------------------------+------------------------------+






Bormann                  Expires April 25, 2014                [Page 14]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   Note that draft-scim-core-schema is just named against the naming
   conventions and actually unrelated to the CoRE working group.

7.  IANA Considerations

   This document has no actions for IANA.

8.  Security Considerations

   (None so far; this section will certainly grow as additional security
   considerations beyond those listed in the base specifications become
   known.)

9.  Acknowledgements

   (The concept for this document is borrowed from [RFC4815], which was
   invented by Lars-Erik Jonsson.  Thanks!)

   Akbar Rahman contributed text to this roadmap.

10.  References

10.1.  Normative References

   [I-D.ietf-core-block]
              Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
              draft-ietf-core-block-13 (work in progress), October 2013.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-18
              (work in progress), June 2013.

   [I-D.ietf-core-observe]
              Hartke, K., "Observing Resources in CoAP", draft-ietf-
              core-observe-11 (work in progress), October 2013.

   [I-D.ietf-tls-oob-pubkey]
              Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
              T. Kivinen, "Using Raw Public Keys in Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", draft-ietf-tls-oob-pubkey-10 (work in progress),
              October 2013.

   [I-D.mcgrew-tls-aes-ccm-ecc]
              McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
              CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm-
              ecc-07 (work in progress), August 2013.



Bormann                  Expires April 25, 2014                [Page 15]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785, April
              2010.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, August 2012.

10.2.  Informative References

   [COAP3]    ETSI plugtests, "CoAP 3 & OMA Lightweight M2M", 2013,
              <http://www.etsi.org/coap-oma-lightweight-m2m>.

   [CoRE204]  Bormann, C., "Introduce a minimal version of Pledge", CoRE
              ticket #204, 2012,
              <http://trac.tools.ietf.org/wg/core/trac/ticket/204>.

   [I-D.arkko-core-dev-urn]
              Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource
              Names for Device Identifiers", draft-arkko-core-dev-urn-03
              (work in progress), July 2012.

   [I-D.becker-core-coap-sms-gprs]
              Becker, M., Li, K., Poetsch, T., and K. Kuladinithi,
              "Transport of CoAP over SMS", draft-becker-core-coap-sms-
              gprs-04 (work in progress), August 2013.

   [I-D.bormann-coap-misc]
              Bormann, C. and K. Hartke, "Miscellaneous additions to
              CoAP", draft-bormann-coap-misc-25 (work in progress), May
              2013.

   [I-D.bormann-core-simple-server-discovery]
              Bormann, C., "CoRE Simple Server Discovery", draft-
              bormann-core-simple-server-discovery-01 (work in
              progress), March 2012.

   [I-D.castellani-core-advanced-http-mapping]
              Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
              E. Dijk, "Best Practices for HTTP-CoAP Mapping
              Implementation", draft-castellani-core-advanced-http-
              mapping-02 (work in progress), July 2013.




Bormann                  Expires April 25, 2014                [Page 16]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   [I-D.castellani-core-alive]
              Castellani, A. and S. Loreto, "CoAP Alive Message", draft-
              castellani-core-alive-00 (work in progress), March 2012.

   [I-D.castellani-core-http-mapping]
              Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
              E. Dijk, "Best Practices for HTTP-CoAP Mapping
              Implementation", draft-castellani-core-http-mapping-07
              (work in progress), February 2013.

   [I-D.castellani-lwig-coap-separate-responses]
              Castellani, A., "Learning CoAP separate responses by
              examples", draft-castellani-lwig-coap-separate-
              responses-00 (work in progress), March 2012.

   [I-D.dijk-core-groupcomm-misc]
              Dijk, E. and A. Rahman, "Miscellaneous CoAP Group
              Communication Topics", draft-dijk-core-groupcomm-misc-04
              (work in progress), June 2013.

   [I-D.doi-core-parameter-option]
              Doi, Y. and K. Lynn, "CoAP Content-Type Parameter Option",
              draft-doi-core-parameter-option-03 (work in progress),
              August 2013.

   [I-D.ersue-constrained-mgmt]
              Ersue, M., Romascanu, D., and J. Schoenwaelder,
              "Management of Networks with Constrained Devices: Problem
              Statement, Use Cases and Requirements", draft-ersue-
              constrained-mgmt-03 (work in progress), February 2013.

   [I-D.fossati-core-fp-link-format-attribute]
              Fossati, T. and S. Loreto, "Resource Discovery through
              Proxies", draft-fossati-core-fp-link-format-attribute-00
              (work in progress), July 2012.

   [I-D.fossati-core-monitor-option]
              Fossati, T., Giacomin, P., and S. Loreto, "Monitor Option
              for CoAP", draft-fossati-core-monitor-option-00 (work in
              progress), July 2012.

   [I-D.fossati-core-multipart-ct]
              Fossati, T., "Multipart Content-Format Encoding for CoAP",
              draft-fossati-core-multipart-ct-03 (work in progress),
              October 2013.

   [I-D.fossati-core-publish-option]




Bormann                  Expires April 25, 2014                [Page 17]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


              Fossati, T., Giacomin, P., and S. Loreto, "Publish Option
              for CoAP", draft-fossati-core-publish-option-02 (work in
              progress), October 2013.

   [I-D.garcia-core-security]
              Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
              R. Struik, "Security Considerations in the IP-based
              Internet of Things", draft-garcia-core-security-06 (work
              in progress), September 2013.

   [I-D.gerdes-core-dcaf-authorize]
              Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
              Authorization Function (DCAF)", draft-gerdes-core-dcaf-
              authorize-00 (work in progress), July 2013.

   [I-D.giacomin-core-sleepy-option]
              Fossati, T., Giacomin, P., Loreto, S., and M. Rossini,
              "Sleepy Option for CoAP", draft-giacomin-core-sleepy-
              option-00 (work in progress), February 2012.

   [I-D.greevenbosch-core-authreq]
              Greevenbosch, B., "Use cases and requirements for
              authentication and authorisation in CoAP", draft-
              greevenbosch-core-authreq-00 (work in progress), September
              2013.

   [I-D.greevenbosch-core-minimum-request-interval]
              Greevenbosch, B., "CoAP Minimum Request Interval", draft-
              greevenbosch-core-minimum-request-interval-01 (work in
              progress), April 2013.

   [I-D.greevenbosch-core-profile-description]
              Greevenbosch, B., Hoebeke, J., Ishaq, I., and F. Abeele,
              "CoAP Profile Description Format", draft-greevenbosch-
              core-profile-description-02 (work in progress), June 2013.

   [I-D.hahm-lwig-painless-constrained-programming]
              Hahm, O., Baccelli, E., and K. Schleiser, "Painless Class
              1 Devices Programming", draft-hahm-lwig-painless-
              constrained-programming-00 (work in progress), March 2013.

   [I-D.hartke-core-codtls]
              Hartke, K. and O. Bergmann, "Datagram Transport Layer
              Security in Constrained Environments", draft-hartke-core-
              codtls-02 (work in progress), July 2012.

   [I-D.hex-lwig-energy-efficient]




Bormann                  Expires April 25, 2014                [Page 18]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


              Cao, Z., He, X., Kovatsch, M., Tian, H., and C. Gomez,
              "Energy Efficient Implementation of IETF Constrained
              Protocol Suite", draft-hex-lwig-energy-efficient-02 (work
              in progress), October 2013.

   [I-D.ietf-core-groupcomm]
              Rahman, A. and E. Dijk, "Group Communication for CoAP",
              draft-ietf-core-groupcomm-16 (work in progress), October
              2013.

   [I-D.ietf-core-interfaces]
              Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf-
              core-interfaces-00 (work in progress), June 2013.

   [I-D.ietf-core-links-json]
              Bormann, C., "Representing CoRE Link Collections in JSON",
              draft-ietf-core-links-json-00 (work in progress), June
              2013.

   [I-D.ietf-core-resource-directory]
              Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource
              Directory", draft-ietf-core-resource-directory-00 (work in
              progress), June 2013.

   [I-D.ietf-lwig-cellular]
              Arkko, J., Eriksson, A., and A. Keranen, "Building Power-
              Efficient CoAP Devices for Cellular Networks", draft-ietf-
              lwig-cellular-00 (work in progress), August 2013.

   [I-D.ietf-lwig-guidance]
              Bormann, C., "Guidance for Light-Weight Implementations of
              the Internet Protocol Suite", draft-ietf-lwig-guidance-03
              (work in progress), February 2013.

   [I-D.ietf-lwig-ikev2-minimal]
              Kivinen, T., "Minimal IKEv2", draft-ietf-lwig-
              ikev2-minimal-01 (work in progress), October 2013.

   [I-D.ietf-lwig-terminology]
              Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained Node Networks", draft-ietf-lwig-terminology-05
              (work in progress), July 2013.

   [I-D.ietf-lwig-tls-minimal]







Bormann                  Expires April 25, 2014                [Page 19]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


              Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's
              Guide to the (Datagram) Transport Layer Security Protocol
              for Smart Objects and Constrained Node Networks", draft-
              ietf-lwig-tls-minimal-00 (work in progress), September
              2013.

   [I-D.jennings-core-transitive-trust-enrollment]
              Jennings, C., "Transitive Trust Enrollment for Constrained
              Devices", draft-jennings-core-transitive-trust-
              enrollment-01 (work in progress), October 2012.

   [I-D.kovatsch-lwig-class1-coap]
              Kovatsch, M., "Implementing CoAP for Class 1 Devices",
              draft-kovatsch-lwig-class1-coap-00 (work in progress),
              October 2012.

   [I-D.kovatsch-lwig-coap]
              Kovatsch, M., Bergmann, O., Dijk, E., He, X., and C.
              Bormann, "CoAP Implementation Guidance", draft-kovatsch-
              lwig-coap-01 (work in progress), July 2013.

   [I-D.li-core-coap-payload-length-option]
              Li, K., "CoAP Payload-Length Option Extension", draft-li-
              core-coap-payload-length-option-02 (work in progress),
              August 2013.

   [I-D.pporamba-dtls-certkey]
              Porambage, P., Kumar, P., Gurtov, A., Ylianttila, M., and
              E. Harjula, "Certificate based keying scheme for DTLS
              secured IoT", draft-pporamba-dtls-certkey-00 (work in
              progress), June 2013.

   [I-D.rahman-core-sleepy-problem-statement]
              Rahman, A., Fossati, T., Loreto, S., and M. Vial, "Sleepy
              Devices in CoAP - Problem Statement", draft-rahman-core-
              sleepy-problem-statement-01 (work in progress), October
              2012.

   [I-D.rahman-core-sleepy]
              Rahman, A., "Enhanced Sleepy Node Support for CoAP",
              draft-rahman-core-sleepy-04 (work in progress), October
              2013.

   [I-D.sarikaya-core-secure-bootsolution]
              Sarikaya, B., "Security Bootstrapping Solution for
              Resource-Constrained Devices", draft-sarikaya-core-secure-
              bootsolution-00 (work in progress), February 2013.




Bormann                  Expires April 25, 2014                [Page 20]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   [I-D.schmitt-two-way-authentication-for-iot]
              Schmitt, C., Stiller, B., Kothmayr, T., and W. Hu, "DTLS-
              based Security with two-way Authentication for IoT",
              draft-schmitt-two-way-authentication-for-iot-01 (work in
              progress), October 2013.

   [I-D.seitz-core-sec-usecases]
              Seitz, L., Gerdes, S., and G. Selander, "Use cases for
              CoRE security", draft-seitz-core-sec-usecases-00 (work in
              progress), September 2013.

   [I-D.selander-core-access-control]
              Selander, G., Sethi, M., and L. Seitz, "Access Control
              Framework for Constrained Environments", draft-selander-
              core-access-control-01 (work in progress), October 2013.

   [I-D.silverajan-core-coap-alternative-transports]
              Silverajan, B. and T. Savolainen, "CoAP Communication with
              Alternative Transports", draft-silverajan-core-coap-
              alternative-transports-03 (work in progress), October
              2013.

   [I-D.urien-core-racs]
              Urien, P., "Remote APDU Call Secure (RACS)", draft-urien-
              core-racs-00 (work in progress), August 2013.

   [I-D.vanderstok-core-dna]
              Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery,
              Naming, and Addressing", draft-vanderstok-core-dna-02
              (work in progress), July 2012.

   [I-D.vial-core-mirror-proxy]
              Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
              proxy-01 (work in progress), July 2012.

   [I-D.vial-core-mirror-server]
              Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
              server-01 (work in progress), April 2013.

   [I-D.zhu-core-groupauth]
              Zhu, J. and M. Qi, "Group Authentication", draft-zhu-core-
              groupauth-01 (work in progress), September 2013.

   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", Ph.D. Dissertation,
              University of California, Irvine, 2000, <http://
              www.ics.uci.edu/~fielding/pubs/dissertation/
              fielding_dissertation.pdf>.



Bormann                  Expires April 25, 2014                [Page 21]


Internet-Draft    CoRE Roadmap and Implementation Guide     October 2013


   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC4815]  Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer,
              "RObust Header Compression (ROHC): Corrections and
              Clarifications to RFC 3095", RFC 4815, February 2007.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals", RFC
              4919, August 2007.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

   [RFC6202]  Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
              "Known Issues and Best Practices for the Use of Long
              Polling and Streaming in Bidirectional HTTP", RFC 6202,
              April 2011.

   [SB]       Bormann, C., Castellani, A., and Z. Shelby, "CoAP: An
              Application Protocol for Billions of Tiny Internet Nodes",
              DOI 10.1109/MIC.2012.29, 2012.

   [WEI]      Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
              Internet", ISBN 9780470747995, 2009.

Author's Address

   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Email: cabo@tzi.org









Bormann                  Expires April 25, 2014                [Page 22]