[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                            K. Fall
Internet-Draft                                   Intel Research Berkeley
Intended status: Experimental                           S. Burleigh, Ed.
Expires: September 29, 2009                    Jet Propulsion Laboratory
                                                                A. Doria
                                          Lulea University of Technology
                                                                  J. Ott
                                       Helsinki University of Technology
                                                                D. Young
                                                          March 28, 2009


                           The DTN URI Scheme
                   draft-irtf-dtnrg-dtn-uri-scheme-00

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 September 29, 2009.

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.



Fall, et al.           Expires September 29, 2009               [Page 1]


Internet-Draft             The DTN URI Scheme                 March 2009


Abstract

   This document describes the "dtn" Uniform Resource Identifier (URI)
   scheme.  DTN URIs are used as DTN endpoint identifiers (EIDs).

Requirements Language

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


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  "dtn" Scheme Syntax and Rules . . . . . . . . . . . . . . . . . 3
     2.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Resolution of DTN Endpoint IDs  . . . . . . . . . . . . . . 4
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.1.  dtn:none  . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.2.  dtn::http://demmermac.dtn/ping  . . . . . . . . . . . . . . 6
     3.3.  dtn::ipn:19.6 . . . . . . . . . . . . . . . . . . . . . . . 6
     3.4.  dtn:pop:http://www.dtnrg.org/log/ . . . . . . . . . . . . . 6
     3.5.  dtn:pop:mailto:kscott@mitre.org . . . . . . . . . . . . . . 7
     3.6.  dtn:push:ethernet:00:1e:24:82:c3:df . . . . . . . . . . . . 7
     3.7.  dtn:push:tcp:119.61.32.4,1816!next:ipn:19.4 . . . . . . . . 7
     3.8.  dtn:flood:sql:true  . . . . . . . . . . . . . . . . . . . . 7
     3.9.  dtn:flood:sql:batterylevel<.25  . . . . . . . . . . . . . . 8
     3.10. dtn:exec:c:while(foo < 9){bar();foo++;} . . . . . . . . . . 8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9















Fall, et al.           Expires September 29, 2009               [Page 2]


Internet-Draft             The DTN URI Scheme                 March 2009


1.  Introduction

   A DTN endpoint identifier (EID) is a type of Uniform Resource
   Identifier (URI) [*] designed to meet the requirements for endpoint
   identification as defined in the Bundle Protocol specification, RFC
   5050 [*]:

   o  EIDs are used to identify the source and destination endpoints of
      a bundle, the endpoint to which bundle status reports pertaining
      to the bundle are to be sent, and the current custodian of the
      bundle.

   o  EIDs are used, as needed, to identify other endpoints that are
      involved in the conveyance of a bundle from its source to its
      destination.  For example, the most recent forwarder of a bundle
      may be identified by EID in some block of the bundle.

   o  The length of the scheme-specific part of an EID MUST NOT exceed
      1023 bytes.

   Any URI whose scheme-specific part is of no more than 1023 bytes MAY
   be used as a DTN endpoint identifier, regardless of scheme.  However,
   DTN routers may be configured only to forward bundles to destinations
   whose EIDs conform to more restrictive rules; in particular, bundles
   destined for endpoints identified by URIs in schemes other than "dtn"
   are likely to be unforwardable.

   EIDs formed in the "dtn" scheme are specifically designed to be
   parseable by DTN routers, increasing the likelihood that the bundles
   to which they are destined may be forwarded.

   Additional information about the dtn URI scheme - motivation,
   genesis, and discussion - can be obtained from http://www.dtnrg.org.

   Note that this draft represents early thinking on this topic and the
   scheme described here is very likely to change in many respects as we
   get further input from DTNRG.  The authors welcome further discussion
   and comments.


2.  "dtn" Scheme Syntax and Rules

   This section specifies the syntax of dtn URIs, then discusses the
   resolution of DTN endpoint IDs.







Fall, et al.           Expires September 29, 2009               [Page 3]


Internet-Draft             The DTN URI Scheme                 March 2009


2.1.  Syntax

   The general syntax of a dtn URI, in ABNF [*], is:

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

   where:

      nontrivialSSP = dtnURIelt *("!" dtnURIelt)

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

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

2.2.  Resolution of DTN Endpoint IDs

   Whenever the scheme-specific part (SSP) of a "dtn" URI is not "none"
   - that is, it is non-trivial - this SSP comprises one or more dtn URI
   elements, each of which comprises an optional operation name followed
   by a URI.  (That is, each non-trivial "dtn" URI's SSP contains at
   least one embedded URI.)  The scheme component of the embedded URI in
   each dtn URI element identifies the name space from which the name-
   specific string (NSS) of that URI - the characters following the
   colon that terminates the scheme component - is drawn and in so doing
   it indicates the syntax rules governing the NSS.

   The scheme component of the embedded URI in a dtn URI element MAY be
   some name that is not the name of a registered URI scheme.  When the
   scheme component of the embedded URI in a DTN URI element is the name
   of a registered URI scheme, the syntax of the NSS of that embedded
   URI MUST conform to the syntax rules defined for the registered URI
   scheme.  Otherwise, determining the applicable syntax rules for the
   NSS of the embedded URI is an implementation issue.

   Each URI element in a "dtn" URI's SSP constitutes a single bundle
   handling request, identifying some handling that the bundle agent
   SHOULD perform when it is required to dispatch a bundle destined for
   the endpoint identified by the "dtn" URI.  When the URI comprises
   multiple URI elements, the handling performed in response to each
   handling request MUST either (a) be performed after any handling
   performed in response to all preceding requests and be performed
   before any handling performed in response to all subsequent requests
   or (b) not be performed.  Note that in some cases the handling
   requested by a given URI element may be precluded by the performance
   of handling requested by a preceding URI element, leaving the bundle
   agent with no alternative but to fail to perform the requested
   handling.




Fall, et al.           Expires September 29, 2009               [Page 4]


Internet-Draft             The DTN URI Scheme                 March 2009


   *Note that the opnames identified in the "dtn" scheme syntax defined
   above are merely those that are currently proposed, and the handling
   defined below for each operation is purely notional at this point.*

   The handling requested by each URI element of a destination EID is
   defined as follows:

   push:  When the operation name is "push", the bundle agent MUST
      regard the URI in the URI element as the convergence layer
      protocol endpoint to which the bundle is to be sent and SHOULD
      invoke the services of the applicable convergence layer adapter to
      send the bundle to that endpoint.  This handling is intended to
      supersede any decision on binding proximate node to convergence
      layer that the bundle agent might make in the absence of this
      handling request.

   pop:  When the operation name is "pop", the bundle agent MUST regard
      the URI in the URI element as the Internet application endpoint to
      which the payload of the bundle is to be sent and SHOULD invoke
      Internet services to send the payload of the bundle to that
      application endpoint.  This handling is intended to provide a
      generalized mechanism for directing bundle payloads to proxies for
      Internet applications.

   next:  When the operation name is "next", the bundle agent MUST
      regard the concatentation of the string "dtn::" and the URI in the
      URI element as the DTN endpoint to which the bundle agent is to
      forward the bundle and SHOULD forward the bundle to that endpoint.
      This handling is intended to supersede any dispatching decision
      that the bundle agent might make in the absence of this handling
      request.

   flood:  When the operation name is "flood", the bundle agent MUST
      regard the URI in the URI element as a node selection expression
      and SHOULD (a) deliver the bundle to the administrative endpoint
      of the node if the state of the node satisfies the selection
      expression and (b) forward the bundle to all of the node's
      neighbors other than the one from which the bundle was received.
      This handling is intended to provide a generalized mechanism for
      content-based addressing.

   exec:  When the operation name is "exec", the bundle agent MUST
      regard the URI in the URI element as the definition of a procedure
      expressed in a programming language and SHOULD execute that
      procedure in the context of the state of the node.  This handling
      is intended to provide a generalized mechanism for programmable
      forwarding.




Fall, et al.           Expires September 29, 2009               [Page 5]


Internet-Draft             The DTN URI Scheme                 March 2009


      When no operation name is present, the bundle agent MUST regard
      the concatentation of the string "dtn::" and the URI in the URI
      element as the name of the destination of the bundle and SHOULD
      dispatch the bundle as prescribed in RFC5050.

   Following the completion of all performance of handling requested by
   the URI elements of a destination EID, if the bundle has not yet been
   either forwarded or delivered then the bundle agent MUST regard the
   entire destination EID as the name of the destination of the bundle
   and MUST dispatch the bundle as prescribed in RFC 5050.

   The results of any prior handling performed by the bundle agent MAY
   affect the dispatching of a bundle in implementation-specific ways.

   Note that one possible use of a succession of URI elements with
   operation names "next" and "push" in an EID is to provide a loose
   source route, prescribing the forwarding of a bundle along a
   specified sequence of network hops.


3.  Examples

3.1.  dtn:none

   Citing this endpoint ID, the "null endpoint", as the destination of a
   bundle causes the bundle to be discarded.

3.2.  dtn::http://demmermac.dtn/ping

   Citing this EID as the destination of a bundle causes the bundle
   simply to be dispatched: it is delivered to the indicated endpoint ID
   if the local node is registered at that EID, and otherwise it is
   forwarded to that endpoint.

3.3.  dtn::ipn:19.6

   Citing this EID as the destination of a bundle again causes the
   bundle simply to be dispatched, as in example 2.  Note that in this
   case the NSS of the URI embedded in the EID's first URI element is
   simply the string "19.6".

3.4.  dtn:pop:http://www.dtnrg.org/log/

   Citing this EID as the destination of a bundle causes the payload of
   the bundle to be sent as an HTTP message to the indicated Web site.
   Note that this differs from example 2 in that (a) only the payload,
   not the entire bundle, is transmitted and (b) the protocol used for
   transmission is HTTP rather than Bundle Protocol.  In example 2, the



Fall, et al.           Expires September 29, 2009               [Page 6]


Internet-Draft             The DTN URI Scheme                 March 2009


   presence of the scheme name "http" identifies the syntax rules
   governing the name text but does *not* cause the HTTP protocol to be
   used.

3.5.  dtn:pop:mailto:kscott@mitre.org

   Citing this EID as the destination of a bundle causes the payload of
   the bundle to be sent as an email message to the indicated email
   address.

3.6.  dtn:push:ethernet:00:1e:24:82:c3:df

   Citing this EID as the destination of a bundle causes the bundle to
   be passed to the Ethernet convergence layer adapter for transmission
   to the indicated Ethernet address.  This implies an expectation that
   an Ethernet convergence layer adapter of some other DTN node is
   listening for bundle traffic at this address and will, upon reception
   of the bundle, pass it up to that node's bundle agent for
   dispatching.

3.7.  dtn:push:tcp:119.61.32.4,1816!next:ipn:19.4

   Citing this EID as the destination of a bundle causes the bundle to
   be passed to the TCP/IP convergence layer adapter for transmission to
   the indicated port on the indicated host.  The implied expectation is
   that a TCP convergence layer adapter of some other DTN node is
   listening for bundle traffic at this port on this host and will, upon
   reception of the bundle, pass it up to that node's bundle agent for
   dispatching.  That bundle agent, recognizing (in an implementation-
   dependent manner) that the first URI element in the destination EID
   is inapplicable, will ignore that first URI element and will respond
   only to the second URI element.  The second URI element requests that
   the bundle agent immediately forward the bundle to the endpoint
   identified by "dtn::ipn:19.4" rather than perform standard dispatch
   procedures.  That is, this EID prescribes a source route including
   selection of a specific initial convergence-layer channel.

3.8.  dtn:flood:sql:true

   Citing this EID as the destination of a bundle causes the bundle to
   be delivered to the local node's administrative endpoint (because the
   node's state is satisfied by the selection expression "true") and
   then forwarded to all of the node's neighbors other than the one from
   which the bundle was received.







Fall, et al.           Expires September 29, 2009               [Page 7]


Internet-Draft             The DTN URI Scheme                 March 2009


3.9.  dtn:flood:sql:batterylevel<.25

   Citing this EID as the destination of a bundle causes the bundle to
   be delivered to the local node's administrative endpoint, provided
   the "batterylevel" variable in the state of the node has a value less
   than .25, and then forwarded to all of the node's neighbors other
   than the one from which the bundle was received.

3.10.  dtn:exec:c:while(foo < 9){bar();foo++;}

   Citing this EID as the destination of a bundle causes function "bar"
   to be executed so long as the value of node state variable "foo" is
   less than 9.  As soon as "foo" is 9 or greater, all requested
   handling for this destination endpoint ID is complete; if execution
   of function "bar" has not yet caused the bundle to be dispatched, the
   bundle is dispatched at this time.  Since, for this purpose, the
   entire destination EID must be regarded as the name of the
   destination, the node's routing mechanism might require an a default
   dispatching decision for all bundles whose destination names conform
   to the wild-card expression "dtn:exec:*".  This is an implementation
   matter.


4.  IANA Considerations

   The IANA has registered the dtn URI scheme as specified in this
   document and summarised in the following template.

   URI scheme name: dtn

   Status: permanent

   URI scheme syntax: see Section 2

   Character encoding considerations: none

   Intended usage: see Sections 1 through 3

   Applications and/or protocols that use this URI scheme name: Any
   applications and protocols that use the DTN Bundle Protocol.

   Interoperability considerations: none

   Security considerations: see Section 5

   Relevant publications: RFC 5050

   Contact: Kevin Fall(kfall@intel.com) and Stephen Farrell



Fall, et al.           Expires September 29, 2009               [Page 8]


Internet-Draft             The DTN URI Scheme                 March 2009


   (stephen.farrell@cs.tcd.ie)

   Author/Change controller: Kevin Fall and Stephen Farrell


5.  Security Considerations

   dtn URIs whose URI elements lack operation names or are confined to
   the operation names "push" and "next" raise no security
   considerations beyond those addressed in RFC 5050.

   The "pop" operation could be used to circumvent firewall rules that
   accept Bundle Protocol traffic but reject traffic destined for
   endpoints of the popped Internet application protocol.

   Attacks built on the "flood" operation could exploit the possible
   side effects of evaluating selection expressions.

   Attacks built on the "exec" operation could modify bundle node state
   in a limitless variety of ways.

   Bundle protocol implementations that support these more dangerous
   operations will need to exercise extreme care.


6.  Acknowledgements

   [We can only have up to 5 authors, so Stephen, Joseph, Elwyn, and
   others need to be acknowledged here.)


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [InfRef]   "", 2004.










Fall, et al.           Expires September 29, 2009               [Page 9]


Internet-Draft             The DTN URI Scheme                 March 2009


Authors' Addresses

   Kevin Fall
   Intel Research Berkeley
   2150 Shattuck Avenue, #1300
   Berkeley, California  94704
   USA

   Phone: +1-510-495-3014
   Fax:
   Email: kfall@intel.com


   Scott Burleigh (editor)
   Jet Propulsion Laboratory
   4800 Oak Grove Drive, m/s 301-490
   Pasadena, California  91109
   USA

   Phone: +1-818-393-3353
   Fax:
   Email: scott.c.burleigh@jpl.nasa.gov
   URI:


   Avri Doria
   Lulea University of Technology
   Lulea  971 87
   Sweden

   Email: avri@ltu.se


   Joerg Ott
   Helsinki University of Technology
   Department of Communications and Networking
   PO Box 3000
   TKK  02015
   Finland

   Email: jo@netlab.tkk.fi










Fall, et al.           Expires September 29, 2009              [Page 10]


Internet-Draft             The DTN URI Scheme                 March 2009


   David Young


   Phone:
   Fax:
   Email:
   URI:












































Fall, et al.           Expires September 29, 2009              [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/