< draft-amsuess-core-rd-replication-01.txt   draft-amsuess-core-rd-replication-02.txt >
CoRE C. Amsuess CoRE C. Amsuess
Internet-Draft March 02, 2018 Internet-Draft March 11, 2019
Intended status: Informational Intended status: Informational
Expires: September 3, 2018 Expires: September 12, 2019
Resource Directory Replication Resource Directory Replication
draft-amsuess-core-rd-replication-01 draft-amsuess-core-rd-replication-02
Abstract Abstract
Discovery of endpoints and resources in M2M applications over large Discovery of endpoints and resources in M2M applications over large
networks is enabled by Resource Directories, but no special networks is enabled by Resource Directories, but no special
consideration has been given to how such directories can scale beyond consideration has been given to how such directories can scale beyond
what can be managed by a single device. what can be managed by a single device.
This document explores different ways in which Resource Directories This document explores different ways in which Resource Directories
can be scaled up from single network to enterprise and global scale. can be scaled up from single network to enterprise and global scale.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 3, 2018. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 28 skipping to change at page 2, line 28
4. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Shared authority . . . . . . . . . . . . . . . . . . . . 4 4.1. Shared authority . . . . . . . . . . . . . . . . . . . . 4
4.2. Plain caching . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Plain caching . . . . . . . . . . . . . . . . . . . . . . 5
4.3. RD-aware caching . . . . . . . . . . . . . . . . . . . . 6 4.3. RD-aware caching . . . . . . . . . . . . . . . . . . . . 6
4.3.1. Potential for improvement . . . . . . . . . . . . . . 7 4.3.1. Potential for improvement . . . . . . . . . . . . . . 7
4.4. Distinct registration points . . . . . . . . . . . . . . 7 4.4. Distinct registration points . . . . . . . . . . . . . . 7
4.4.1. Redundancy and handover . . . . . . . . . . . . . . . 8 4.4.1. Redundancy and handover . . . . . . . . . . . . . . . 8
4.4.2. Loops between RDs and proxies . . . . . . . . . . . . 8 4.4.2. Loops between RDs and proxies . . . . . . . . . . . . 8
5. Proposed RD extensions . . . . . . . . . . . . . . . . . . . 9 5. Proposed RD extensions . . . . . . . . . . . . . . . . . . . 9
5.1. Provenance . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Provenance . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Lifetime Age . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Lifetime reporting . . . . . . . . . . . . . . . . . . . 10
6. Example scenarios . . . . . . . . . . . . . . . . . . . . . . 11 6. Example scenarios . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Redundant and replicated resource lookup (anycast) . . . 11 6.1. Redundant and replicated resource lookup (anycast) . . . 11
6.2. Redundant and replicated resource lookup (distinct 6.2. Redundant and replicated resource lookup (distinct
registration points) . . . . . . . . . . . . . . . . . . 12 registration points) . . . . . . . . . . . . . . . . . . 12
6.2.1. Variation: Large number of registrations, localized 6.2.1. Variation: Large number of registrations, localized
queries . . . . . . . . . . . . . . . . . . . . . . . 15 queries . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Variation: Combination with anycast . . . . . . . . . 15 6.2.2. Variation: Combination with anycast . . . . . . . . . 15
6.3. Anonymous global endpoint lookup . . . . . . . . . . . . 16 6.3. Anonymous global endpoint lookup . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Informative References . . . . . . . . . . . . . . . . . 18 7.1. Informative References . . . . . . . . . . . . . . . . . 18
7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[ See abstract for now. ] [ See abstract for now. ]
This document is being developed in a git based workflow. Please see This document is being developed in a git based workflow. Please see
https://github.com/chrysn/resource-directory-replication [1] for more https://github.com/chrysn/resource-directory-replication [1] for more
details and easy ways to contribute. details and easy ways to contribute.
2. Terminology 2. Terminology
skipping to change at page 7, line 32 skipping to change at page 7, line 32
endpoints, as opposed to the "title" of resources), the proxy could endpoints, as opposed to the "title" of resources), the proxy could
not do the filtering on its own becaus it would not have the required not do the filtering on its own becaus it would not have the required
information. Even the above example does not allow for fully information. Even the above example does not allow for fully
accurate replication, as the endpoint _might_ register with a "title" accurate replication, as the endpoint _might_ register with a "title"
endpoint attribute, even though no such attribute is specified right endpoint attribute, even though no such attribute is specified right
now. Also, annotating the links in the endpoint lookup with now. Also, annotating the links in the endpoint lookup with
information about which registration they belong to would help the information about which registration they belong to would help the
proxy keep all the data around to solve more complex queries. The proxy keep all the data around to solve more complex queries. The
provenance extension is proposed for that purpose. provenance extension is proposed for that purpose.
In its extreme form, the proxy can observe the complete lookup In its extreme form, the proxy can observe the complete endpoint
resources of the Resource Directory. It can then answer all queries lookup resource of the Resource Directory. and run a dedicated
on its own based on the continuously fresh state transferred in the observation for each registration. It can then answer all queries on
observations. That form requires the RD to support the provenance its own based on the continuously fresh state transferred in the
extension. observations.
For such proxies, it can be suitable to configure them to use stale For such proxies, it can be suitable to configure them to use stale
cache values for extended periods of time when the RD becomes cache values for extended periods of time when the RD becomes
intermittently unavailable. intermittently unavailable.
4.4. Distinct registration points 4.4. Distinct registration points
Caching proxies that are aware of RD semantics could be extended to Caching proxies that are aware of RD semantics could be extended to
gather information from more than one Resource Directory. gather information from more than one Resource Directory.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
be interpreted by the same rules that apply to the "anchor" be interpreted by the same rules that apply to the "anchor"
attribute, namely by resolving the reference relative to the attribute, namely by resolving the reference relative to the
requested document's URI. The attribute should not be repeated, and requested document's URI. The attribute should not be repeated, and
in presence of multiple attributes, only the last should be in presence of multiple attributes, only the last should be
considered. considered.
[ TODO: If a something link-format-ish comes up during the [ TODO: If a something link-format-ish comes up during the
development of this document which allows setting base-hrefs in-line, development of this document which allows setting base-hrefs in-line,
evaluate whether it really makes sense to inherit anchor's rules or evaluate whether it really makes sense to inherit anchor's rules or
whether it's better to phrase it in a way that the requested base URI whether it's better to phrase it in a way that the requested base URI
always counts. ] always counts. A composite CoRAL endpoint-and-resource lookup on the
RD might make this extension proposal obsolete. ]
The URI given in the "provenance" attribute describes where the The URI given in the "provenance" attribute describes where the
information in the link was obtained from. An aggregator of links information in the link was obtained from. An aggregator of links
can thus declare its sources for each link. can thus declare its sources for each link.
It is recommended that a Resource Directory adds the URI of the It is recommended that a Resource Directory adds the URI of the
registration resource to resource lookups. Thus, if an endpoint registration resource to resource lookups. Thus, if an endpoint
registers as registers as
Req: POST /rd?ep=node1 Req: POST /rd?ep=node1
skipping to change at page 10, line 28 skipping to change at page 10, line 28
o Use: Resource lookup only o Use: Resource lookup only
o Description: If "provenance" or any string starting with o Description: If "provenance" or any string starting with
"provenance=" is given as one of the ampersand-delimited query "provenance=" is given as one of the ampersand-delimited query
arguments, the RD is instructed to add the provenance attribute to arguments, the RD is instructed to add the provenance attribute to
all looked up links; otherwise, the RD will not present them. The all looked up links; otherwise, the RD will not present them. The
filtering rules still apply: If there is a "=" sign in the query filtering rules still apply: If there is a "=" sign in the query
argument, only links with matching provenance will be reported. argument, only links with matching provenance will be reported.
5.2. Lifetime Age 5.2. Lifetime reporting
The result of an endpoint lookup as a whole has inhomogenous cache The result of an endpoint lookup as a whole has inhomogenous cache
properties that would determine its Max-Age: properties that would determine its Max-Age:
o The document can change at any time when a new endpoint registers. o The document can change at any time when a new endpoint registers.
o The document can change at any time when an endpoint deregisters. o The document can change at any time when an endpoint deregisters.
o Each record can be expected to not change until its lifetime has o Each record can be expected to not change until its lifetime has
expired. expired.
As currently specified, a lookup client has no way to tell where in As currently specified, a lookup client has no way to tell where in
its lifetime an endpoint is. Therefore, a new link attribute is its lifetime an endpoint is. Therefore, a new link attribute is
suggested that allows the RD to share that information: suggested that allows the RD to share that information:
The new link attribute Lifetime Age (lt-age) is described for use in The new link attribute Lifetime Remaining (lt-remaining) is described
RD Endpoint Lookups. Valid values are integers from 0 to the for use in RD Endpoint Lookups. Valid values are integers from 0 to
lifetime of the registration. The value indicates how many seconds the lifetime of the registration. The value indicates how many
have passed since the endpoint last renewed its registration. seconds have passed since the endpoint last renewed its registration.
Care has to be taken when replicating this value in caches, as the Care has to be taken when replicating this value in caches, as the
caching agent might be unaware of the attribute's semantics and not caching agent might be unaware of the attribute's semantics and not
update it. (This is unlike the Max-Age attribute, which a caching update it. (This is unlike the Max-Age attribute, which a caching
agent needs to understand and reduce accordingly when serving from agent needs to understand and reduce accordingly when serving from
the cache). It should therefore only be used with responses that the cache). It should therefore only be used with responses that
carry the default Max-Age of 60 or less. carry the default Max-Age of 60 or less.
Clients that use the lookup interface (especially RD-aware proxies) Clients that use the lookup interface (especially RD-aware proxies)
are free to treat that record and its corresponding resource records are free to treat that record and its corresponding resource records
as fresh until after the difference of lt and lt-age seconds have as fresh until after lt-remaining seconds have passed since the
passed since the endpoint lookup result was obtained, especially if endpoint lookup result was obtained, especially if the origin server
the origin server has become unavailable. has become unavailable.
Security considerations: Given that this leaks information about the Security considerations: Given that this leaks information about the
endpoint's communication patterns, it may be prudent for an RD only endpoint's communication patterns, it may be prudent for an RD only
to reveal this information on a need-to-know basis. to reveal this information on a need-to-know basis.
6. Example scenarios 6. Example scenarios
6.1. Redundant and replicated resource lookup (anycast) 6.1. Redundant and replicated resource lookup (anycast)
This scenario describes a setup where millions of devices register in This scenario describes a setup where millions of devices register in
skipping to change at page 13, line 25 skipping to change at page 13, line 25
| LP-X | | | LP-Y | | | | | | | | LP-X | | | LP-Y | | | | | | |
\_____1/ | \_____2/ | \____3/ | \_____4/ \_____1/ | \_____2/ | \____3/ | \_____4/
| | | | | |
+--+--+ +--+--+ +--+ +--+--+ +--+--+ +--+
E E C E E E C C E E C E E E C C
The lookup proxies in this scenario are constantly observing the The lookup proxies in this scenario are constantly observing the
"/rd-lookup/ep?href=/*" and "/rd-lookup/res?provenance=/*" resources "/rd-lookup/ep?href=/*" and "/rd-lookup/res?provenance=/*" resources
of known RDs on other hosts, and might get updated internally with of known RDs on other hosts, and might get updated internally with
state from a co-hosted RD or observe that using an internal state from a co-hosted RD or observe that using an internal
interface. As there is really suitable content format and interface. As there is no really suitable content format and
observation mechanism for those yet, the exchanges are partially observation mechanism for those yet, the exchanges are partially
described in words here. described in words here.
RDAO announcements point to the nearest host (whose IP address ends RDAO announcements point to the nearest host (whose IP address ends
with the numbers of the respective box in the figure), and hosts that with the numbers of the respective box in the figure), and hosts that
do not serve both functions provide lookup as follows: do not serve both functions provide lookup as follows:
Req: GET coap://[2001:db8:23::3]/.well-known/core?rt=core.rd* Req: GET coap://[2001:db8:23::3]/.well-known/core?rt=core.rd*
Res: 2.05 Content Res: 2.05 Content
skipping to change at page 14, line 9 skipping to change at page 14, line 9
Payload: Payload:
</sensors/temp>;if="core.s" </sensors/temp>;if="core.s"
Res: 2.01 Created Res: 2.01 Created
Location: /reg/42 Location: /reg/42
the RD at 3 sends notifications to the observing lookup proxies X, Y the RD at 3 sends notifications to the observing lookup proxies X, Y
and Z: and Z:
Res: Patch Result Res: Patch Result
Add one record: </reg/42>;ep="endpoint1";d="facility23.eu.example.com"; Add one record: </reg/42>;ep="endpoint1";d="facility23.eu.example.com";
con="coap://[2001:db8:23::1]";lt-age=0 con="coap://[2001:db8:23::1]";lt-remaining=90000
As soon as that is processed, clients can query LP-Z As soon as that is processed, clients can query LP-Z
Req: GET coap://[2001:db8:4::4]/rd-lookup/ep?ep=endpoint1& Req: GET coap://[2001:db8:4::4]/rd-lookup/ep?ep=endpoint1&
d=facility23.eu.example.com d=facility23.eu.example.com
Res: 2.05 Content Res: 2.05 Content
Payload: Payload:
<coap://[2001:db8:23::3]/reg/42>;ep="endpoint1"; <coap://[2001:db8:23::3]/reg/42>;ep="endpoint1";
d="facility23.eu.example.com";con="coap://[2001:db8:23::1]" d="facility23.eu.example.com";con="coap://[2001:db8:23::1]"
(Note that lt-age is elided to the client as per the security (Note that lt-remaining is elided to the client as per the security
considerations for that information). considerations for that information).
When a net split happens that cuts LP-Z's site off the rest, it keeps When a net split happens that cuts LP-Z's site off the rest, it keeps
that information available until the lt-age runs out. that information available until the lt-remaining runs out.
When RD-C unexpectedly becomes unavailable, endpoint1 fails to renew When RD-C unexpectedly becomes unavailable, endpoint1 fails to renew
its registration. It then starts the RD discovery process again, its registration. It then starts the RD discovery process again,
picks the next available RD (this time B) and gets a new registration picks the next available RD (this time B) and gets a new registration
from that. from that.
RD-B then sends an update to the proxies: RD-B then sends an update to the proxies:
Res: Patch Result Res: Patch Result
Add one record: </reg/11>;ep="endpoint1";d="facility23.eu.example.com"; Add one record: </reg/11>;ep="endpoint1";d="facility23.eu.example.com";
con="coap://[2001:db8:23::1]";lt-age=0 con="coap://[2001:db8:23::1]";lt-remaining=90000
The proxies remove C's registration "/reg/42" based on the duplicate The proxies remove C's registration "/reg/42" based on the duplicate
name and now answer requests like this: name and now answer requests like this:
Req: GET /rd-lookup/ep?ep=endpoint1&d=facility23.eu.example.com Req: GET /rd-lookup/ep?ep=endpoint1&d=facility23.eu.example.com
Res: 2.05 Content Res: 2.05 Content
Payload: Payload:
<coap://[2001:db8:23::2]/reg/11>;ep="endpoint1"; <coap://[2001:db8:23::2]/reg/11>;ep="endpoint1";
d="facility23.eu.example.com";con="coap://[2001:db8:23::1]" d="facility23.eu.example.com";con="coap://[2001:db8:23::1]"
skipping to change at page 16, line 19 skipping to change at page 16, line 19
o Lookup request are served from the local lookup proxy, or o Lookup request are served from the local lookup proxy, or
forwarded to the closest one on RD-only hosts. forwarded to the closest one on RD-only hosts.
Such a setup is easier if all hosts provide both registration and Such a setup is easier if all hosts provide both registration and
lookup functionality. lookup functionality.
6.3. Anonymous global endpoint lookup 6.3. Anonymous global endpoint lookup
This scenario describes a way to provide connectivity into devices in This scenario describes a way to provide connectivity into devices in
difficult network situations based on identifiers of their difficult network situations based on identifiers of their
cryptographic keys, the KID context identifiers of OSCORE. A global cryptographic keys, in this case the (sufficently long) ID context
network of untrusted Resource Directory servers is built, and the plus recipient ID of OSCORE ([I-D.ietf-core-object-security]). A
individual servers provide network relaying services for endpoints global network of untrusted Resource Directory servers is built, and
that operate behind NAT or firewalls. the individual servers provide network relaying services for
endpoints that operate behind NAT or firewalls.
It assumes the existance of two other hypothetical mechanisms: It assumes the existance of two other hypothetical mechanisms:
o The RD Parameter named "proxy". o The "proxy" parameter from
[I-D.amsuess-core-resource-directory-extensions]
An endpoint can ask the RD to act as a reverse proxy for it by
adding the "proxy" registration parameter; an RD that does
proxying disregards the implicit "con" parameter and announces a
name of its own instead.
o A URI scheme called "oscore". o A URI scheme called "oscore".
A URI of the form "oscore://VGhh...2aWNl/sensor/temp" refers to a A URI of the form "oscore://VGhh...2aWNl/sensor/temp" refers to a
resource "/sensor/temp/" on any OSCORE capable host with which the resource "/sensor/temp/" on any OSCORE capable host with which the
client has a key established under the KID context given by the client has a key established under the KID context and recipient
base64 string in the authority component. ID given by the base64 string in the authority component.
To resolve the URI to a concrete protocol and socket, a form of To resolve the URI to a concrete protocol and socket, a form of
Resource Directory assisted protocol negotiation is used. Resource Directory assisted protocol negotiation is used.
RD servers join a global pool of servers using a protocol that is not RD servers join a global pool of servers using a protocol that is not
further described here, but could conceivably be based on distributed further described here, but could conceivably be based on distributed
hash tables (DHTs). hash tables (DHTs).
Endpoints register only with a key derived name, and usually do not Endpoints register only with a key derived name, and usually do not
provide any links because those would be accessible only to provide any links because those would be accessible only to
skipping to change at page 18, line 15 skipping to change at page 18, line 11
Note that while this setup _can_ serve as a generic RD and answer Note that while this setup _can_ serve as a generic RD and answer
resource requests as well, it is doubtful whether there would be any resource requests as well, it is doubtful whether there would be any
interest in it given the data becomes public, and is limited by the interest in it given the data becomes public, and is limited by the
necessity to have an "ep=" filter in all requests lest the network be necessity to have an "ep=" filter in all requests lest the network be
flooded with requests. flooded with requests.
7. References 7. References
7.1. Informative References 7.1. Informative References
[I-D.amsuess-core-resource-directory-extensions]
Amsuess, C., "CoRE Resource Directory Extensions", draft-
amsuess-core-resource-directory-extensions-00 (work in
progress), January 2019.
[I-D.ietf-core-dynlink] [I-D.ietf-core-dynlink]
Shelby, Z., Koster, M., Groves, C., Zhu, J., and B. Shelby, Z., Koster, M., Groves, C., Zhu, J., and B.
Silverajan, "Dynamic Resource Linking for Constrained Silverajan, "Dynamic Resource Linking for Constrained
RESTful Environments", draft-ietf-core-dynlink-04 (work in RESTful Environments", draft-ietf-core-dynlink-08 (work in
progress), September 2017. progress), March 2019.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-13 (work in progress), March 2018. resource-directory-19 (work in progress), January 2019.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
 End of changes. 23 change blocks. 
42 lines changed or deleted 51 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/