A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)
draft-jimenez-p2psip-coap-reload-07

The information below is for an old version of the document
Document Type Active Internet-Draft (individual in rai area)
Last updated 2015-04-10 (latest revision 2015-02-03)
Stream IETF
Intended RFC status Proposed Standard
Formats plain text pdf html bibtex
Additional URLs
Stream WG state (None)
Document shepherd Carlos Bernardos
Shepherd write-up Show (last changed 2015-02-04)
IESG IESG state AD Evaluation
Consensus Boilerplate Unknown
Telechat date
Responsible AD Ben Campbell
Send notices to jmlvega@ugr.es, jaime.jimenez@ericsson.com, gonzalo.camarillo@ericsson.com, cjbc@it.uc3m.es, Jouni.Maenpaa@ericsson.com
P2PSIP                                                        J. Jimenez
Internet-Draft                                                  Ericsson
Intended status: Standards Track                           J. Lopez-Vega
Expires: August 7, 2015                            University of Granada
                                                              J. Maenpaa
                                                            G. Camarillo
                                                                Ericsson
                                                        February 3, 2015

 A Constrained Application Protocol (CoAP) Usage for REsource LOcation
                         And Discovery (RELOAD)
                  draft-jimenez-p2psip-coap-reload-07

Abstract

   This document defines a Constrained Application Protocol (CoAP) Usage
   for REsource LOcation And Discovery (RELOAD).  The CoAP Usage
   provides the functionality to federate Wireless Sensor Networks (WSN)
   in a peer-to-peer fashion.  The CoAP Usage for RELOAD allows CoAP
   nodes to store resources in a RELOAD peer-to-peer overlay, provides a
   lookup service, and enables the use of RELOAD overlay as a cache for
   sensor data.  This functionality is implemented in the RELOAD overlay
   itself, without the use of centralized servers.  The RELOAD AppAttach
   method is used to establish a direct connection between nodes through
   which CoAP messages are exchanged.

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 August 7, 2015.

Jimenez, et al.          Expires August 7, 2015                 [Page 1]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Registering CoAP URIs . . . . . . . . . . . . . . . . . . . .   7
   5.  Lookup  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Forming a Direct Connection and Reading Data  . . . . . . . .   9
   7.  Caching Mechanisms  . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  ProxyCache  . . . . . . . . . . . . . . . . . . . . . . .  11
     7.2.  SensorCache . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  CoAP Usage Kinds Definition . . . . . . . . . . . . . . . . .  14
     8.1.  CoAP-REGISTRATION Kind  . . . . . . . . . . . . . . . . .  14
     8.2.  CoAP-CACHING Kind . . . . . . . . . . . . . . . . . . . .  15
   9.  Access Control Rules  . . . . . . . . . . . . . . . . . . . .  15
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  16
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  CoAP-REGISTRATION Kind-ID  . . . . . . . . . . . . . . .  16
     11.2.  CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . .  17
     11.3.  Access Control Policies  . . . . . . . . . . . . . . . .  17
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     12.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   This usage is intended for interconnected devices over a wide-area
   geographical coverage.  For example in cases multiple Wireless Sensor
   Networks (WSN) that need to be fedetrated over some wider-area
   network.  These would interconnect by means of nodes that are equiped
   with long range modules (2G, 3G, 4G) as well as short range ones
   (XBee, ZigBee, BLE, ...) Since these federations ocur over a wide

