doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc7650.txt b/doc/rfc/rfc7650.txt
new file mode 100644
index 0000000..0451b65
--- /dev/null
+++ b/doc/rfc/rfc7650.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Jimenez
+Request for Comments: 7650                                      Ericsson
+Category: Standards Track                                  J. Lopez-Vega
+ISSN: 2070-1721                                    University of Granada
+                                                              J. Maenpaa
+                                                            G. Camarillo
+                                                                Ericsson
+                                                          September 2015
+
+
+            A Constrained Application Protocol (CoAP) Usage
+              for REsource LOcation And Discovery (RELOAD)
+
+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
+   (WSNs) 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 is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7650.
+
+
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.              Standards Track                    [Page 1]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   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 . . . . . . . . . . . . . . . . . . . . . . .  13
+   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 . . . . . . . . . . . . . . . . . . . . .  17
+     11.1.  CoAP-REGISTRATION Kind-ID  . . . . . . . . . . . . . . .  17
+     11.2.  CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . .  17
+     11.3.  Access Control Policies  . . . . . . . . . . . . . . . .  17
+   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
+     12.1.  Normative References . . . . . . . . . . . . . . . . . .  18
+     12.2.  Informative References . . . . . . . . . . . . . . . . .  18
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19
+
+
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.              Standards Track                    [Page 2]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+1.  Introduction
+
+   The Constrained Application Protocol (CoAP) Usage for REsource
+   LOcation And Discovery (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.
+
+   This usage is intended for interconnected devices over a wide-area
+   geographical coverage, such as in cases where multiple Wireless
+   Sensor Networks (WSNs) need to be federated over some wider-area
+   network.  These WSNs would interconnect by means of nodes that are
+   equipped with long range modules (e.g., 2G, 3G, 4G) as well as short
+   range ones (e.g., XBee, ZigBee, Bluetooth LE).
+
+   Constrained 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, which 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
+   machine-to-machine (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.  It provides a layered architecture with pluggable
+   application layers that 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.              Standards Track                    [Page 3]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 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 that can use the RELOAD data storage
+   functionality, can store a mapping from their CoAP URI to their Node-
+   ID in the overlay.  They can also retrieve the Node-IDs of other
+   nodes.  Nodes that are not RELOAD aware can use other mechanisms, for
+   example [CORERESDIR] in their local network.
+
+   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 that can be used to exchange CoAP messages.
+   Similarly as with the registration, nodes that are not RELOAD aware
+   can use CoAP messages with a RELOAD Node (RN) that will in turn
+   perform the lookup in the overlay.
+
+
+
+
+
+Jimenez, et al.              Standards Track                    [Page 4]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+   Caching: Nodes can use the RELOAD overlay as a caching mechanism for
+   information about what CoAP resources are available on the node.
+   This is especially useful for power-constrained nodes that can make
+   their data available in the cache provided by the overlay while in
+   sleep mode.
+
+   For instance, a CoAP proxy (See Section 3) could register its Node-ID
+   (e.g. "9996172") and a list of sensors (e.g. "/sensors/temp-1;
+   /sensors/temp-2; /sensors/light, /sensors/humidity") 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" [P2PSIP] 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 the overlay topology.  The
+   different nodes, according to their functionality, are:
+
+   Client
+      As specified in [RFC6940], clients are nodes that do not have
+      routing or storage responsibilities in the Overlay.
+
+   Peer
+      As specified in [RFC6940], peers are nodes in the overlay that can
+      route messages for nodes other than those to which it is directly
+      connected.
+
+
+
+
+Jimenez, et al.              Standards Track                    [Page 5]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+   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.
+
+   Actuator
+      Devices capable of interacting and affecting their environment
+      such as: electrical motors, pneumatic actuators, electric
+      switches, and so on.
+
+   Proxy Node
+      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 cannot act as a client,
+      peer, nor proxy.  A CN is always 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.
+      An 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.  A
+      Proxy Node fulfills the "Proxy Node" role as described previously
+      in the Architecture.
+
+
+
+
+Jimenez, et al.              Standards Track                    [Page 6]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 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 8.1 and uses a DICTIONARY data model.
+
+   In this example, a CoAP proxy that is located in an overlay
+   overlay-1.com using a Node-ID "9996172" wants to register four
+   different sensors to the URI "coap://overlay-1.com/proxy-1/.well-
+   known/".  We will be using the link format specified in [RFC6690] to
+   store the following mapping in the overlay:
+
+
+
+
+
+Jimenez, et al.              Standards Track                    [Page 7]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+    Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/)
+    KEY =  9996172,
+
+    VALUE = [
+     </sensors/temp-1>;rt="temperature-c";if="sensor",
+     </sensors/temp-2>;rt="temperature-c";if="sensor",
+     </sensors/light>;rt="light-lux";if="sensor",
+     </sensors/humidity>;rt="humidity-p";if="sensor"
+        ]
+
+   Note that the Resource-ID stored in the overlay is calculated as hash
+   over the URI, that is -- h(URI), which in RELOAD is usually SHA-1.
+
+   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 an 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 = [
+     </sensors/temp-1>;rt="temperature-c";if="sensor",
+     </sensors/temp-2>;rt="temperature-c";if="sensor",
+     </sensors/light>;rt="light-lux";if="sensor",
+     </sensors/humidity>;rt="humidity-p";if="sensor"
+     ]
+
+   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.
+
+
+
+
+Jimenez, et al.              Standards Track                    [Page 8]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+   Using the RELOAD DICTIONARY model allows for multiple nodes to
+   perform a store to the same Resource-ID.  This can be used, for
+   example, to perform a store of resources of the same type or with
+   similar characteristics.  After performing a lookup, this feature
+   allows the fetching of those multiple RNs that host CNs of the same
+   class.
+
+   As an example, provided that the previous peer (9996172) and another
+   peer (9996173) have stored the links to their respective temperature
+   resources in this same Resource-ID (temperature), an RN (e.g.,
+   node-A) can do a fetch to the URI "coap://overlay-1.com/
+   temperature/.well-known/", obtaining the following results:
+
+    Resource-ID = h(coap://overlay-1.com/temperature/.well-known/)
+
+    KEY =  9996172,
+    VALUE = [
+     </sensors/temp-1>;rt="temperature-c";if="sensor",
+     </sensors/temp-2>;rt="temperature-c";if="sensor",
+      ]
+
+    KEY = 9996173,
+    VALUE = [
+     </sensors/temp-a>;rt="temperature-c";if="sensor",
+           </sensors/temp-b>;rt="temperature-c";if="sensor"
+      ]
+
+6.  Forming a Direct Connection and Reading Data
+
+   Once an 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 the values of the
+   CNs at proxy-1 using the information obtained during the lookup.
+   Following the example in Section 5, and according to [RFC6690], the
+   requests for accessing the CNs at proxy-1 would be:
+
+    REQ: GET /sensors/temp-1
+    REQ: GET /sensors/temp-2
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.              Standards Track                    [Page 9]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+   Figure 3 shows a sample of a node reading temperature data.
+
+   +-----+     +---------+    +-----+          +---+
+   | PNA |     | OVERLAY |    | PNB |          |CNB|
+   +-----+     +---------+    +-----+          +---+
+      |             |            |                |
+      |             |            |                |
+      | 1.RELOAD    |            |                |
+      | FetchReq    |            |                |
+      |+----------->|            |                |
+      |             |            |                |
+      | 2.RELOAD    |            |                |
+      | FetchAns    |            |                |
+      |<-----------+|            |                |
+      |             |            |                |
+      | 3.RELOAD    |            |                |
+      |  AppAttach  |            |                |
+      |+----------->|            |                |
+      |             | 4.RELOAD   |                |
+      |             | AppAttach  |                |
+      |             |+---------->|                |
+      |             |            |                |
+      |             | 5.RELOAD   |                |
+      | 6.RELOAD    |AppAttachAns|                |
+      |AppAttachAns |<----------+|                |
+      |<-----------+|            |                |
+      |             |            |                |
+      |                          |                |
+      |   ---------------------  |                |
+      | /        7.ICE          \|                |
+      | \   connectivity checks /|                |
+      |   ---------------------  |                |
+      |                          |                |
+      |      8.CoAP CON          |                |
+      |    GET /sensors/temp-1   |                |
+      |+------------------------>|                |
+      |                          |  9.CoAP  GET   |
+      |                          |/sensors/temp-1 |
+      |                          |+-------------->|
+      |                          | 10.CoAP        |
+      |     11.CoAP              |    ACK 200     |
+      |        ACK 200           |<--------------+|
+      |<------------------------+|                |
+      |                          |                |
+
+                Figure 3: An Example of a Message Sequence
+
+
+
+
+
+Jimenez, et al.              Standards Track                   [Page 10]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 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 Section 5 of [RFC7252].  It consists of reusing stored
+   responses when new requests arrive.  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
+   constraints 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 [RFC6940].  We
+   use the StoredDataValue structure defined in Section 6.2 of
+   [RFC6940], 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.  SensorCache, on the other hand, is used
+   for storing the information and cached value of only one sensor (CoAP
+   URI is not necessary, as it is the same as the one used for
+   generating the Resource-ID associated to that SensorCache entry).
+
+
+
+Jimenez, et al.              Standards Track                   [Page 11]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+   ProxyCache contains the Node-ID, length, and a series of SensorEntry
+   types.
+
+   struct {
+    Node-ID  Node_ID;
+    uint32   length;
+    SensorEntry sensors[count];
+   } ProxyCache;
+
+   Node-ID
+      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[count];
+   } 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;
+
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.              Standards Track                   [Page 12]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+7.2.  SensorCache
+
+   SensorCache: contains the information related to one sensor.
+
+   struct {
+    Node-ID  Node_ID;
+    SensorInfo sensor_info;
+    uint32  length;
+    SensorValue sensor_value[count];
+   } 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 that is dependent on
+   the use case.  As an example, we use the sensor manufacturer as
+   relevant information.
+
+   struct {
+    opaque  dev_info;
+
+    /* extensions */
+
+   } SensorInfo;
+
+   dev_info
+      Contains specific device information as defined in [RFC6690] --
+      for example, temperature, luminosity, etc.  It can also represent
+      other semantic information about the device.
+
+   SensorValue contains the measurement_time, lifetime, and value of the
+   measurement.
+
+
+
+
+
+
+
+
+
+Jimenez, et al.              Standards Track                   [Page 13]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+   struct {
+    uint32  measurement_time;
+    uint32  lifetime;
+    opaque  value;
+
+    /* extensions */
+
+   } SensorValue;
+
+   measurement_time
+      indicates the moment when 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.
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.              Standards Track                   [Page 14]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+   Data stored under the COAP-REGISTRATION Kind is of type
+   CoAPRegistration, defined below.
+
+   struct {
+    Node-ID Node_ID;
+    uint16 coap_uris_length;
+    opaque coap_uris (0..2^16-1);
+   } CoAPRegistration;
+
+8.2.  CoAP-CACHING Kind
+
+   Kind-IDs
+      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.
+
+   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 that 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 [RFC6940] are sufficient.
+
+   This document defines two access control policies, called URI-MATCH
+   and URI-NODE-MATCH.  In the URI-MATCH policy, a given value MUST be
+   written and overwritten if and only if the signer's certificate
+   contains an uniformResourceIdentifier entry in the subjectAltName
+   Extension [RFC5280] that in canonicalized form hashes to the
+   Resource-ID for the resource.  As explained in Section 6.3 of
+   [RFC7252] the "coap" and "coaps" schemes conform to the generic URI,
+   thus they are normalized in the generic form as explained in
+
+
+
+
+Jimenez, et al.              Standards Track                   [Page 15]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+   Section 6 of [RFC3986].  The hash function used is specified in
+   Section 10.2 of [RFC6940].  The certificate can be generated as
+   specified in Section 9 of [RFC7252], using Certificate mode.
+
+   In the URI-NODE-MATCH policy, a given value MUST be written and
+   overwritten if and only if the condition for URI-MATCH is met and, in
+   addition, the dictionary key is equal to the Node-ID in the
+   certificate and that Node-ID is the one indicated in the
+   SignerIdentity value cert_hash.
+
+   These Access Control Policies are specified for IANA in Section 11.3.
+
+10.  Security Considerations
+
+   The security considerations of RELOAD [RFC6940] and CoAP [RFC7252]
+   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
+   [RFC7252] specifications.
+
+   Additionally, in RELOAD every Kind that 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 9.  These policies cover the most typical deployment
+   scenarios.
+
+   During the phase of registration and lookup, security considerations
+   relevant to RELOAD apply.  A CoAP node that advertises its existence
+   via this mechanism, is more likely to be attacked, compared to a node
+   (especially a sleepy node) that does not advertise its existence.
+   Section 11 of [RFC7252] and Section 13 of [RFC6940] have more
+   information about the kinds of attack and mitigation possible.
+
+   The caching mechanism specified in this document 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 for
+   validating the signature on the data being stored.
+
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.              Standards Track                   [Page 16]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+11.  IANA Considerations
+
+11.1.  CoAP-REGISTRATION Kind-ID
+
+   This document introduces a data Kind-ID to the "RELOAD Data Kind-ID"
+   registry:
+
+       +-------------------+------------+----------+
+       | Kind              |    Kind-ID |      RFC |
+       +-------------------+------------+----------+
+       | CoAP-REGISTRATION |      0x105 | RFC 7650 |
+       +-------------------+------------+----------+
+
+   This Kind-ID was defined in Section 8.1.
+
+11.2.  CoAP-CACHING Kind-ID
+
+   This document introduces another data Kind-ID to the "RELOAD Data
+   Kind-ID" registry:
+
+       +--------------+------------+----------+
+       | Kind         |    Kind-ID |      RFC |
+       +--------------+------------+----------+
+       | CoAP-CACHING |      0x106 | RFC 7650 |
+       +--------------+------------+----------+
+
+   This Kind-ID was defined in Section 8.2.
+
+11.3.  Access Control Policies
+
+   IANA has created a "CoAP Usage for RELOAD Access Control Policy"
+   registry.  This registry has been added to the existing RELOAD
+   registry.  Entries in this registry are strings denoting access
+   control policies, as described in Section 9.  New entries in this
+   registry are to be registered per the Specification Required policy
+   in [RFC5226].  The initial contents of this registry are:
+
+       +-----------------+----------+
+       | Access Policy   |      RFC |
+       +-----------------+----------+
+       | URI-NODE-MATCH  | RFC 7650 |
+       | URI-MATCH       | RFC 7650 |
+       +-----------------+----------+
+
+   This access control policy was described in Section 9.
+
+
+
+
+
+
+Jimenez, et al.              Standards Track                   [Page 17]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <http://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
+              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
+              <http://www.rfc-editor.org/info/rfc6690>.
+
+   [RFC6940]  Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
+              and H. Schulzrinne, "REsource LOcation And Discovery
+              (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
+              January 2014, <http://www.rfc-editor.org/info/rfc6940>.
+
+   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
+              Application Protocol (CoAP)", RFC 7252,
+              DOI 10.17487/RFC7252, June 2014,
+              <http://www.rfc-editor.org/info/rfc7252>.
+
+12.2.  Informative References
+
+   [CORERESDIR]
+              Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
+              Resource Directory", Work in Progress, draft-ietf-core-
+              resource-directory-04, July 2015.
+
+   [P2PSIP]   Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
+              Dawkins, "Concepts and Terminology for Peer to Peer SIP",
+              Work in Progress, draft-ietf-p2psip-concepts-07, May 2015.
+
+
+
+
+
+
+
+Jimenez, et al.              Standards Track                   [Page 18]
+
+RFC 7650                 A CoAP Usage for RELOAD          September 2015
+
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
+              Constrained-Node Networks", RFC 7228,
+              DOI 10.17487/RFC7228, May 2014,
+              <http://www.rfc-editor.org/info/rfc7228>.
+
+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
+
+
+   Gonzalo Camarillo
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   Email: gonzalo.camarillo@ericsson.com
+
+
+
+
+
+Jimenez, et al.              Standards Track                   [Page 19]
+