idnits 2.17.1 draft-jimenez-t2trg-drd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 43 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2018) is 2230 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.brandt-coap-subnet-discovery' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'I-D.vanderstok-core-bc' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 476, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 T2TRG J. Jimenez 3 Internet-Draft Ericsson 4 Intended status: Standards Track M. Liu 5 Expires: September 20, 2018 E. Harjula 6 University of Oulu 7 March 19, 2018 9 A Distributed Resource Directory (DRD) 10 draft-jimenez-t2trg-drd-00 12 Abstract 14 NB: This document was submitted in 2013 and then discontinued. It is 15 now submitted to T2TRG for discussion on the replication of the 16 Resource Directory. References and many operations would need 17 updating. Architecture and functions should remain the same. 19 In some M2M scenarios, it is convenient to offer non-centralized 20 alternatives for discovery and rendezvous. This document defines a 21 Distributed Resource Directory (DRD) for Constrained Application 22 Protocol (CoAP). Distribution is achieved by means of a structured 23 Peer-to-Peer (P2P) overlay. The DHT-based P2P overlay provides 24 discovery, rendezvous and caching services for CoAP End-points as 25 well as HTTP proxy service for Web clients. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 20, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. DRD Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Distributed Resource Directory Function Set . . . . . . . . . 5 66 6. Registration . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8. Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . 8 70 10. Get Data (resource values) from Endpoint via DHT . . . . . . 9 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 74 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 15.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 15.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 CoAP is a specialized Web transfer protocol that can be used not only 83 between nodes on the same constrained network but also between 84 constrained nodes and other nodes on the Internet. The latter is 85 possible since CoAP can be translated into Hypertext Transfer 86 Protocol (HTTP) for integration with the Web. 88 The discovery of resources offered by a constrained server is very 89 important in machine-to-machine applications and it is dealt in CoAP 90 by the Resource Directory (RD) [I-D.shelby-core-resource-directory]. 91 RD uses Web Linking for discovering resources in CoAP servers as 92 specified by the CoRE Link Format [RFC6690] and Web Linking 93 [RFC5988]. When used globally the RD is not sufficient if we want to 94 independently access small portions of the RD database. 96 This document specifies the interfaces to a DHT and specifies how to 97 use DHT capabilities to enable a distributed Resource Directory. The 98 peer-to-peer overlay provides 1) a rendezvous service, 2) enables the 99 use of the overlay as a cache for sensor data, and 3) provides HTTP- 100 proxying functionality. The mentioned functionalities can be 101 implemented in the overlay itself, without the use of centralized 102 servers. The use of a DHT provides some useful properties for M2M, 103 such as autonomy, low deployment cost and enhanced network failure 104 tolerance and scalability. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. The term 111 "byte" is used in its now customary sense as a synonym for "octet". 113 This specification requires readers to be familiar with all the terms 114 and concepts that are discussed in [RFC5988] and [RFC6690]. Readers 115 should also be familiar with the terms and concepts discussed in 116 [I-D.ietf-core-coap]. The URI Template format is used to describe 117 the REST interfaces defined in this specification [RFC6570]. This 118 specification uses the following additional terminology: 120 HTTP Client 121 HTTP Clients are clients that send out requests to resource 122 directory using HTTP messages. 124 CoAP Client 125 CoAP clients are CoAP entities that send out requests to resource 126 directory using CoAP messages. 128 3. Architecture 130 The Distributed Resource Directory (DRD) architecture is shown in 131 Figure 1. It provides the same REST interfaces as the centralized 132 Resource Directory (RD) does. Endpoints are physical nodes that may 133 run one or more CoAP servers, and can use REST operations such as 134 POST and GET in the DRD. Endpoints can also act as clients. In this 135 case we name them CoAP Clients. There can be also traditional or 136 legacy HTTP Clients that need to access the resources stored in the 137 DRD. The different nodes, according to their functionality are: 139 Endpoints (EP) 140 Endpoint (EP) is an entity that lives on a "Node" and communicates 141 using the CoAP protocol. A CoAP endpoint can be the source or 142 destination of a CoAP message. 144 Peers 145 Peers (P) are full overlay member nodes, capable of forwarding 146 messages following a path through the overlay to the destination. 147 Some Peers can also act as HTTP Proxies (see next). In other 148 words, beside acting as a peer, the node also acts as a proxy for 149 protocol translation. 151 HTTP Proxy 152 A HTTP Proxy (HP) is capable of running both HTTP and CoAP 153 protocols, as well as performing translation between the two. 155 HTTP Clients 156 HTTP Clients are clients that send out requests to a resource 157 directory using HTTP messages. 159 CoAP Clients 160 CoAP clients are CoAP entities that send out requests to a 161 resource directory using CoAP messages. 163 Registration Lookup 164 | | 165 +----+ CoAP | +---+ +----+ | HTTP +--------+ 166 | EP |----- | | P |-----| HP | | -----| Client | 167 +----+ | +---+ +----+ | +--------+ 168 +----+ CoAP | | | | 169 | EP |----- | ---- | DRD | ---- | 170 +----+ | | | | 171 +----+ CoAP | +---+ +---+ | CoAP +--------+ 172 | EP |----- | | P |-----| P | | -----| Client | 173 +----+ | +---+ +---+ | +--------+ 175 Figure 1: The Distributed Resource Directory architecture. 177 4. DRD Discovery 179 Before an endpoint (EP) can register its resources into the DRD, it 180 needs to find an entry point to the DRD. The initial entry point can 181 be any peer connected to the DRD. There are a number of ways for 182 finding an entry point. One method is to use a well-known multicast 183 address, where the endpoint sends a POST request to a well-known 184 address to get the information of the DRD. Other ways include 185 finding the nearest DRD EP or the dynamic discovery of the DRD. 187 5. Distributed Resource Directory Function Set 189 This section defines the interfaces between an endpoint and a DRD 190 peer. The interface is called the Resource Directory Function Set. 191 This section also describes the operations required in the DHT to 192 realize the REST operations that a RD implements. We assume that EPs 193 implement CoAP [I-D.ietf-core-coap] and optionally HTTP [RFC2616] 194 protocols. 196 6. Registration 198 In registration, EP sends a CoAP POST message that must contain the 199 list of resources (in the payload of the message), to register its 200 resources into the DRD. When a peer (P) (that runs a DHT algorithm 201 to participate in the DRD overlay) receives a registration message, 202 it stores the CoAP Registration structure under the hash of its CoAP 203 URI in the DHT. The payload of the CoAP Registration is stored as 204 the value into the overlay. After getting the DHT ACK message, the 205 peer sends back a COAP ACK message back to the EP to indicate the 206 resource is registered into the DRD. 208 The POST request should include a query string parameter to indicate 209 the name of the endpoint, which is used to uniquely identify the 210 endpoint (it could be a node or a device). The endpoint name setting 211 has different alternatives. One method is to hash the MAC address of 212 the device to generate the endpoint name. Another method is to use 213 common names. The sequence diagram is shown below. 215 As an example, if an endpoint with name "9996172" wants to register 216 two different temperature descriptions into the DRD, the endpoint 217 sends a POST request with the URI "coap://overlay-1.com/proxy- 218 1/.well-known/core?ep=9996172".The temperature descriptions are 219 included in the payload of the message. An example of the 220 registration message is given below. 222 +---+ +---+ +-----+ 223 |EP | | P | | DHT | 224 +---+ +---+ +-----+ 225 | | | 226 | CoAP POST | | 227 | (URI ) | Store | 228 |+------------->| h(URI), VALUE| 229 | |+------------>| 230 | | | 231 | | | 232 | | | 233 | | | 234 | | Store ACK | 235 | 2.01 ACK |<------------+| 236 |<-------------+| | 237 | | | 239 Req: POST coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172 240 Payload: 241 ;ct=41;rt="TemperatureC";if="sensor", 242 ;ct=41;rt="LightLux";if="sensor" 244 The peer in the resource directory stores the following mapping in 245 the overlay: 247 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172) 248 KEY = 9996172, 249 VALUE = {<./temperature-1>;ct=41;rt="TemperatureC";if="sensor", <./temperature-2>;ct=41;rt="LightLux";if="sensor",} 251 Note that the Resource-ID stored in the overlay is calculated as hash 252 over the URI (i.e. h(URI)), for instance SHA-1. 254 This action informs any other node performing a lookup for the 255 previous URI "coap://overlay-1.com/proxy-1/.well-known/ 256 core?ep=9996172" that the Node-ID value for peer is "9996172". 258 7. Discovery 260 Endpoints discover resources The DRD also supports rendezvous by 261 fetching the mapping information between CoAP URIs and Node-IDs to 262 get the address information of resources. Specifically, an 263 endpoint sends a CoAP GET request to the DRD, including the URI 264 information of requested resource. The DRD peer (handling this 265 request) performs a DHT Lookup for the hash of the COAP URI. The 266 DHT then finds the peer that is responsible for the value of the 267 resource. The destination peer returns the stored value to the 268 peer (P). Finally, P sends back the content (i.e., stored value) 269 back to the endpoint. The sequence diagram is shown below. 271 +---+ +---+ +-----+ 272 |EP | | P | | DHT | 273 +---+ +---+ +-----+ 274 | | | 275 | CoAP GET | | 276 | (URI) | Lookup | 277 |+------------->| h(URI) | 278 | |+------------>| 279 | | | 280 | | | 281 | | | 282 | | Lookup Reply | 283 | | (Content) | 284 | 2.05 Content |<------------+| 285 |<-------------+| | 286 | | | 288 As an example, if a peer located in the overlay overlay-1.com wishes 289 to retrieve the resources with URI coap://overlay-1.com/proxy- 290 1/.well-known/core?ep=9996172, it performs DHT Lookup operation in 291 the overlay. The Resource-ID used in this lookup is a SHA-1 hash 292 over the URI "coap://overlay-1.com/proxy-1/.well-known/ 293 core?ep=9996172". 295 As a response to this fetch request, the overlay returns the 296 following result: 298 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172) 299 KEY = 9996172, 300 VALUE = {<./temperature-1>;ct=41;rt="TemperatureC";if="sensor", 301 ? ? ? ?<./temperature-2>;ct=41;rt="LightLux";if="sensor",} 303 The obtained KEY is the Node-ID of the peer that is responsible of 304 this KEY/VALUE pair. The VALUE is the set of resource descriptions 305 that are necessary to read data from the endpoints. 307 Req: GET coap://overlay-1.com/proxy-1/.well-known/core?ep=9996172 309 Response Payload: 310 ;ct=41;rt="TemperatureC";if="sensor", 311 ;ct=41;rt="LightLux";if="sensor" 313 8. Update 315 In addtion, EP can send a CoAP PUT message to update its resources 316 into the DRD. When receiving the PUT message, the P performs a DHT 317 Store operation to update the CoAP message structure under the hash 318 of its CoAP URI. The payload of the CoAP Registration is stored as 319 the the new value into the overlay. After receiving the ACK message, 320 P sends a COAP Changed message back to the EP to indicate the 321 resource was updated into the DRD. The sequence diagram is shown 322 below. 324 +---+ +---+ +-----+ 325 |EP | | P | | DHT | 326 +---+ +---+ +-----+ 327 | | | 328 | CoAP PUT | | 329 | (URI ) | Store | 330 |+------------->| h(URI), VALUE| 331 | |+------------>| 332 | | | 333 | | | 334 | | | 335 | | | 336 | | Store ACK | 337 | 2.04 Changed |<------------+| 338 |<-------------+| | 339 | | | 341 9. Caching Mechanisms 343 The CoAP protocol itself supports caching of resource values in order 344 to reduce the response time and network bandwidth consumption of 345 future equivalent requests. This storage can be done in CoAP 346 endpoints and CoAP proxies. Herein, CoAP proxies mean the CoAP 347 endpoints that perform requests on behalf of CoAP clients. 349 +---+ +---+ +-----+ 350 |HC | | P | | DHT | 351 +---+ +---+ +-----+ 352 | | | 353 | HTTP GET | | 354 | (CONTENT URI) | Lookup | 355 |+------------->| h(URI) | 356 | |+------------>| 357 | | | 358 | | | 359 | | | 360 | | Lookup Reply | 361 | | (Data ) | 362 | HTTP Reply |<------------+| 363 |<-------------+| | 364 | | | 366 10. Get Data (resource values) from Endpoint via DHT 368 The DRD also supports fetching data (i.e., resource values) from 369 endpoints. Specifically, if an endpoint EP1 wants to get the data 370 provided by another endpoint EP2, EP1 firsts sends a GET request to 371 peer P1 in the DRD. P1 then performs DHT Lookup operation to find 372 the destination peer (in this case P2) that is responsible for 373 managing EP2. P2 then sends a CoAP GET request to get the data 374 provided by the endpoint EP2. After getting the data provided by 375 EP2, P2 sends the data back to P1, which in turn sends it back to the 376 EP1. The sequence diagram is shown below. 378 +---+ +---+ +-----+ +---+ +---+ 379 |EP1| |P1 | | DHT | |P2 | |EP2| 380 +---+ +---+ +-----+ +---+ +---+ 381 | | | | | 382 | GET | | | | 383 | (CONTENT) | Lookup | | | 384 |+------------->| h(CONTENT) | GET | | 385 | |+-------------> | (CONTENT) | GET | 386 | | |+------------>| (CONTENT) | 387 | | | |+------------>| 388 | | | | 389 | | | 2.05 Content | 390 | | 2.05 Content |<------------+| 391 | 2.05 Content |<-----------------------------+| | 392 |<-------------+| | | 393 | | | | 395 11. Security Considerations 397 This document needs the same security considerations as described in 398 Section 7 of [RFC5988] and Section 6 of [RFC6690]. The /.well-known/ 399 core resource may be protected e.g. using DTLS when hosted on a CoAP 400 server as described in [I-D.ietf-core-coap]. 402 Access control SHOULD be performed separately for the RD Function Set 403 and the RD Lookup Function Set, as different endpoints may be 404 authorized to register with an RD from those authorized to lookup 405 endpoints from the RD. Such access control SHOULD be performed in as 406 fine-grained a level as possible. For example access control for 407 lookups could be performed either at the domain, endpoint or resource 408 level. 410 12. IANA Considerations 412 "core.rd", "core.rd-group" and "core.rd-lookup" resource types need 413 to be registered with the resource type registry defined by 414 [RFC6690]. 416 The "exp" attribute needs to be registered when a future Web Linking 417 attribute is created. 419 13. Acknowledgments 421 This work was carried out in the MAMMotH project funded by Tekes, the 422 Finnish Funding Agency for Technology and Innovation. 424 14. Changelog 426 15. References 428 15.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 432 RFC2119, March 1997, . 435 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/ 436 RFC5988, October 2010, . 439 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 440 and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/ 441 RFC6570, March 2012, . 444 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 445 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 446 . 448 15.2. Informative References 450 [I-D.brandt-coap-subnet-discovery] 451 Brandt, A., "Discovery of CoAP servers across subnets", 452 draft-brandt-coap-subnet-discovery-00 (work in progress), 453 March 2011. 455 [I-D.ietf-core-coap] 456 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 457 Application Protocol (CoAP)", draft-ietf-core-coap-18 458 (work in progress), June 2013. 460 [I-D.shelby-core-resource-directory] 461 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 462 Directory", draft-shelby-core-resource-directory-05 (work 463 in progress), February 2013. 465 [I-D.vanderstok-core-bc] 466 Stok, P. and K. Lynn, "CoAP Utilization for Building 467 Control", draft-vanderstok-core-bc-05 (work in progress), 468 October 2011. 470 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 471 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 472 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 473 RFC2616, June 1999, . 476 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 477 Bormann, "Neighbor Discovery Optimization for IPv6 over 478 Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 479 6775, DOI 10.17487/RFC6775, November 2012, 480 . 482 Authors' Addresses 484 Jaime Jimenez 485 Ericsson 486 Hirsalantie 11 487 Jorvas 02420 488 FINLAND 490 Phone: +358442992827 491 Email: jaime.jimenez@ericsson.com 492 Meirong Liu 493 University of Oulu 494 Erkki Koiso-Kanttilan Katu 3 495 University of Oulu 90014 496 FINLAND 498 Email: meiliu@ee.oulu.fi 500 Erkki Harjula 501 University of Oulu 502 Erkki Koiso-Kanttilan Katu 3 503 University of Oulu 90014 504 FINLAND 506 Phone: +358503030478 507 Email: erkki.harjula@ee.oulu.fi