Jimenez, et al.          Expires August 7, 2015                 [Page 2]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   area, distances between them are from the order of hundreds of meters
   to kilometers.

   Constained devices are likely to be heterogeneous when it comes to
   their radio layer, however we expect them to use a common application
   layer protocol, CoAP.  The Constrained Application Protocol (CoAP) is
   a specialized web transfer protocol [RFC7252].  It realizes the
   Representational State Transfer (REST) architecture for the most
   constrained nodes, such as sensors and actuators.  CoAP can be used
   not only between nodes on the same constrained network but also
   between constrained nodes and nodes on the Internet.  The latter is
   possible since CoAP can be translated to Hypertext Transfer Protocol
   (HTTP) for integration with the web.  Application areas of CoAP
   include different forms of M2M communication, such as home
   automation, construction, health care or transportation.  Areas with
   heavy use of sensor and actuator devices that monitor and interact
   with the surrounding environment.

   As specified in [RFC6940] RELOAD is fundamentally an overlay network.
   Providing a layered architecture with plugable application layers
   than can use the underlaying forwarding, storage and lookup
   functionalities.  Figure 1 illustrates where the CoAP Usage is placed
   within the RELOAD architecture.

Jimenez, et al.          Expires August 7, 2015                 [Page 3]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

               Application

           +-------+
           | CoAP  |   ...
           | Usage |
           +-------+
       ------------------------------------ Messaging Service
       +------------------+     +---------+
       |     Message      |<--->| Storage |
       |    Transport     |     +---------+
       +------------------+           ^
              ^       ^               |
              |       v               v
              |     +-------------------+
              |     |    Topology       |
              |     |    Plug-in        |
              |     +-------------------+
              |         ^
              v         v
           +------------------+
           |  Forwarding &    |
           | Link Management  |
           +------------------+
       ------------------------------------ Overlay Link Service
            +-------+  +-------+
            |TLS    |  |DTLS   |  ...
            |Overlay|  |Overlay|
            |Link   |  |Link   |
            +-------+  +-------+

                          Figure 1: Architecture

   The CoAP Usage involves three basic functions:

   Registration: CoAP nodes can use the RELOAD data storage
   functionality to store a mapping from their CoAP URI to their Node-ID
   in the overlay, and to retrieve the Node-IDs of other nodes.

   Lookup: Once a CoAP node has identified the Node-ID for an URI it
   wishes to retrieve, it can use the RELOAD message routing system to
   set up a connection which can be used to exchange CoAP messages.

   Caching: Nodes can use the RELOAD overlay as a caching mechanism for
   their sensor information.  This is specially useful for battery
   constrained nodes that can make their data available in the cache
   provided by the overlay while in sleep mode.

Jimenez, et al.          Expires August 7, 2015                 [Page 4]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   For instance, a CoAP proxy (See Section 3) could register its Node-ID
   (e.g. "9996172") and a list of sensors (e.g. "/temperature-1;
   ./temperature-2; ./temperature-3") under its URI (e.g.
   "coap://overlay-1.com/proxy-1/").

   When a node wants to discover the values associated with that URI, it
   queries the overlay for "coap://overlay-1.com/proxy-1/" and gets back
   the Node-ID of the proxy and the list of its associated sensors.  The
   requesting node can then use the RELOAD overlay to establish a direct
   connection with the proxy and to read sensor values.

   Moreover, the CoAP proxy can store the sensor information in the
   overlay.  In this way information can be retrieved directly from the
   overlay without performing a direct connection to the storing proxy.

2.  Terminology

   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 [RFC2119].

   We use the terminology and definitions from the RELOAD Base Protocol
   [RFC6940] extensively in this document.  Some of those concepts are
   further described in the Concepts and Terminology for Peer to Peer
   SIP [I-D.ietf-p2psip-concepts] document.

3.  Architecture

   In our architecture we extend the different nodes present in RELOAD
   (Peer, Client) and add support for sensor devices or other
   constrained devices.  Figure 2 illustrates our architecture.  The
   different nodes, according to their functionality are :

   Client
      Devices that are capable of participating in a RELOAD overlay as
      client nodes, that is they do not route messages in the overlay.

   Router
      Devices that are members of (i.e., peers in) a RELOAD overlay and
      capable of forwarding RELOAD messages following a path through the
      overlay to the destination.

   Sensor
      Devices capable of measuring a physical quantity.  Sensors usually
      acquire quantifiable information about their surrounding
      environment such as: temperature, humidity, electric current,
      moisture, radiation, and so on.

