One document matched: draft-jimenez-p2psip-coap-reload-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3621 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3621.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.ietf-p2psip-concepts SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-concepts.xml">
<!ENTITY I-D.ietf-p2psip-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-base.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc ipr="trust200902" docName="draft-jimenez-p2psip-coap-reload-04" category='std'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="A CoAP Usage for RELOAD">
A Constrained Application Protocol (CoAP) Usage for REsource LOcation
And Discovery (RELOAD)
</title>
<author initials="J" surname="Jimenez" fullname="Jaime Jimenez">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>jaime.jimenez@ericsson.com</email>
</address>
</author>
<author initials="J.M.L.V." surname="Lopez-Vega"
fullname="Jose M. Lopez-Vega">
<organization>University of Granada</organization>
<address>
<postal>
<street>CITIC UGR Periodista Rafael Gomez Montero 2</street>
<code>18071</code>
<city>Granada</city>
<country>Spain</country>
</postal>
<email>jmlvega@ugr.es</email>
</address>
</author>
<author initials="J.M." surname="Maenpaa"
fullname="Jouni Maenpaa">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>jouni.maenpaa@ericsson.com</email>
</address>
</author>
<author initials="G.C." surname="Camarillo"
fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>gonzalo.camarillo@ericsson.com</email>
</address>
</author>
<date year="2014" />
<area>RAI</area>
<workgroup>P2PSIP</workgroup>
<keyword>CoAP, RELOAD, Distributed Resource Directory</keyword>
<abstract>
<t>
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 also provides a rendezvous service for CoAP Nodes and caching of sensor information. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<t>
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol <xref target="I-D.ietf-core-coap"/>. 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.
</t>
<t>
The CoAP Usage for RELOAD allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a rendezvous 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 CoAP Usage involves three basic functions:
</t>
<t>
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.
</t>
<t>
Rendezvous: 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 direct connection which can be used to exchange CoAP messages.
</t>
<t>
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.
</t>
<t>
For instance, a CoAP proxy (See <xref target="sec-arc"/>) 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/").
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='terminology' title="Terminology">
<t>
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 <xref
target="RFC2119"/>.
</t>
<t>
We use the terminology and definitions from Concepts and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base Protocol [I-D.ietf-p2psip-base] extensively in this document.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec-arc' title="Architecture">
<t> In our architecture we extend the different nodes present in RELOAD (Peer, Client) and add support for sensor devices or other constrained devices. <xref target="fig-arc"/> illustrates our architecture. The different nodes, according to their functionality are :
<list style='hanging'>
<t hangText="Client"><vspace />
Devices that are capable of participating in a RELOAD overlay as client nodes, that is they do not route messages in the overlay.</t>
<t hangText="Router"><vspace />
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. </t>
<t hangText="Sensor"><vspace />
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.</t>
<t hangText="Actuator"><vspace />
Devices capable of interacting and affecting their environment such as: electrical motors, pneumatic actuators, electric switches, and so on.</t>
<t hangText="Proxy"><vspace />
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.</t>
</list>
</t>
<t> 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:
<list style='hanging'>
<t hangText="Constrained Node"><vspace />
A Constrained Node (CN) is a node with limited computational capabilities. If it is wireless then it will be part of a Low-Rate Wireless Personal Area Network (LR-WPAN), it might be movable and often offer unreliable connectivity. Also, 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.</t>
<t hangText="RELOAD Node"><vspace />
A Reload Node (RN) MUST implement the client functionality in the Overlay. Additionally the node will often be a full RELOAD peer with Proxy functionality. A RN may also be sensor or actuator since it can have those devices connected to it.</t>
</list>
</t>
<figure anchor="fig-arc" title="Architecture">
<artwork align="left"><![CDATA[
+------+
| |
+--------+ RN +---------+
| | | |
+---+--+ +------+ +--+---+
| | | |
| RN | | RN |
| | | | +------------+
+---+--+ +--+---+ | WSN |
| RELOAD | | +----+ |
| OVERLAY | | +---+ CN | |
+---+--+ +--+---+ | | +----+ |
| | | +-----+ |
| RN | | PN | | |
| | | +-----+ |
+---+--+ +------+ +--+---+ | | +----+ |
| | | | | +---+ CN | |
+--------+ PN +---------+ | +----+ |
| | +------------+
+-+--+-+
| |
+--------|--|--------+
| +--+ +--+ |
| | | |
| +--+-+ +-+--+ |
| | CN | | CN | |
| +----+ +----+ |
| WSN |
+--------------------+
]]>
</artwork>
</figure>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="sec-reg-uri" title="Registering CoAP URIs">
<t>
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 register 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 <xref target="sec-dir"/>, and that uses a DICTIONARY data model.
</t>
<t>
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:
</t>
<figure>
<artwork align="left"><![CDATA[
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/)
KEY = 9996172,
VALUE = {./temperature-1;
./temperature-2;
./temperature-3}
]]></artwork>
</figure>
<t>
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.
</t>
<t>
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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="sec-ren" title="Rendezvous">
<t>
The RELOAD overlay supports rendezvous by fetching mapping information between CoAP URIs and Node-IDs.
</t>
<t>
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/".
</t>
<t>
After this fetch request, the overlay will return the following result:
</t>
<figure>
<artwork align="left"><![CDATA[
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/)
KEY = 9996172,
VALUE = { ./temperature-1;
./temperature-2;
./temperature-3}
]]></artwork>
</figure>
<t>
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.
</t>
<t>
Using the RELOAD DICTIONARY model allows for multiple nodes to perform a store to the same Resource-ID. This feature allows for performing rendezvous with multiple RNs that host CNs of the same class.
</t>
<t>
As an example, a fetch to the URI "coap://overlay-1.com/temperature/.well-known/" could return the following results:
</t>
<figure>
<artwork align="left"><![CDATA[
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}
]]></artwork>
</figure>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="sec-dir" title="Forming a direct connection and reading data">
<t>
Once a RN (e.g., node-A) has obtained the rendezvous information for a node in the overlay (e.g., proxy-1), it can open a direct connection to that node. This is performed by sending an AppAttach request to the Node-ID obtained during the rendezvous process.
</t>
<t>
After the AppAttach negotiation, node-A can access to the values of the CNs at proxy-1 using the URIs obtained during the rendezvous. Following the example in Section 5, the URIs for accessing to the CNs at proxy-1 would be:
</t>
<t>
<figure>
<artwork align="left"><![CDATA[
coap://overlay-1.com/proxy-1/temperature-1
coap://overlay-1.com/proxy-1/temperature-2
coap://overlay-1.com/proxy-1/temperature-3
]]></artwork>
</figure>
</t>
<t>
Note that the ".well-known" string has been removed from the URIs, as this is only used during CNs discovery. <xref target="fig-arc"/> shows a sample of a node reading humidity data.
</t>
<figure title="An Example of a Message Sequence"
anchor="fig-sample">
<artwork>
<![CDATA[
+---+ +-----+ +---------+ +-----+ +---+
|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 |<------------------------+| |
|<-------------+| | |
| | | |
]]>
</artwork>
</figure>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="sec-cach" title="Caching Mechanisms">
<t>
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. This storage is done in CoAP proxies.
</t>
<t>
This CoAP usage proposes an additional caching mechanism for storing sensor information directly in the overlay. This 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.
</t>
<t>
Whenever a CN wakes up, it sends the most recent data from its sensors to its proxy (RN), which stores the data in the overlay using a RELOAD StoredData structure defined in Section 6 of the RELOAD base draft <xref target="I-D.ietf-p2psip-base"/>. We use the StoredDataValue structure defined in Section 6.2 of the RELOAD base draft, 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:
</t>
<t>
<figure>
<artwork align="left"><![CDATA[
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;
]]></artwork>
</figure>
</t>
<section title="ProxyCache">
<t>
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).
</t>
<t>
ProxyCache contains the fields Node-ID and series of SensorEntry types.
<figure>
<artwork align="left"><![CDATA[
struct {
Node-ID Node_ID;
uint32 length;
SensorEntry sensors[length];
} ProxyCache;
]]></artwork>
</figure>
</t>
<t>
<list style='hanging'>
<t hangText="Node-D"><vspace /> The Node-ID of the Proxy Node (PN) responsible for different sensor devices;</t>
<t hangText="length"><vspace /> The length of the rest of the structure;</t>
<t hangText="Sensor-Entry"><vspace /> List of sensors in the form of SensorEntry types;</t>
</list>
</t>
<t>
SensorEntry contains the coap_uri, sensor_info and a series of SensorValue types.
<figure>
<artwork align="left"><![CDATA[
struct {
opaque coap_uri;
SensorInfo sensor_info;
uint32 length;
SensorValue sensor_value[length];
} SensorEntry;
]]></artwork>
</figure>
</t>
<t>
<list style='hanging'>
<t hangText="coap_uri"><vspace blankLines='0' />CoAP name of the sensor device in question;</t>
<t hangText="sensor_info"><vspace blankLines='0' />contains relevant sensor information;</t>
<t hangText="length"><vspace blankLines='0' />The length of the rest of the structure;</t>
<t hangText="sensor_value"><vspace blankLines='0' />contains a list of values stored by the sensor;</t>
</list>
</t>
</section>
<section title="SensorCache">
<t>
SensorCache: contains the information related to one sensor.
<figure>
<artwork align="left"><![CDATA[
struct {
Node-ID Node_ID;
SensorInfo sensor_info;
uint32 length;
SensorValue sensor_value[length];
} SensorCache;
]]></artwork>
</figure>
</t>
<t>
<list style='hanging'>
<t hangText="Node_ID"><vspace blankLines='0' />identifies the Node-ID of the Proxy Node responsible for the sensor;</t>
<t hangText="sensor_info"><vspace blankLines='0' />contains relevant sensor information;</t>
<t hangText="length"><vspace blankLines='0' />The length of the rest of the structure;</t>
<t hangText="sensor_value"><vspace blankLines='0' />contains a list of values stored by the sensor;</t>
</list>
</t>
<t>
SensorInfo contains relevant sensor information, such as sensor_type, duration_of_inactivity and c fields.
<figure>
<artwork align="left"><![CDATA[
struct {
integer sensor_type;
uint32 duration_of_inactivity;
uint32 last_awake;
/* extensions */
} SensorInfo;
]]></artwork>
</figure>
</t>
<t>
<list style='hanging'>
<t hangText="sensor_type"><vspace blankLines='0' />is an integer identifying the type of the sensor. See <xref target="fig-sens"/>;</t>
<t hangText="duration_of_inactivity"><vspace blankLines='0' />contains the sleep pattern (if any) that the sensor device follows, specified in seconds;</t>
<t hangText="last_awake"><vspace blankLines='0' />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;</t>
</list>
</t>
<t>
SensorValue contains the measurement_time, lifetime and value.
<figure>
<artwork align="left"><![CDATA[
struct {
uint32 measurement_time;
uint32 lifetime;
opaque value;
/* extensions */
} SensorValue;
]]></artwork>
</figure>
</t>
<t>
<list style='hanging'>
<t hangText="measurement_time"><vspace blankLines='0' />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;</t>
<t hangText="lifetime"><vspace blankLines='0' />indicates the validity time of that measured value in milliseconds since measurement_time;</t>
<t hangText="value"><vspace blankLines='0' />indicates the actual value measured. It can be of different types (integer, long, string) therefore opaque has been used;</t>
</list>
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="sec-kind" title="CoAP Usage Kinds Definition">
<t>
This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds.
</t>
<section title="CoAP-REGISTRATION Kind">
<t>
<list style='hanging'>
<t hangText="Kind IDs"><vspace blankLines='0' />
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.
</t>
<t hangText="Data Model"><vspace blankLines='0' />
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.
</t>
<t hangText="Access Control"><vspace blankLines='0' />
URI-NODE-MATCH. The "coap:" prefix needs to be removed from the COAP URI before matching. See <xref target="sec-rules"/>.
</t>
</list>
</t>
<t>
Data stored under the COAP-REGISTRATION kind is of type
CoAPRegistration, defined below.
<figure>
<artwork align="left"><![CDATA[
struct {
Node-ID Node_ID;
uint16 coap_uris_length;
opaque coap_uris (0..2^16-1);
} CoAPRegistration;
]]></artwork>
</figure>
</t>
</section>
<section title="CoAP-CACHING Kind">
<t><list style='hanging'>
<t hangText="KindIDs"><vspace blankLines='0' /> The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI. The data stored is a CoAPCaching, which contains a cached value. </t>
<t hangText="Data Model"><vspace blankLines='0' />The data model for the CoAP-CACHING Kind-ID is single value.
</t>
<t hangText="Access Control"><vspace blankLines='0' />URI-MATCH. The "coap:" prefix needs to be removed from the COAP URI before matching. See <xref target="sec-rules"/>.
</t>
</list>
</t>
<t>
Data stored under the CoAP-CACHING kind is of type CoAPCaching, defined in <xref target="sec-cach"/>.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Access Control Rules"
anchor="sec-rules">
<t>
As specified in RELOAD base <xref target="I-D.ietf-p2psip-base"/>, 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.
</t>
<t>
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 <xref target="I-D.ietf-p2psip-base"/>.
</t>
<t>
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.
</t>
<t>
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 that Node-ID MUST be the one indicated in the SignerIdentity value cert_hash.
</t>
<t>
These Access Control Policies are specified for IANA in Section <xref target="sec-access-control"/>.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Security Considerations"
anchor="sec-security">
<t>
TBD.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA Considerations" anchor="sec-iana">
<section title="RELOAD Sensor Type Registry">
<t>
IANA SHALL create a "RELOAD sensor type" Registry. Entries in this registry are 16-bit integers denoting method codes as described in Section 7. The initial contents of this registry are:
</t>
<t>
<figure anchor="fig-sens">
<artwork>
+-----------------+-------+
| Code Name | Value |
+-----------------+-------+
| temperature | 0 |
| humidity | 1 |
| acceleration | 2 |
| pressure | 3 |
| altitude | 4 |
| luminance | 5 |
| velocity | 6 |
| signal_strength | 7 |
| battery | 8 |
| heart_rate | 9 |
+-----------------+-------+
</artwork>
</figure>
</t>
</section>
<section title="CoAP-REGISTRATION Kind-ID">
<t>
This document introduces one additional data Kind-ID to the "RELOAD
Data Kind-ID" Registry:
</t>
<t>
<figure> <artwork>
+-------------------+------------+----------+
| Kind | Kind-ID | RFC |
+-------------------+------------+----------+
| CoAP-REGISTRATION | 105 | RFC-AAAA |
+-------------------+------------+----------+
</artwork></figure>
</t>
<t>
This Kind-ID was defined in <xref target="sec-reg-uri"/>.
</t>
</section>
<section title="CoAP-CACHING Kind-ID">
<t>
This document introduces one additional data Kind-ID to the "RELOAD
Data Kind-ID" Registry:
</t>
<t>
<figure> <artwork>
+--------------+------------+----------+
| Kind | Kind-ID | RFC |
+--------------+------------+----------+
| CoAP-CACHING | 106 | RFC-AAAA |
+--------------+------------+----------+
</artwork></figure>
</t>
<t>
This Kind-ID was defined in <xref target="sec-reg-uri"/>.
</t>
</section>
<section title="Access Control Policies" anchor= "sec-access-control">
<t>
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 <xref target="RFC5226"/>. Standards Action. The initial contents of this registry are:
</t>
<t>
<figure> <artwork>
+-----------------+----------+
| Access Policy | RFC |
+-----------------+----------+
| URI-NODE-MATCH | RFC-AAAA |
| URI-MATCH | RFC-AAAA |
+-----------------+----------+
</artwork></figure>
</t>
<t>
This access control policy was described in <xref target="sec-rules"/>.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&I-D.ietf-core-coap;
&I-D.ietf-p2psip-concepts;
&I-D.ietf-p2psip-base;
</references>
<references title="Informative References">
&RFC3621;
&RFC5226;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 01:35:07 |