Internet DRAFT - draft-davies-dtnrg-uri-find
draft-davies-dtnrg-uri-find
Network Working Group E. Davies
Internet-Draft Folly Consulting
Intended status: Informational A. Doria
Expires: April 29, 2010 LTU
October 26, 2009
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
Davies & Doria Expires April 29, 2010 [Page 1]
Internet-Draft Adding find opname to dtn: URI October 2009
"find" operation would provide support for DTN (Delay- and
Disruption-Tolerant Network) anycast services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3
3. Changes to "dtn" Scheme Syntax and Rules . . . . . . . . . . . 4
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Changes to Resolution of DTN Endpoint IDs . . . . . . . . . 4
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Services Delivered by Local Service Agents . . . . . . . . 5
4.1.1. dtn:find:mailto:another@example.org,second@example.org 5
4.1.2. dtn:find:service:printer?printer-color-supported=true . 5
4.1.3. dtn:find:service:fax?destination=+4416324960123 . . . . 5
4.1.4. dtn:find:service:httpproxy:http://example.com/somepage. 5
4.1.5. dtn:find:service:httpproxy:http:?telephone+number+e
&width=5,&depth=3 . . . . . . . . . . . . . . . . . . . 6
4.2. Services Delivered by Forwarding the Bundle Using
Alternative Addressing . . . . . . . . . . . . . . . . . . 6
4.2.1. dtn:find:intent#role(?E,coffee),location(?E,Loc),within 6
4.2.2. dtn:find:assoc:wanderer3.base1.example.dtn . . . . . . 7
4.2.3. dtn:find:dns:foo.bar.example.net . . . . . . . . . . . 7
4.2.4. dtn:find:ipv4:192.0.2.27 . . . . . . . . . . . . . . . 7
4.2.5. dtn:find:ipv6:[2001:db8::27:ef12] . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Davies & Doria Expires April 29, 2010 [Page 2]
Internet-Draft Adding find opname to dtn: URI October 2009
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].
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].
Davies & Doria Expires April 29, 2010 [Page 3]
Internet-Draft Adding find opname to dtn: URI October 2009
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] is unchanged except for the addition
of "find" to opname. The revised ABNF [RFC5234] 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] 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.
Davies & Doria Expires April 29, 2010 [Page 4]
Internet-Draft Adding find opname to dtn: URI October 2009
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] 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].
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
Davies & Doria Expires April 29, 2010 [Page 5]
Internet-Draft Adding find opname to dtn: URI October 2009
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,
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]. 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
Davies & Doria Expires April 29, 2010 [Page 6]
Internet-Draft Adding find opname to dtn: URI October 2009
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 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.
Davies & Doria Expires April 29, 2010 [Page 7]
Internet-Draft Adding find opname to dtn: URI October 2009
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] which
will be registered in the URI registry defined in [RFC4395].
The "find" operation expects to use URIs following the service: URI
scheme ([RFC2609]) 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
[I-D.irtf-dtnrg-dtn-uri-scheme]
Fall, K., Burleigh, S., Doria, A., and J. Ott, "The DTN
URI Scheme", draft-irtf-dtnrg-dtn-uri-scheme-00 (work in
progress), March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
8.2. Informative References
[I-D.pbasu-dtnrg-naming]
Basu, P., Brown, D., Polit, S., and R. Krishnan,
"Intentional Naming in DTN", draft-pbasu-dtnrg-naming-00
(work in progress), May 2009.
[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, June 1999.
Davies & Doria Expires April 29, 2010 [Page 8]
Internet-Draft Adding find opname to dtn: URI October 2009
[RFC2683] Leiba, B., "IMAP4 Implementation Recommendations",
RFC 2683, September 1999.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
Authors' Addresses
Elwyn B. Davies
Folly Consulting
Soham, Cambs
UK
Phone: +44 7889 488 335
Email: elwynd@dial.pipex.com
Avri Doria
LTU
Lulea, 971 87
Sweden
Phone: +1 401 663 5024
Email: avri@acm.org
Davies & Doria Expires April 29, 2010 [Page 9]