Jimenez, et al.          Expires August 7, 2015                 [Page 5]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   Actuator
      Devices capable of interacting and affecting their environment
      such as: electrical motors, pneumatic actuators, electric
      switches, and so on.

   Proxy
      Devices having sufficient resources to run RELOAD either as client
      or peer.  These devices are located at the edge of the sensor
      network and, in case of Wireless Sensor Networks (WSN), act as
      coordinators of the network.

   Physical devices can have one or several of the previous functional
   roles.  According to the functionalities that are present in each of
   the nodes, they can be:

   Constrained Node
      A Constrained Node (CN) is a node with limited computational
      capabilities.  CN devices belong to classes of at least C1 and C2
      devices as defined in [RFC7228], their main constraint being the
      implementation of the CoAP protocol.  If the CN is wireless then
      it will be part of a Low-Rate Wireless Personal Area Network (LR-
      WPAN), also termed Low-Power and Lossy Network (LLN).  Lastly,
      devices will usually be in sleep mode in order to prevent battery
      drain, and will not communicate during those periods.  A CN is NOT
      part of the RELOAD overlay, therefore it can not act as a client,
      router nor proxy.  A CN is always either a either a Sensor or an
      Actuator.  In the latter case the node is often connected to a
      continuous energy power supply.

   RELOAD Node
      A Reload Node (RN) MUST implement the client functionality in the
      Overlay.  Additionally the node will often be a full RELOAD peer.
      A RN may also be sensor or actuator since it can have those
      devices connected to it.

   Proxy Node
      A Proxy Node (PN) MUST implement the RN functionality and act as a
      sink for the LR-WPAN network.  The PN connects the short range
      Wireless Network to the Wide Area Network or the Internet.

Jimenez, et al.          Expires August 7, 2015                 [Page 6]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

                        +------+
                        |      |
               +--------+  RN  +---------+
               |        |      |         |
           +---+--+     +------+      +--+---+
           |      |                   |      |
           |  RN  |                   |  RN  |
           |      |                   |      |   +------------+
           +---+--+                   +--+---+   |        WSN |
               |         RELOAD          |       |     +----+ |
               |         OVERLAY         |       | +---+ CN | |
           +---+--+                   +--+---+   | |   +----+ |
           |      |                   |      +-----+          |
           |  RN  |                   |  PN  |   |            |
           |      |                   |      +-----+          |
           +---+--+     +------+      +--+---+   | |   +----+ |
               |        |      |         |       | +---+ CN | |
               +--------+  PN  +---------+       |     +----+ |
                        |      |                 +------------+
                        +-+--+-+
                          |  |
                 +--------|--|--------+
                 |     +--+  +--+     |
                 |     |        |     |
                 |  +--+-+    +-+--+  |
                 |  | CN |    | CN |  |
                 |  +----+    +----+  |
                 |                WSN |
                 +--------------------+

                        Figure 2: Overlay Topology

4.  Registering CoAP URIs

   CoAP URIs are typically resolved using a DNS.  When CoAP is needed in
   a RELOAD environment, URI resolution is provided by the overlay as a
   whole.  Instead of registering a URI, a peer stores a
   CoAPRegistration structure under a hash of its own URI.  This uses
   the CoAP REGISTRATION Kind-ID, which is formally defined in
   Section 6, and that uses a DICTIONARY data model.

   As an example, if a CoAP proxy that is located in an overlay overlay-
   1.com using a Node-ID "9996172" wants to register three different
   temperature sensors to the URI "coap://overlay-1.com/proxy-1/.well-
   known/", it might store the following mapping in the overlay:

Jimenez, et al.          Expires August 7, 2015                 [Page 7]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

       Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/)
       KEY =    9996172,
       VALUE = {./temperature-1;
           ./temperature-2;
           ./temperature-3}

   Note that the Resource-ID stored in the overlay is calculated as hash
   over the URI (i.e. h(URI)), for instance SHA-1 in RELOAD.

   This would inform any other node performing a lookup for the previous
   URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value
   for proxy-1 is "9996172".  In addition, this mapping provides
   relevant information as to the number of sensors (CNs) and the URI
   path to connect to them using CoAP.

