--- 1/draft-ietf-core-resource-directory-20.txt 2019-06-13 03:13:39.093647797 -0700 +++ 2/draft-ietf-core-resource-directory-21.txt 2019-06-13 03:13:39.225651135 -0700 @@ -1,24 +1,24 @@ CoRE Z. Shelby Internet-Draft ARM Intended status: Standards Track M. Koster -Expires: September 12, 2019 SmartThings +Expires: December 15, 2019 SmartThings C. Bormann Universitaet Bremen TZI P. van der Stok consultant C. Amsuess, Ed. - March 11, 2019 + June 13, 2019 CoRE Resource Directory - draft-ietf-core-resource-directory-20 + draft-ietf-core-resource-directory-21 Abstract In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the @@ -36,21 +36,21 @@ 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 https://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 12, 2019. + This Internet-Draft will expire on December 15, 2019. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,21 +64,21 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 6 3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 7 3.3. RD Content Model . . . . . . . . . . . . . . . . . . . . 8 3.4. Link-local addresses and zone identifiers . . . . . . . . 12 3.5. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 12 3.6. Use Case: Home and Building Automation . . . . . . . . . 13 - 3.7. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 13 + 3.7. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 14 4. RD discovery and other interface-independent components . . . 14 4.1. Finding a Resource Directory . . . . . . . . . . . . . . 15 4.1.1. Resource Directory Address Option (RDAO) . . . . . . 17 4.2. Payload Content Formats . . . . . . . . . . . . . . . . . 18 4.3. URI Discovery . . . . . . . . . . . . . . . . . . . . . . 19 5. Registration . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Simple Registration . . . . . . . . . . . . . . . . . . . 26 5.2. Third-party registration . . . . . . . . . . . . . . . . 28 5.3. Operations on the Registration Resource . . . . . . . . . 28 5.3.1. Registration Update . . . . . . . . . . . . . . . . . 29 @@ -115,29 +115,29 @@ 10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 52 10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 54 10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 54 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 54 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 13.1. Normative References . . . . . . . . . . . . . . . . . . 63 13.2. Informative References . . . . . . . . . . . . . . . . . 64 Appendix A. Groups Registration and Lookup . . . . . . . . . . . 66 Appendix B. Web links and the Resource Directory . . . . . . . . 67 - B.1. A simple example . . . . . . . . . . . . . . . . . . . . 67 + B.1. A simple example . . . . . . . . . . . . . . . . . . . . 68 B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 68 B.1.2. Interpreting attributes and relations . . . . . . . . 68 B.2. A slightly more complex example . . . . . . . . . . . . . 69 B.3. Enter the Resource Directory . . . . . . . . . . . . . . 69 B.4. A note on differences between link-format and Link headers . . . . . . . . . . . . . . . . . . . . . . . . . 71 Appendix C. Limited Link Format . . . . . . . . . . . . . . . . 72 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 1. Introduction In the work on Constrained RESTful Environments (CoRE), a REST architecture suitable for constrained nodes (e.g. with limited RAM and ROM [RFC7228]) and networks (e.g. 6LoWPAN [RFC4944]) has been established and is used in Internet-of-Things (IoT) or machine-to- machine (M2M) applications such as smart energy and building automation. @@ -248,21 +248,21 @@ installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. Registrant-ep Registrant-ep is the endpoint that is registered into the RD. The registrant-ep can register itself, or a CT registers the registrant-ep. RDAO - Resource Directory Address Option. A new IPv6 Neigbhbor Discovery + Resource Directory Address Option. A new IPv6 Neighbor Discovery option defined for announcing a Resource Directory's address. 3. Architecture and Use Cases 3.1. Principles The Resource Directory is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, or across boundaries that would be limiting those operations. @@ -552,20 +552,30 @@ Home and commercial building automation systems can benefit from the use of M2M web services. The discovery requirements of these applications are demanding. Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time discovery is used. Both home and building automation involve peer- to-peer interactions between endpoints, and involve battery-powered sleeping devices. + Two phases can be discerned for a network servicing the system: (1) + installation and (2) operation. During the operational phase, the + network is connected to the Internet with a Border router (6LBR) and + the nodes connected to the network can use the Internet services that + are provided by the Internet Provider or the network administrator. + During the installation phase, the network is completely stand-alone, + no 6LBR is connected, and the network only supports the IP + communication between the connected nodes. The installation phase is + usually followed by the operational phase. + 3.7. Use Case: Link Catalogues Resources may be shared through data brokers that have no knowledge beforehand of who is going to consume the data. Resource Directory can be used to hold links about resources and services hosted anywhere to make them discoverable by a general class of applications. For example, environmental and weather sensors that generate data for public consumption may provide data to an intermediary server, or @@ -634,45 +644,42 @@ in HTTP). A resource directory MAY make the information submitted to it available to further directories, if it can ensure that a loop does not form. The protocol used between directories to ensure loop-free operation is outside the scope of this document. 4.1. Finding a Resource Directory A (re-)starting device may want to find one or more resource - directories for discovery purposes. + directories for discovery purposes. Dependent on the operational + conditions, one or more of the techniques below apply. The use of + DNS-SD [RFC6763] is described in [I-D.ietf-core-rd-dns-sd]. The device may be pre-configured to exercise specific mechanisms for finding the resource directory: 1. It may be configured with a specific IP address for the RD. That IP address may also be an anycast address, allowing the network to forward RD requests to an RD that is topologically close; each target network environment in which some of these preconfigured nodes are to be brought up is then configured with a route for this anycast address that leads to an appropriate RD. (Instead of using an anycast address, a multicast address can also be preconfigured. The RD servers then need to configure one of their interfaces with this multicast address.) 2. It may be configured with a DNS name for the RD and use DNS to return the IP address of the RD; it can find a DNS server to perform the lookup using the usual mechanisms for finding DNS servers. - 3. It may be configured to use a service discovery mechanism such as - DNS-SD [RFC6763]. The present specification suggests configuring - the service with name rd._sub._coap._udp, preferably within the - domain of the querying nodes. - For cases where the device is not specifically configured with a way to find a resource directory, the network may want to provide a suitable default. 1. If the address configuration of the network is performed via SLAAC, this is provided by the RDAO option Section 4.1.1. 2. If the address configuration of the network is performed via DHCP, this could be provided via a DHCP option (no such option is defined at the time of writing). @@ -703,23 +710,34 @@ As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out. For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. - If multiple candidate addresses are discovered, the device may pick - any of them initially, unless the discovery method indicates a more - precise selection scheme. + The following RD discovery mechanisms are recommended: + + o In managed networks with border routers that need stand-alone + operation, the RDA0 option is recommended (e.g. operational phase + described in Section 3.6). + + o In managed networks without border router (no Internet services + available), the use of a preconfigured anycast address is + recommended (e.g. installation phase described in Section 3.6). + + o The use of DNS facilities is described in + [I-D.ietf-core-rd-dns-sd]. + + The use of multicast discovery in mesh networks is NOT recommended. 4.1.1. Resource Directory Address Option (RDAO) The Resource Directory Address Option (RDAO) using IPv6 Neighbor Discovery (ND) carries information about the address of the Resource Directory (RD). This information is needed when endpoints cannot discover the Resource Directory with a link-local or realm-local scope multicast address, for instance because the endpoint and the RD are separated by a Border Router (6LBR). In many circumstances the availability of DHCP cannot be guaranteed either during commissioning @@ -2919,36 +2937,41 @@ Systems Vol. 1, pp. 9-36, DOI 10.1145/320434.320440, March 1976. [I-D.bormann-t2trg-rel-impl] Bormann, C., "impl-info: A link relation type for disclosing implementation information", draft-bormann- t2trg-rel-impl-00 (work in progress), January 2018. [I-D.hartke-t2trg-coral] Hartke, K., "The Constrained RESTful Application Language - (CoRAL)", draft-hartke-t2trg-coral-07 (work in progress), - February 2019. + (CoRAL)", draft-hartke-t2trg-coral-08 (work in progress), + March 2019. [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 - Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 + Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 (work in progress), March 2019. [I-D.ietf-core-links-json] Li, K., Rahman, A., and C. Bormann, "Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR", draft-ietf-core-links-json-10 (work in progress), February 2018. + [I-D.ietf-core-rd-dns-sd] + Lynn, K., Stok, P., Koster, M., and C. Amsuess, "CoRE + Resource Directory: DNS-SD mapping", draft-ietf-core-rd- + dns-sd-04 (work in progress), March 2019. + [I-D.silverajan-core-coap-protocol-negotiation] Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", draft-silverajan-core-coap-protocol-negotiation-09 (work in progress), July 2018. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, .