Adding the "find" Operation to the dtn: URI Scheme
draft-davies-dtnrg-uri-find-01.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 29, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document discusses the addition of a new operation to the proposed dtn: URI (Uniform Resource Identifier) scheme. The new "find" operation would provide support for DTN (Delay- and Disruption-Tolerant Network) anycast services.

Table of Contents

1.  Introduction
2.  Requirements Notation
3.  Changes to "dtn" Scheme Syntax and Rules
    3.1.  Syntax
    3.2.  Changes to Resolution of DTN Endpoint IDs
4.  Examples
    4.1.  Services Delivered by Local Service Agents
        4.1.1.  dtn:find:mailto:another@example.org,second@example.org
        4.1.2.  dtn:find:service:printer?printer-color-supported=true
        4.1.3.  dtn:find:service:fax?destination=+4416324960123
        4.1.4.  dtn:find:service:httpproxy:http://example.com/somepage.html?depth=3
        4.1.5.  dtn:find:service:httpproxy:http:?telephone+number+example, &width=5,&depth=3
    4.2.  Services Delivered by Forwarding the Bundle Using Alternative Addressing
        4.2.1.  dtn:find:intent#role(?E,coffee),location(?E,Loc),within(100,(1,3),Loc)
        4.2.2.  dtn:find:assoc:wanderer3.base1.example.dtn
        4.2.3.  dtn:find:dns:foo.bar.example.net
        4.2.4.  dtn:find:ipv4:192.0.2.27
        4.2.5.  dtn:find:ipv6:[2001:db8::27:ef12]
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgments
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

This document describes the addition of an extra operation to the proposed dtn: URI (Uniform Resource Identifier) scheme documented in [I‑D.irtf‑dtnrg‑dtn‑uri‑scheme] (Fall, K., Burleigh, S., Doria, A., and J. Ott, “The DTN URI Scheme,” March 2009.).

The purpose of the "find" operation is to allow DTN nodes to access services that they do not or cannot support through exchange of DTN bundles. In the spirit of DTN operation, nodes expect to be able to operate independently and may not know exactly where such a service is implemented, but has a reasonable expectation that such a service is provided by another node accessible using DTN.

Apart from the usual concept of services such as requesting printing of a bundle payload or accessing a web proxy, the "find" operation can also be used to find gateways onto remote networks that use other forms of addressing than the Endpoint IDs (EIDs) normally used to identify DTN nodes and to route bundles outside the current "association" where the bundles was created.

When a bundle arrives at a DTN node that implements the service indicated, the action taken depends on the service requested. In the case of gateway services, the bundle will simply be forwarded to the bundle agent on the addressed node. For other services, the bundle's payload will be passed to the service agent on the node together with any parameters derived from the service specification in the destination URI.

In order for the "find" operation to work satisfactorily, the routing service, whether static or dynamic, would need to collect and propagate information about the "services" offered by the nodes to which it was able to route bundles. With the help of this information, the DTN routing system could offer a form of "anycast" service that delivered appropriately addressed bundles to one or more nodes that offer the services requested in the "find" addressing format. Especially in the dynamic case, service announcements will need to be propagated in the DTN network. The mechanism to be used to provide these announcements requires further study. Where services are provided by gateway nodes at the edge of the Internet static configuration in some DTN nodes may be sufficient.

2.  Requirements Notation

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Changes to "dtn" Scheme Syntax and Rules

3.1.  Syntax

The general syntax of a dtn URI as defined in [I‑D.irtf‑dtnrg‑dtn‑uri‑scheme] (Fall, K., Burleigh, S., Doria, A., and J. Ott, “The DTN URI Scheme,” March 2009.) is unchanged except for the addition of "find" to opname. The revised ABNF [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) is:

dtnURI = "dtn:" ("none" / nontrivialSSP)

where:

nontrivialSSP = dtnURIelt *("!" dtnURIelt)

dtnURIelt = [opname] ":" URI ; URI as defined in RFC 3986 [*]

opname = "push" / "pop" / "next" / "flood" / "exec"/ "find"