5.  Lookup

   The RELOAD overlay supports a rendezvous system that can be used for
   the lookup of other CoAP nodes.  This is done by fetching mapping
   information between CoAP URIs and Node-IDs.

   As an example, if a node RN located in the overlay overlay-1.com
   wishes to read which resources are served at a RN with URI
   coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay.
   The Resource-ID used in this fetch is a SHA-1 hash over the URI
   "coap://overlay-1.com/proxy-1/.well-known/".

   After this fetch request, the overlay will return the following
   result:

       Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/)
       KEY =    9996172,
       VALUE = { ./temperature-1;
             ./temperature-2;
             ./temperature-3}

   The obtained KEY is the Node-ID of the RN responsible of this KEY/
   VALUE pair.  The VALUE is the set of URIs necessary to read data from
   the CNs associated with the RN.

   Using the RELOAD DICTIONARY model allows for multiple nodes to
   perform a store to the same Resource-ID.  This feature allows to
   fetch multiple RNs that host CNs of the same class.

   As an example, a fetch to the URI "coap://overlay-1.com/
   temperature/.well-known/" could return the following results:

Jimenez, et al.          Expires August 7, 2015                 [Page 8]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

       Resource-ID = h(coap://overlay-1.com/temperature/.well-known/)
       KEY =    9992323,
       VALUE = { ./temperature}

       KEY =    9996172,
       VALUE = { ./temperature-1;
             ./temperature-2;
             ./temperature-3}

       KEY =   9996173,
       VALUE = { ./temp-a;
             ./temp-b}

6.  Forming a Direct Connection and Reading Data

   Once a RN (e.g., node-A) has obtained the lookup information for a
   node in the overlay (e.g., proxy-1), it can directly connect to that
   node.  This is performed by sending an AppAttach request to the Node-
   ID obtained during the lookup process.

   After the AppAttach negotiation, node-A can access to the values of
   the CNs at proxy-1 using the URIs obtained during the lookup.
   Following the example in Section 5, the URIs for accessing to the CNs
   at proxy-1 would be:

       coap://overlay-1.com/proxy-1/temperature-1
       coap://overlay-1.com/proxy-1/temperature-2
       coap://overlay-1.com/proxy-1/temperature-3

   Note that the ".well-known" string has been removed from the URIs, as
   this is only used during CNs discovery.  Figure 3 shows a sample of a
   node reading humidity data.

Jimenez, et al.          Expires August 7, 2015                 [Page 9]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   +---+         +-----+     +---------+    +-----+          +---+
   |CNA|         | PNA |     | OVERLAY |    | PNB |          |CNB|
   +---+         +-----+     +---------+    +-----+          +---+
    |               |             |            |                |
    | .COAP CON GET |             |            |                |
    |  /humidity    | 2.RELOAD    |            |                |
    |+------------->| FetchReq    |            |                |
    |               |+----------->|            |                |
    |               |             |            |                |
    |               | 3.RELOAD    |            |                |
    |               | FetchAns    |            |                |
    |               |<-----------+|            |                |
    |               |             |            |                |
    |               | 4.RELOAD    |            |                |
    |               |  AppAttach  |            |                |
    |               |+----------->|            |                |
    |               |             | 5.RELOAD   |                |
    |               |             | AppAttach  |                |
    |               |             |+---------->|                |
    |               |             |            |                |
    |               |             | 6.RELOAD   |                |
    |               | 7.RELOAD    |AppAttachAns|                |
    |               |AppAttachAns |<----------+|                |
    |               |<-----------+|            |                |
    |               |             |            |                |
    |               |                          |                |
    |               |   ---------------------  |                |
    |               | /        8.ICE          \|                |
    |               | \   connectivity checks /|                |
    |               |   ---------------------  |                |
    |               |                          |                |
    |               |      9.CoAP CON          |                |
    |               |        GET humidity      |                |
    |               |+------------------------>|                |
    |               |                          | 10.CoAP CON    |
    |               |                          |   GET humidity |
    |               |                          |+-------------->|
    |               |                          | 11.CoAP        |
    |               |     12.CoAP              |    ACK 200     |
    |  12.CoAP      |        ACK 200           |<--------------+|
    |     ACK 200   |<------------------------+|                |
    |<-------------+|                          |                |
    |               |                          |                |

                Figure 3: An Example of a Message Sequence

Jimenez, et al.          Expires August 7, 2015                [Page 10]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

7.  Caching Mechanisms

   The CoAP protocol itself supports the caching of sensor information
   in order to reduce the response time and network bandwidth
   consumption of future, equivalent requests.  CoAP caching is
   specified in the Section 5 of the CoAP RFC [RFC7228], it consists on
   reusing stored responses when new requests arrives.  This type of
   storage is done in CoAP proxies.

   This CoAP usage for RELOAD proposes an additional caching mechanism
   for storing sensor information directly in the overlay.  In order to
   do so, it is necessary to define how the data should be stored.  Such
   caching mechanism is primarily intended for CNs with sensor
   capabilities, not for RN sensors.  This is due to the battery
   constrains of CNs, forcing them to stay in sleep mode for long
   periods of time.

   Whenever a CN wakes up, it sends the most recent data from its
   sensors to its proxy (PN), which stores the data in the overlay using
   a RELOAD StoredData structure defined in Section 6 of the RELOAD RFC
   [RFC6940].  We use the StoredDataValue structure defined in
   Section 6.2 of the RELOAD RFC, in particular we use the SingleValue
   format type to store the cached values in the overlay.  From that
   structure length, storage_time, lifetime and Signature are used in
   the same way.  The only difference is DataValue which in our case can
   be either a ProxyCache or a SensorCache:

   enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) }
                   CoAPCachingType;
   struct {
       CoAPCachingType coap_caching_type;

       select(coap_caching_type) {
           case proxy_cache:   ProxyCache proxy_cache_entry;
           case sensor_cache:  SensorCache sensor_cache_entry;
           /* extensions */

       }
   } CoAPCaching;

