| P2PSIP | J. Jimenez |
| Internet-Draft | Ericsson |
| Intended status: Standards Track | J. Lopez-Vega |
| Expires: August 2, 2015 | University of Granada |
| J. Maenpaa | |
| G. Camarillo | |
| Ericsson | |
| January 29, 2015 |
A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)
draft-jimenez-p2psip-coap-reload-06
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.
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 2, 2015.
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.
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 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.
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.
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.
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 Concepts and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base Protocol [RFC6940] extensively in this document.
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 :
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:
+------+ | | +--------+ RN +---------+ | | | | +---+--+ +------+ +--+---+ | | | | | RN | | RN | | | | | +------------+ +---+--+ +--+---+ | WSN | | RELOAD | | +----+ | | OVERLAY | | +---+ CN | | +---+--+ +--+---+ | | +----+ | | | | +-----+ | | RN | | PN | | | | | | +-----+ | +---+--+ +------+ +--+---+ | | +----+ | | | | | | +---+ CN | | +--------+ PN +---------+ | +----+ | | | +------------+ +-+--+-+ | | +--------|--|--------+ | +--+ +--+ | | | | | | +--+-+ +-+--+ | | | CN | | CN | | | +----+ +----+ | | WSN | +--------------------+
Figure 2: Overlay Topology
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:
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.
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:
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}
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.
+---+ +-----+ +---------+ +-----+ +---+ |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
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;
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).
struct {
Node-ID Node_ID;
uint32 length;
SensorEntry sensors[length];
} ProxyCache;
ProxyCache contains the fields Node-ID and series of SensorEntry types.
struct {
opaque coap_uri;
SensorInfo sensor_info;
uint32 length;
SensorValue sensor_value[length];
} SensorEntry;
SensorEntry contains the coap_uri, sensor_info and a series of SensorValue types.
struct {
Node-ID Node_ID;
SensorInfo sensor_info;
uint32 length;
SensorValue sensor_value[length];
} SensorCache;
SensorCache: contains the information related to one sensor.
struct {
uint32 sensor_type;
uint32 duration_of_inactivity;
uint32 last_awake;
/* extensions */
} SensorInfo;
SensorInfo contains relevant sensor information, such as sensor_type, duration_of_inactivity and c fields.
struct {
uint32 measurement_time;
uint32 lifetime;
opaque value;
/* extensions */
} SensorValue;
SensorValue contains the measurement_time, lifetime and value.
This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds.
struct {
Node-ID Node_ID;
uint16 coap_uris_length;
opaque coap_uris (0..2^16-1);
} CoAPRegistration;
Data stored under the COAP-REGISTRATION kind is of type CoAPRegistration, defined below.
Data stored under the CoAP-CACHING kind is of type CoAPCaching, defined in Section 7.
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 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.
TBD.
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.
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.
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.
| [I-D.ietf-p2psip-concepts] | Bryan, D., Matthews, P., Shim, E., Willis, D. and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", Internet-Draft draft-ietf-p2psip-concepts-06, June 2014. |
| [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. |
| [RFC7228] | Bormann, C., Ersue, M. and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014. |
| [RFC7252] | Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |