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

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 January 6, 2016.

Copyright Notice

Copyright (c) 2015 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 example, all the response codes(i.e. success and error) for registering and looking up resources are CoAP based. Also a multicast discovery interface is defined [RFC7390]. However, in theory, the RD interfaces can also be implemented using HTTP [RFC7252].

The Core Link Format [RFC6690] describes the format of the payload of a CoAP Response 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).

3. Proposal

It is proposed that the RD should also support the following additional features:

1. Explicit HTTP interfaces - As explained previously the current CoRE specifications are written explicitly with CoAP examples. The specifications should be expanded to also explicitly support HTTP (e.g. HTTP request and response codes). There may be some RD interfaces, such as multicast and Group Function, that may not be supported by HTTP and those should also be explicitly identified and excluded.

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