7.1.  ProxyCache

   ProxyCache is meant to store values and sensor information (e.g.
   inactivity time) for all the sensors associated with a certain proxy,
   as well as their CoAP URIs.  On the other hand, SensorCache is used
   for storing the information and cached value of only one sensor (CoAP
   URI is not necessary, as is the same as the one used for generating
   the Resource-ID associated to that SensorCache entry).

Jimenez, et al.          Expires August 7, 2015                [Page 11]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   ProxyCache contains the fields Node-ID and series of SensorEntry
   types.

   struct {
       Node-ID     Node_ID;
       uint32      length;
       SensorEntry sensors[length];
   } ProxyCache;

   Node-D
      The Node-ID of the Proxy Node (PN) responsible for different
      sensor devices;

   length
      The length of the rest of the structure;

   Sensor-Entry
      List of sensors in the form of SensorEntry types;

   SensorEntry contains the coap_uri, sensor_info and a series of
   SensorValue types.

   struct {
       opaque      coap_uri;
       SensorInfo  sensor_info;
       uint32      length;
       SensorValue sensor_value[length];
   } SensorEntry;

   coap_uri
      CoAP name of the sensor device in question;

   sensor_info
      contains relevant sensor information;

   length
      The length of the rest of the structure;

   sensor_value
      contains a list of values stored by the sensor;

7.2.  SensorCache

   SensorCache: contains the information related to one sensor.

