Internet DRAFT - draft-jimenez-distributed-resource-directory
draft-jimenez-distributed-resource-directory
CoRE J. Jimenez
Internet-Draft Ericsson
Intended status: Standards Track M. Liu
Expires: January 16, 2014 E. Harjula
University of Oulu
July 15, 2013
A Distributed Resource Directory (DRD)
draft-jimenez-distributed-resource-directory-00
Abstract
In some M2M scenarios, it is convenient to offer non-centralized
alternatives for discovery and rendezvous. This document defines a
Distributed Resource Directory (DRD) for Constrained Application
Protocol (CoAP). Distribution is achieved by means of a structured
Peer-to-Peer (P2P) overlay. The DHT-based P2P overlay provides
discovery, rendezvous and caching services for CoAP End-points as
well as HTTP proxy service for Web clients.
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 January 16, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Jimenez, et al. Expires January 16, 2014 [Page 1]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3
4. DRD Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Distributed Resource Directory Function Set . . . . . . . . . 4
6. Registration . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . 8
10. Get Data (resource values) from Endpoint via DHT . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
15.1. Normative References . . . . . . . . . . . . . . . . . . 10
15.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
CoAP is a specialized Web transfer protocol that can be used not only
between nodes on the same constrained network but also between
constrained nodes and other nodes on the Internet. The latter is
possible since CoAP can be translated into Hypertext Transfer
Protocol (HTTP) for integration with the Web.
The discovery of resources offered by a constrained server is very
important in machine-to-machine applications and it is dealt in CoAP
by the Resource Directory (RD) [I-D.shelby-core-resource-directory].
RD uses Web Linking for discovering resources in CoAP servers as
specified by the CoRE Link Format [RFC6690] and Web Linking
[RFC5988]. When used globally the RD is not sufficient if we want to
independently access small portions of the RD database.
This document specifies the interfaces to a DHT and specifies how to
use DHT capabilities to enable a distributed Resource Directory. The
peer-to-peer overlay provides 1) a rendezvous service, 2) enables the
use of the overlay as a cache for sensor data, and 3) provides HTTP-
proxying functionality. The mentioned functionalities can be
implemented in the overlay itself, without the use of centralized
Jimenez, et al. Expires January 16, 2014 [Page 2]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
servers. The use of a DHT provides some useful properties for M2M,
such as autonomy, low deployment cost and enhanced network failure
tolerance and scalability.
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 [RFC2119]. The term
"byte" is used in its now customary sense as a synonym for "octet".
This specification requires readers to be familiar with all the terms
and concepts that are discussed in [RFC5988] and [RFC6690]. Readers
should also be familiar with the terms and concepts discussed in
[I-D.ietf-core-coap]. The URI Template format is used to describe
the REST interfaces defined in this specification [RFC6570]. This
specification uses the following additional terminology:
HTTP Client
HTTP Clients are clients that send out requests to resource
directory using HTTP messages.
CoAP Client
CoAP clients are CoAP entities that send out requests to resource
directory using CoAP messages.
3. Architecture
The Distributed Resource Directory (DRD) architecture is shown in
Figure 1. It provides the same REST interfaces as the centralized
Resource Directory (RD) does. Endpoints are physical nodes that may
run one or more CoAP servers, and can use REST operations such as
POST and GET in the DRD. Endpoints can also act as clients. In this
case we name them CoAP Clients. There can be also traditional or
legacy HTTP Clients that need to access the resources stored in the
DRD. The different nodes, according to their functionality are:
Endpoints (EP)
Endpoint (EP) is an entity that lives on a "Node" and communicates
using the CoAP protocol. A CoAP endpoint can be the source or
destination of a CoAP message.
Peers
Peers (P) are full overlay member nodes, capable of forwarding
messages following a path through the overlay to the destination.
Some Peers can also act as HTTP Proxies (see next). In other
words, beside acting as a peer, the node also acts as a proxy for
protocol translation.
Jimenez, et al. Expires January 16, 2014 [Page 3]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
HTTP Proxy
A HTTP Proxy (HP) is capable of running both HTTP and CoAP
protocols, as well as performing translation between the two.
HTTP Clients
HTTP Clients are clients that send out requests to a resource
directory using HTTP messages.
CoAP Clients
CoAP clients are CoAP entities that send out requests to a
resource directory using CoAP messages.
Registration Lookup
| |
+----+ CoAP | +---+ +----+ | HTTP +--------+
| EP |----- | | P |-----| HP | | -----| Client |
+----+ | +---+ +----+ | +--------+
+----+ CoAP | | | |
| EP |----- | ---- | DRD | ---- |
+----+ | | | |
+----+ CoAP | +---+ +---+ | CoAP +--------+
| EP |----- | | P |-----| P | | -----| Client |
+----+ | +---+ +---+ | +--------+
Figure 1: The Distributed Resource Directory architecture.
4. DRD Discovery
Before an endpoint (EP) can register its resources into the DRD, it
needs to find an entry point to the DRD. The initial entry point can
be any peer connected to the DRD. There are a number of ways for
finding an entry point. One method is to use a well-known multicast
address, where the endpoint sends a POST request to a well-known
address to get the information of the DRD. Other ways include
finding the nearest DRD EP or the dynamic discovery of the DRD.
5. Distributed Resource Directory Function Set
This section defines the interfaces between an endpoint and a DRD
peer. The interface is called the Resource Directory Function Set.
This section also describes the operations required in the DHT to
realize the REST operations that a RD implements. We assume that EPs
implement CoAP [I-D.ietf-core-coap] and optionally HTTP [RFC2616]
protocols.
Jimenez, et al. Expires January 16, 2014 [Page 4]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
6. Registration
In registration, EP sends a CoAP POST message that must contain the
list of resources (in the payload of the message), to register its
resources into the DRD. When a peer (P) (that runs a DHT algorithm
to participate in the DRD overlay) receives a registration message,
it stores the CoAP Registration structure under the hash of its CoAP
URI in the DHT. The payload of the CoAP Registration is stored as
the value into the overlay. After getting the DHT ACK message, the
peer sends back a COAP ACK message back to the EP to indicate the
resource is registered into the DRD.
The POST request should include a query string parameter to indicate
the name of the endpoint, which is used to uniquely identify the
endpoint (it could be a node or a device). The endpoint name setting
has different alternatives. One method is to hash the MAC address of
the device to generate the endpoint name. Another method is to use
common names. The sequence diagram is shown below.
As an example, if an endpoint with name "9996172" wants to register
two different temperature descriptions into the DRD, the endpoint
sends a POST request with the URI "coap://overlay-1.com/proxy-1/
.well-known/core?ep=9996172".The temperature descriptions are
included in the payload of the message. An example of the
registration message is given below.
+---+ +---+ +-----+
|EP | | P | | DHT |
+---+ +---+ +-----+
| | |
| CoAP POST | |
| (URI ) | Store |
|+------------->| h(URI), VALUE|
| |+------------>|
| | |
| | |
| | |
| | |
| | Store ACK |
| 2.01 ACK |<------------+|
|<-------------+| |
| | |
Jimenez, et al. Expires January 16, 2014 [Page 5]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
Req: POST coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172
Payload:
</temperature-1>;ct=41;rt="TemperatureC";if="sensor",
</temperature-2>;ct=41;rt="LightLux";if="sensor"
The peer in the resource directory stores the following mapping in
the overlay:
<artwork>
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172)
KEY = 9996172,
VALUE = {<./temperature-1>;ct=41;rt="TemperatureC";if="sensor", <./temperature-2>;ct=41;rt="LightLux";if="sensor",}
Note that the Resource-ID stored in the overlay is calculated as hash
over the URI (i.e. h(URI)), for instance SHA-1.
This action informs any other node performing a lookup for the
previous URI "coap://overlay-1.com/proxy-1/.well-known/
core?ep=9996172" that the Node-ID value for peer is "9996172".
7. Discovery
The DRD also supports rendezvous by fetching the mapping information
between CoAP URIs and Node-IDs to get the address information of
resources. Specifically, an endpoint sends a CoAP GET request to the
DRD, including the URI information of requested resource. The DRD
peer (handling this request) performs a DHT Lookup for the hash of
the COAP URI. The DHT then finds the peer that is responsible for
the value of the resource. The destination peer returns the stored
value to the peer (P). Finally, P sends back the content (i.e.,
stored value) back to the endpoint. The sequence diagram is shown
below.
+---+ +---+ +-----+
|EP | | P | | DHT |
+---+ +---+ +-----+
| | |
| CoAP GET | |
| (URI) | Lookup |
|+------------->| h(URI) |
| |+------------>|
| | |
| | |
Jimenez, et al. Expires January 16, 2014 [Page 6]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
| | |
| | Lookup Reply |
| | (Content) |
| 2.05 Content |<------------+|
|<-------------+| |
| | |
As an example, if a peer located in the overlay overlay-1.com wishes
to retrieve the resources with URI coap://overlay-1.com/proxy-1/
.well-known/core?ep=9996172, it performs DHT Lookup operation in the
overlay. The Resource-ID used in this lookup is a SHA-1 hash over
the URI "coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172".
As a response to this fetch request, the overlay returns the
following result:
<artwork>
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172)
KEY = 9996172,
VALUE = {<./temperature-1>;ct=41;rt="TemperatureC";if="sensor",
? ? ? ?<./temperature-2>;ct=41;rt="LightLux";if="sensor",}
The obtained KEY is the Node-ID of the peer that is responsible of
this KEY/VALUE pair. The VALUE is the set of resource descriptions
that are necessary to read data from the endpoints.
Req: GET coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172
Response Payload:
</temperature-1>;ct=41;rt="TemperatureC";if="sensor",
</temperature-2>;ct=41;rt="LightLux";if="sensor"
8. Update
In addtion, EP can send a CoAP PUT message to update its resources
into the DRD. When receiving the PUT message, the P performs a DHT
Store operation to update the CoAP message structure under the hash
of its CoAP URI. The payload of the CoAP Registration is stored as
the the new value into the overlay. After receiving the ACK message,
P sends a COAP Changed message back to the EP to indicate the
resource was updated into the DRD. The sequence diagram is shown
below.
Jimenez, et al. Expires January 16, 2014 [Page 7]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
+---+ +---+ +-----+
|EP | | P | | DHT |
+---+ +---+ +-----+
| | |
| CoAP PUT | |
| (URI ) | Store |
|+------------->| h(URI), VALUE|
| |+------------>|
| | |
| | |
| | |
| | |
| | Store ACK |
| 2.04 Changed |<------------+|
|<-------------+| |
| | |
9. Caching Mechanisms
The CoAP protocol itself supports caching of resource values in order
to reduce the response time and network bandwidth consumption of
future equivalent requests. This storage can be done in CoAP
endpoints and CoAP proxies. Herein, CoAP proxies mean the CoAP
endpoints that perform requests on behalf of CoAP clients.
+---+ +---+ +-----+
|HC | | P | | DHT |
+---+ +---+ +-----+
| | |
| HTTP GET | |
| (CONTENT URI) | Lookup |
|+------------->| h(URI) |
| |+------------>|
| | |
| | |
| | |
| | Lookup Reply |
| | (Data ) |
| HTTP Reply |<------------+|
|<-------------+| |
| | |
Jimenez, et al. Expires January 16, 2014 [Page 8]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
10. Get Data (resource values) from Endpoint via DHT
The DRD also supports fetching data (i.e., resource values) from
endpoints. Specifically, if an endpoint EP1 wants to get the data
provided by another endpoint EP2, EP1 firsts sends a GET request to
peer P1 in the DRD. P1 then performs DHT Lookup operation to find
the destination peer (in this case P2) that is responsible for
managing EP2. P2 then sends a CoAP GET request to get the data
provided by the endpoint EP2. After getting the data provided by
EP2, P2 sends the data back to P1, which in turn sends it back to the
EP1. The sequence diagram is shown below.
+---+ +---+ +-----+ +---+ +---+
|EP1| |P1 | | DHT | |P2 | |EP2|
+---+ +---+ +-----+ +---+ +---+
| | | | |
| GET | | | |
| (CONTENT) | Lookup | | |
|+------------->| h(CONTENT) | GET | |
| |+-------------> | (CONTENT) | GET |
| | |+------------>| (CONTENT) |
| | | |+------------>|
| | | |
| | | 2.05 Content |
| | 2.05 Content |<------------+|
| 2.05 Content |<-----------------------------+| |
|<-------------+| | |
| | | |
11. Security Considerations
This document needs the same security considerations as described in
Section 7 of [RFC5988] and Section 6 of [RFC6690]. The /.well-known/
core resource may be protected e.g. using DTLS when hosted on a CoAP
server as described in [I-D.ietf-core-coap].
Access control SHOULD be performed separately for the RD Function Set
and the RD Lookup Function Set, as different endpoints may be
authorized to register with an RD from those authorized to lookup
endpoints from the RD. Such access control SHOULD be performed in as
fine-grained a level as possible. For example access control for
lookups could be performed either at the domain, endpoint or resource
level.
12. IANA Considerations
Jimenez, et al. Expires January 16, 2014 [Page 9]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
"core.rd", "core.rd-group" and "core.rd-lookup" resource types need
to be registered with the resource type registry defined by
[RFC6690].
The "exp" attribute needs to be registered when a future Web Linking
attribute is created.
13. Acknowledgments
This work was carried out in the MAMMotH project funded by Tekes, the
Finnish Funding Agency for Technology and Innovation.
14. Changelog
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, March 2012.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012.
15.2. Informative References
[I-D.brandt-coap-subnet-discovery]
Brandt, A., "Discovery of CoAP servers across subnets",
draft-brandt-coap-subnet-discovery-00 (work in progress),
March 2011.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.shelby-core-resource-directory]
Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource
Directory", draft-shelby-core-resource-directory-05 (work
in progress), February 2013.
[I-D.vanderstok-core-bc]
Jimenez, et al. Expires January 16, 2014 [Page 10]
Internet-Draft A Distributed Resource Directory (DRD) July 2013
Stok, P. and K. Lynn, "CoAP Utilization for Building
Control", draft-vanderstok-core-bc-05 (work in progress),
October 2011.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012.
Authors' Addresses
Jaime Jimenez
Ericsson
Hirsalantie 11
Jorvas 02420
FINLAND
Phone: +358442992827
Email: jaime.j.jimenez@ericsson.com
Meirong Liu
University of Oulu
Erkki Koiso-Kanttilan Katu 3
University of Oulu 90014
FINLAND
Email: meiliu@ee.oulu.fi
Erkki Harjula
University of Oulu
Erkki Koiso-Kanttilan Katu 3
University of Oulu 90014
FINLAND
Phone: +358503030478
Email: erkki.harjula@ee.oulu.fi
Jimenez, et al. Expires January 16, 2014 [Page 11]
