T2TRG J. Jimenez Internet-Draft Ericsson Intended status: Standards Track M. Liu Expires: September 20, 2018 E. Harjula University of Oulu March 19, 2018 A Distributed Resource Directory (DRD) draft-jimenez-t2trg-drd-00 Abstract NB: This document was submitted in 2013 and then discontinued. It is now submitted to T2TRG for discussion on the replication of the Resource Directory. References and many operations would need updating. Architecture and functions should remain the same. 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 September 20, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Jimenez, et al. Expires September 20, 2018 [Page 1] Internet-Draft A Distributed Resource Directory (DRD) March 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 4. DRD Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Distributed Resource Directory Function Set . . . . . . . . . 5 6. Registration . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . 8 10. Get Data (resource values) from Endpoint via DHT . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 15.1. Normative References . . . . . . . . . . . . . . . . . . 10 15.2. Informative References . . . . . . . . . . . . . . . . . 11 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. Jimenez, et al. Expires September 20, 2018 [Page 2] Internet-Draft A Distributed Resource Directory (DRD) March 2018 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 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. Jimenez, et al. Expires September 20, 2018 [Page 3] Internet-Draft A Distributed Resource Directory (DRD) March 2018 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. 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. Jimenez, et al. Expires September 20, 2018 [Page 4] Internet-Draft A Distributed Resource Directory (DRD) March 2018 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. 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. Jimenez, et al. Expires September 20, 2018 [Page 5] Internet-Draft A Distributed Resource Directory (DRD) March 2018 +---+ +---+ +-----+ |EP | | P | | DHT | +---+ +---+ +-----+ | | | | CoAP POST | | | (URI ) | Store | |+------------->| h(URI), VALUE| | |+------------>| | | | | | | | | | | | | | | Store ACK | | 2.01 ACK |<------------+| |<-------------+| | | | | Req: POST coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172 Payload: ;ct=41;rt="TemperatureC";if="sensor", ;ct=41;rt="LightLux";if="sensor" The peer in the resource directory stores the following mapping in the overlay: 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 Endpoints discover resources 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 Jimenez, et al. Expires September 20, 2018 [Page 6] Internet-Draft A Distributed Resource Directory (DRD) March 2018 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) | | |+------------>| | | | | | | | | | | | 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: 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: ;ct=41;rt="TemperatureC";if="sensor", ;ct=41;rt="LightLux";if="sensor" Jimenez, et al. Expires September 20, 2018 [Page 7] Internet-Draft A Distributed Resource Directory (DRD) March 2018 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. +---+ +---+ +-----+ |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. Jimenez, et al. Expires September 20, 2018 [Page 8] Internet-Draft A Distributed Resource Directory (DRD) March 2018 +---+ +---+ +-----+ |HC | | P | | DHT | +---+ +---+ +-----+ | | | | HTTP GET | | | (CONTENT URI) | Lookup | |+------------->| h(URI) | | |+------------>| | | | | | | | | | | | Lookup Reply | | | (Data ) | | HTTP Reply |<------------+| |<-------------+| | | | | 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 |<-----------------------------+| | |<-------------+| | | | | | | Jimenez, et al. Expires September 20, 2018 [Page 9] Internet-Draft A Distributed Resource Directory (DRD) March 2018 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 "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, DOI 10.17487/ RFC2119, March 1997, . [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/ RFC5988, October 2010, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/ RFC6570, March 2012, . Jimenez, et al. Expires September 20, 2018 [Page 10] Internet-Draft A Distributed Resource Directory (DRD) March 2018 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, 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] 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, DOI 10.17487/ RFC2616, June 1999, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . Authors' Addresses Jaime Jimenez Ericsson Hirsalantie 11 Jorvas 02420 FINLAND Phone: +358442992827 Email: jaime.jimenez@ericsson.com Jimenez, et al. Expires September 20, 2018 [Page 11] Internet-Draft A Distributed Resource Directory (DRD) March 2018 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 September 20, 2018 [Page 12]