Jimenez, et al.          Expires August 7, 2015                [Page 12]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   struct {
       Node-ID     Node_ID;
       SensorInfo  sensor_info;
       uint32      length;
       SensorValue sensor_value[length];
   } SensorCache;

   Node_ID
      identifies the Node-ID of the Proxy Node responsible for the
      sensor;

   sensor_info
      contains relevant sensor information;

   length
      The length of the rest of the structure;

   sensor_value
      contains a list of values stored by the sensor;

   SensorInfo contains relevant sensor information, such as sensor_type,
   duration_of_inactivity and c fields.

   struct {
       uint32      sensor_type;
       uint32      duration_of_inactivity;
       uint32      last_awake;

       /* extensions */

   } SensorInfo;

   sensor_type
      contains the type of a resource as defined in [RFC6690], for
      example temperature, luminosity, etc.;

   duration_of_inactivity
      contains the sleep pattern (if any) that the sensor device
      follows, specified in seconds;

   last_awake
      indicates the last time that the sensor was awake represented as
      the number of milliseconds elapsed since midnight Jan 1, 1970 UTC
      not counting leap seconds.  This will have the same values for
      seconds as standard UNIX time or POSIX time;

   SensorValue contains the measurement_time, lifetime and value.

Jimenez, et al.          Expires August 7, 2015                [Page 13]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   struct {
       uint32      measurement_time;
       uint32      lifetime;
       opaque      value;

       /* extensions */

   } SensorValue;

   measurement_time
      indicates the moment in which the measure was taken represented as
      the number of milliseconds elapsed since midnight Jan 1, 1970 UTC
      not counting leap seconds;

   lifetime
      indicates the validity time of that measured value in milliseconds
      since measurement_time;

   value
      indicates the actual value measured.  It can be of different types
      (integer, long, string) therefore opaque has been used;

8.  CoAP Usage Kinds Definition

   This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds.

8.1.  CoAP-REGISTRATION Kind

   Kind IDs
      The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP
      URI.  The data stored is a CoAPRegistration, which contains a set
      of CoAP URIs.

   Data Model
      The data model for the CoAP-REGISTRATION Kind-ID is dictionary.
      The dictionary key is the Node-ID of the storing RN.  This allows
      each RN to store a single mapping.

   Access Control
      URI-NODE-MATCH.  The "coap:" prefix needs to be removed from the
      COAP URI before matching.  See Section 9.

   Data stored under the COAP-REGISTRATION kind is of type
   CoAPRegistration, defined below.

Jimenez, et al.          Expires August 7, 2015                [Page 14]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   struct {
       Node-ID Node_ID;
       uint16 coap_uris_length;
       opaque coap_uris (0..2^16-1);
   } CoAPRegistration;

8.2.  CoAP-CACHING Kind

   KindIDs
      The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI.
      The data stored is a CoAPCaching, which contains a cached value.

   Data Model
      The data model for the CoAP-CACHING Kind-ID is single value.

   Access Control
      URI-MATCH.  The "coap:" prefix needs to be removed from the COAP
      URI before matching.  See Section 9.

   Data stored under the CoAP-CACHING kind is of type CoAPCaching,
   defined in Section 7.

9.  Access Control Rules

   As specified in RELOAD base [RFC6940], every kind which is storable
   in an overlay must be associated with an access control policy.  This
   policy defines whether a request from a given node to operate on a
   given value should succeed or fail.  Usages can define any access
   control rules they choose, including publicly writable values.

   CoAP Usage for RELOAD requires an access control policy that allows
   multiple nodes in the overlay read and write access.  This access is
   for registering and caching information using CoAP URIs as
   identifiers.  Therefore, none of the access control policies
   specified in RELOAD base are sufficient .

   This document defines two access control policies , called URI-MATCH
   and URI-NODE-MATCH.  In URI-MATCH policy, a given value MUST be
   written and overwritten if and only if the signer's certificate has
   an associated URI which canonicalized form hashes (using the hash
   function for the overlay) to the Resource-ID for the resource.

   In URI-NODE-MATCH policy, a given value MUST be written and
   overwritten if and only if the signer's certificate has an associated
   URI which canonicalized form hashes (using the hash function for the
   overlay) to the Resource-ID for the resource.  In addition, the
   dictionary key MUST be equal to the Node-ID in the certificate and