3.2.  Changes to Resolution of DTN Endpoint IDs

Section 2.2 of [I‑D.irtf‑dtnrg‑dtn‑uri‑scheme] (Fall, K., Burleigh, S., Doria, A., and J. Ott, “The DTN URI Scheme,” March 2009.) contains definitions of the various operations listed under "opname" in the ABNF. For the "find" operation the following definition should be added after the definition of "exec":

find:

When the operation name is "find", the bundle agent SHOULD use information accumulated by the DTN routing system in use to forward the bundle towards one or more nodes that are able to deliver the requested service or would be better able to forward the bundle towards such a node. However, the node MAY determine that it is able to deliver the bundle locally to an agent that can provide the requested service: in this case the operation is equivalent to the "pop" operation. If the node is unable to determine a suitable target it MAY drop the bundle.
When the bundle is delivered to a node that provides the specified service then, depending on the service specified, the bundle is either forwarded to the bundle agent on a node using an alternative addressing scheme or passed to the service agent for the service on the current node.

4.  Examples

Several examples of the use of the "find" operation are presented split between conventional services delivered by a local service agent, such as a SMTP mail server, and services that provide access to networks using alternative addressing schemes, such as IPv4.

4.1.  Services Delivered by Local Service Agents

In these cases the bundle is passed to a service agent that will generally be expected to decapsulate the bundle and use the payload in combination with any parameters passed in the service description in the dtn: URI to deliver the requested service.

4.1.1.  dtn:find:mailto:another@example.org,second@example.org

Citing this EID as the destination of a bundle causes the bundle to be delivered to a node that provides an (outgoing) email server that can forward the payload of the bundle as an email to the specified address(es) in the mailto URI or local account(s) to which the email can be delivered. In this case the bundle payload is expected to contain one or more emails in [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) format.

4.1.2.  dtn:find:service:printer?printer-color-supported=true

Citing this EID as the destination of a bundle causes the bundle to be delivered to a node that provides a printing service. The specified attribute requests that a color capable printer be used to print the payload carried in the bundle. This example uses the service: URI template "printer.2.0.en" http://www.iana.org/assignments/svrloc-templates/printer.2.0.en that conforms to the specification in [RFC2609] (Guttman, E., Perkins, C., and J. Kempf, “Service Templates and Service: Schemes,” June 1999.).

4.1.3.  dtn:find:service:fax?destination=+4416324960123

Citing this EID as the destination of a bundle is intended to cause the bundle to be delivered to a node that provides a telephone facsimile (fax) service. Note that this would require the definition of a new service: URI template for a fax delivery service which provided the "destination" attribute that would be the telephone number called. The payload of the bundle would be sent as a fax to the specified destination.

4.1.4.  dtn:find:service:httpproxy:http://example.com/somepage.html?depth=3

