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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/