Jimenez, et al.          Expires August 7, 2015                [Page 15]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   that Node-ID MUST be the one indicated in the SignerIdentity value
   cert_hash.

   These Access Control Policies are specified for IANA in
   Section Section 11.3.

10.  Security Considerations

   The security considerations of RELOAD [RFC6940] and CoAP [RFC7228]
   apply to this specification.  RELOAD's security model is based on
   public key certificates, which are used for signing messages and
   stored objects.  At the connection level RELOAD can use either TLS or
   DTLS.  In the case of CoAP, several security modes have been defined.
   Implementations of this specification MUST follow all the security-
   related rules specified in the RELOAD [RFC6940] and CoAP [RFC7228]
   specifications.

   Additionally, in RELOAD every kind which is storable in an overlay
   must be associated with an access control policy.  This document
   specifies two new access control policies, which are specified in
   Section Section 9.  These policies cover the most typical deployment
   scenarios.

   During the phase of registration and lookup, security considerations
   relevant to RELOAD apply.  The caching mechanism specified in this
   draft is additional to the caching already done in CoAP.  Access
   control is handled by the RELOAD overlay, where the peer storing the
   data is responsible of validating the signature on the data being
   stored.

11.  IANA Considerations

11.1.  CoAP-REGISTRATION Kind-ID

   This document introduces one additional data Kind-ID to the "RELOAD
   Data Kind-ID" Registry:

                   +-------------------+------------+----------+
                   | Kind              |    Kind-ID |      RFC |
                   +-------------------+------------+----------+
                   | CoAP-REGISTRATION |        105 | RFC-AAAA |
                   +-------------------+------------+----------+

   This Kind-ID was defined in Section 4.

Jimenez, et al.          Expires August 7, 2015                [Page 16]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

11.2.  CoAP-CACHING Kind-ID

   This document introduces one additional data Kind-ID to the "RELOAD
   Data Kind-ID" Registry:

                   +--------------+------------+----------+
                   | Kind         |    Kind-ID |      RFC |
                   +--------------+------------+----------+
                   | CoAP-CACHING |        106 | RFC-AAAA |
                   +--------------+------------+----------+

   This Kind-ID was defined in Section 4.

11.3.  Access Control Policies

   IANA SHALL create a "CoAP Usage for RELOAD Access Control Policy"
   Registry.  Entries in this registry are strings denoting access
   control policies, as described in Section 8.1.  New entries in this
   registry SHALL be registered via RFC 5226 [RFC5226].  Standards
   Action.  The initial contents of this registry are:

                   +-----------------+----------+
                   | Access Policy   |      RFC |
                   +-----------------+----------+
                   | URI-NODE-MATCH  | RFC-AAAA |
                   | URI-MATCH       | RFC-AAAA |
                   +-----------------+----------+

   This access control policy was described in Section 9.

12.  References

12.1.  Normative References

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

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

   [RFC6940]  Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
              Base Protocol", RFC 6940, January 2014.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

Jimenez, et al.          Expires August 7, 2015                [Page 17]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

12.2.  Informative References

   [I-D.ietf-p2psip-concepts]
              Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
              Dawkins, "Concepts and Terminology for Peer to Peer SIP",
              draft-ietf-p2psip-concepts-06 (work in progress), June
              2014.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228, May 2014.

Authors' Addresses

   Jaime Jimenez
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: jaime.jimenez@ericsson.com

   Jose M. Lopez-Vega
   University of Granada
   CITIC UGR Periodista Rafael Gomez Montero 2
   Granada  18071
   Spain

   Email: jmlvega@ugr.es

   Jouni Maenpaa
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: jouni.maenpaa@ericsson.com

Jimenez, et al.          Expires August 7, 2015                [Page 18]
Internet-Draft           A CoAP Usage for RELOAD           February 2015

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: gonzalo.camarillo@ericsson.com

Jimenez, et al.          Expires August 7, 2015                [Page 19]