Citing this EID as the destination of a bundle is intended to cause the bundle to be delivered to a node that provides a (caching) web proxy service. As with the previous example, this proposes the use of a yet-to-be created service: URI template for a web proxy service that would access the specified URI using the HTTP protocol. Typically the HTML in the page returned from the initial request would require additional accesses to build up the entire displayed page (c.f., the GNU "wget" tool that returns content from web servers http://www.gnu.org/software/wget/). The "depth" parameter controls the depth of recursion of such accesses. The suite of returned HTML documents would be combined into a single bundle that would be returned to the requestor. The complete service would provide additional parameters to control the behavior of the service and possibly cause repeated operation on a timed basis.

4.1.5.  dtn:find:service:httpproxy:http:?telephone+number+example, &width=5,&depth=3

This example is similar to the previous example in Section 4.1.4 (dtn:find:service:httpproxy:http://example.com/somepage.html?depth=3), except that the intention is to have the service access a suitable web search engine (to be chosen by the service provider) to look up information according to the query (in this case information about example numbers to be used when describing a telephone service) with parameters that control the number of returned results (&width parameter) to be examined in more detail by accessing the returned URIs recursively to the value of the &depth parameter. Again the complete set of results would be returned as a single bundle and additional parameters could be defined.

4.2.  Services Delivered by Forwarding the Bundle Using Alternative Addressing

The examples in this section show how the "find" operation could be used to deliver bundles to nodes that implement a bundle agent but that are also identified by another form of identifier or locator than a "universal" dtn: URI. The means used to deliver the bundle will be dependent on the network technology associated with the addressing format used.

In all cases the bundle is forwarded as a bundle rather than being decapsulated. At the destination additional parts of the URI will be used to demultiplex the bundle to the appropriate application to which it is directed as with conventional EID addressing.

4.2.1.  dtn:find:intent#role(?E,coffee),location(?E,Loc),within(100,(1,3),Loc)

The concept of intentional naming is described in [I‑D.pbasu‑dtnrg‑naming] (Basu, P., Brown, D., Polit, S., and R. Krishnan, “Intentional Naming in DTN,” May 2009.). An example of the naming scheme used with the GRAIN (Gradient-Based Algorithm for Intentional Naming) algorithm to locate nodes that satisfy the intentional naming specification is given at the end of Section 5.5 of the Intentional Naming draft. The mechanism needs additional support from the dtn: URI scheme to be usable in a DTN network. We suggest that the "find" operation could be used in the way illustrated in this example to direct bundles to appropriate nodes using an intentional naming scheme. We also note that it would also be possible to specify the intentional naming mechanism through a service: URI service template which would allow it to be used in the wider Internet instead of defined a separate "intent" URI scheme restricted to DTN.

4.2.2.  dtn:find:assoc:wanderer3.base1.example.dtn

The basic naming scheme for DTN nodes (EIDs) anticipates that names would be globally valid. In order to improve the scaling of DTN networks, the concept of "associations" has been discussed. This usage of the "find" operation would allow a node to be located via a name which was applicable only within a given association. Routing would endeavour to locate a node which was a member of the association or find a suitable gateway that might have such information.

4.2.3.  dtn:find:dns:foo.bar.example.net

In this case the bundle is destined for a node in the IP-addressed Internet that has an entry in the DNS (Domain Name System), which can be looked up to provide an IP address where the bundle can be delivered. The bundle agent "service" could either be accessed through a well-known TCP or UDP port or looked up in a DNS service record. The bundle would be delivered using the TCP or (possibly) the UDP convergence layer. The bundle agent can use IPv4 or IPv6 according to what addresses are provided by DNS, the capabilities of the local node and a policy choice if both are available.

4.2.4.  dtn:find:ipv4:192.0.2.27

This example is equivalent to the previous example except that "find" needs to locate a gateway that provides IPv4 connectivity onto the Internet. The forward DNS lookup is not required but it may be necessary to perform a reverse lookup to check that the bundle agent service is available and determine the protocol and port to use.

4.2.5.  dtn:find:ipv6:[2001:db8::27:ef12]

A similar example to Section 4.2.4 (dtn:find:ipv4:192.0.2.27) but using an IPv6 address. The "find" operation needs to locate a gateway providing IPv6 connectivity onto the Internet.

5.  Security Considerations

The addition of the "find" operation does not appear to introduce any extra security issues beyond the considerable challenges already facing DTN security.

6.  IANA Considerations

It is intended that the "find" operation will be folded into the dtn: URI scheme being defined in [I‑D.irtf‑dtnrg‑dtn‑uri‑scheme] (Fall, K., Burleigh, S., Doria, A., and J. Ott, “The DTN URI Scheme,” March 2009.) which will be registered in the URI registry defined in [RFC4395] (Hansen, T., Hardie, T., and L. Masinter, “Guidelines and Registration Procedures for New URI Schemes,” February 2006.).

The "find" operation expects to use URIs following the service: URI scheme ([RFC2609] (Guttman, E., Perkins, C., and J. Kempf, “Service Templates and Service: Schemes,” June 1999.)) and possibly other existing schemes. It may require the definition of new service templates according to the service: URI definition.

7.  Acknowledgments

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses