Advanced Resource Directory Features
draft-rahman-core-advanced-rd-features-01

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 August 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 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. Background
• 3. Proposal
• 4. Summary
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

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.

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 current UDP transport. It would be very useful if search results from a RD indicated the type of transport supported by a given URI.

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

8.2. Informative References

Authors' Addresses