Internet DRAFT - draft-rahman-core-advanced-rd-features
draft-rahman-core-advanced-rd-features
CORE WG A. Rahman
Internet-Draft C. Wang
Intended status: Informational InterDigital Communications, LLC
Expires: September 19, 2016 March 18, 2016
Advanced Resource Directory Features
draft-rahman-core-advanced-rd-features-02
Abstract
The Resource Directory (RD) is a key element for successful
deployments of constrained networks. Similar to the HTTP web search
engines (e.g. Google, Bing), the RD for CoAP should also support
useful search query responses beyond a basic listing of relevant
links. This document proposes several new features to be considered
for the RD. The only goal of this document is to trigger discussion
in the CoRE WG so that all relevant features for RD evolution are
taken into account during CoRE re-charter activities.
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 19, 2016.
Copyright Notice
Copyright (c) 2016 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
(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
Rahman & Wang Expires September 19, 2016 [Page 1]
Internet-Draft Advanced Resource Directory Features March 2016
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. Terminology and Conventions . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 4
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Terminology and Conventions
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 RFC 2119 [RFC2119].
This document assumes readers are familiar with the terms and
concepts that are used in [RFC6690], [RFC7252] and
[I-D.ietf-core-resource-directory].
2. Background
The concept of the Resource Directory (RD) is described in
[I-D.ietf-core-resource-directory]. It is defined as a node which
hosts descriptions of resources held on other servers, allowing
lookups to be performed for those resources. The
[I-D.ietf-core-resource-directory] specifies the web interfaces that
a Resource Directory supports in order for devices to discover the RD
and to register, maintain, lookup and remove resources descriptions.
The relevant specification of interfaces in
[I-D.ietf-core-resource-directory] is given using the CoAP protocol
[RFC7252] for all interfaces. Also, HTTP protocol [RFC7230] support
is given for some interfaces. For example, all the response
codes(i.e. success and error) for registering and looking up
resources support both CoAP and HTTP. However, the important
multicast discovery interface does not support HTTP. The Group
interface also does not support HTTP.
Rahman & Wang Expires September 19, 2016 [Page 2]
Internet-Draft Advanced Resource Directory Features March 2016
The CoRE Link Format [RFC6690] describes the format of the payload of
a CoAP message that carries a set of CoAP URIs. With relation to the
RD, the CoRE Link Format is be used by a device to carry (encode) the
set of URIs it wants to register with an RD. Also, the CoRE Link
Format is used to carry (encode) the set of URIs returned by a RD for
a lookup query (including the initial multicast discovery request).
While in theory the CoRE Link Format [RFC6690] specification states
that it may be used with HTTP, in practice many details still need to
be fleshed out and specified before this can be realized.
3. Proposal
It is proposed that the RD should also support the following
additional features:
1. Explicit HTTP Support - Though there is some support of HTTP in
[I-D.ietf-core-resource-directory], the specification should be
further expanded to also explicitly support HTTP for the Discovery
and perhaps the Group Functions. Also, the RD function is intimately
tied to the CoRE Link Format [RFC6690] which does not have any
explicit support of HTTP at all. So the CoRE Link Format definitely
needs to be updated to support HTTP explicitly.
2. Mirror Server - The CoRE WG has previously discussed the concept
of a mirror server in relation to supporting sleepy devices.
Specifically, [I-D.vial-core-mirror-server] recommends to create a
new class of RDs which store the actual resource representations (as
opposed to simply storing the URI) in a special type of RD called the
Mirror Server. Communicating devices can both lookup the resource,
and then also fetch directly the resource representation, from the
Mirror Server regardless of the state of the sleepy server.
3. Re-direction to another RD - A given RD may not have the URIs
being queried for registered in its database. The given RD should
have the capability to re-direct the querying client to another RD
which may have the information of interest.
4. URI Ranking - Current Internet search engines (e.g. Google) have
extensive methods for ranking the URIs returned to a human initiated
search query. For example, the concept of Search Engine Optimization
(SEO) has spawned a large industry in the web world for specifically
this purpose. The concept of URI ranking (to indicate the "value" of
the URI) should also be supported by the RD.
5. Indication of transport protocol - Several proposals exist(e.g.
[I-D.silverajan-core-coap-alternative-transports]) in the CoRE WG to
support alternative transports (e.g. TCP, SMS) for CoAP beyond the
Rahman & Wang Expires September 19, 2016 [Page 3]
Internet-Draft Advanced Resource Directory Features March 2016
current UDP transport. It would be very useful if search results
from a RD indicated the type of transport supported by a given URI.
6. Privacy Model - IoT devices may often contain sensitive
information (e.g. health monitoring device) or affect human safety
(e.g. traffic light controllers, elevator actuators). When the
resources of a device is registered with a given RD and domain,
should anyone at all be able to easily discover the resources
associated with the device? Does this cause privacy or security
concerns in certain RD lookup scenarios? Currently,
[I-D.ietf-core-resource-directory] has a very brief mention that
endpoint and clients should be authenticated and access controlled.
However, a more complete privacy model should be developed to address
this very important issue.
4. Summary
The proposed set of feature extensions for the RD will improve the
constrained environment search capability and make deployments more
efficient. These RD feature extensions should be individually
considered during the CoRE re-charter discussions. Evolution and
forward thinking is required for the CoRE RD, as constantly occurs in
the current Internet for HTTP web search engines (e.g. Google).
5. Acknowledgements
TBD.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
Not applicable.
8. References
8.1. Normative References
[I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
Resource Directory", draft-ietf-core-resource-directory-05
(work in progress), October 2015.
Rahman & Wang Expires September 19, 2016 [Page 4]
Internet-Draft Advanced Resource Directory Features March 2016
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References
[I-D.silverajan-core-coap-alternative-transports]
Silverajan, B. and T. Savolainen, "CoAP Communication with
Alternative Transports", draft-silverajan-core-coap-
alternative-transports-09 (work in progress), December
2015.
[I-D.vial-core-mirror-server]
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
server-01 (work in progress), April 2013.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014,
<http://www.rfc-editor.org/info/rfc7390>.
Authors' Addresses
Akbar Rahman
InterDigital Communications, LLC
Email: akbar.rahman@interdigital.com
Chonggang Wang
InterDigital Communications, LLC
Email: chonggang.wang@interdigital.com
Rahman & Wang Expires September 19, 2016 [Page 5]
