[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09                                 
Network Working Group                                            L. Wood
Internet-Draft                                               P. Holliday
Intended status: Experimental                              Cisco Systems
Expires: September 14, 2008                               March 13, 2008

     Using HTTP for delivery in Delay/Disruption-Tolerant Networks

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 14, 2008.


   This document describes how to use the Hypertext Transfer Protocol,
   http, for communication across delay- and disruption-tolerant
   networks. http is well-known and simpler to deploy in these networks
   than custom specialised alternatives such as the Bundle Protocol.

Wood & Holliday        Expires September 14, 2008               [Page 1]

Internet-Draft            http for DTN delivery               March 2008

Table of Contents

   1.  Background and Introduction . . . . . . . . . . . . . . . . . . 3
   2.  Adapting the http delivery mechanism for DTNs . . . . . . . . . 4
   3.  Other useful proposed http headers  . . . . . . . . . . . . . . 5
   4.  Other suggestions on http for dtn use . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

Wood & Holliday        Expires September 14, 2008               [Page 2]

Internet-Draft            http for DTN delivery               March 2008

1.  Background and Introduction

   Delay- and Disruption-Tolerant Networks (DTNs) are networks where
   conditions are such that links between nodes are not always
   permanent, may be of very long delay or exist only during very short
   contact periods where the link is up, and may change over time
   [RFC4838].  Some DTNs can be thought of as sparse ad-hoc networks,
   with nodes communicating intermittently only when they come into
   contact.  Store-and-forward delivery of data is a useful way of
   communicating across these networks.

   A specialised store-and-forward protocol for DTN delivery has been
   proposed in the IRTF DTN research group (DTNRG) - the Bundle Protocol
   [RFC5050].  Criticisms of the Bundle Protocol's reliability and
   complexity have been raised [I-D.irtf-dtnrg-bundle-checksum].

   This document outlines how the well-known Hypertext Transfer Protocol
   (http) [RFC2616] can be used for store-and-forward communication
   across DTNs. http is not used end-to-end as it is on the web.
   Instead, applications running on each node in the network communicate
   with their neighbours using dedicated hop-by-hop http transfers to
   effect local data delivery.  Additional http header information adds
   context for onward forwarding and delivery to destination endpoints,
   and provides the reliability and error-detection missing from
   alternatives such as the Bundle Protocol.

   http is a session layer, running over a transport layer providing
   reliable delivery of the http stream between hops.  This transport
   layer is commonly TCP, although alternatives, such as SCTP, can also
   be used.  For long-delay networks, or for network conditions where
   TCP or an equivalent is not suitable, an alternative transport layer
   such as Saratoga [I-D.wood-tsvwg-saratoga] could be used under http
   instead in hop-by-hop communications between nodes.

   Steve Deering has often described IP as 'the waist in the hourglass'
   - what is above IP can be changed, what is below IP can be changed,
   but provided the new elements continue to interface to and work with
   IP, the network stack remains functional.  Here, http is the waist in
   this particular hourglass; applications can use http to communicate,
   provided http runs over a reliable transport stream.  The transport
   stream can be changed; http does not have to run over TCP/IP, but
   could even be made to run directly over HDLC or a CCSDS reliable

   This document contains an overview of how http can be simply adapted
   to the DTN environment by the use of http/1.1 with persistence and
   pipelining, the PUT and GET directives, and some trivial extra http
   headers needed to indicate e.g. a destination in the DTN network.

Wood & Holliday        Expires September 14, 2008               [Page 3]

Internet-Draft            http for DTN delivery               March 2008

   The remainder of this specification uses 'file' as a shorthand for
   'binary object', which may be an http 'object', file with an
   associated MIMEtype, or other type of contiguous binary data.

   A benefit to use of http is that the well-known MIMEtype mechanism,
   used by http, provides hints on what received files are, and what
   applications should do with them.  The Bundle Protocol does not
   support MIMEtypes, or any similar mechanism.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.  [RFC2119]

2.  Adapting the http delivery mechanism for DTNs

   Here, http is used as a peer-to-peer protocol in the sense that
   multiple files may be transferred in both directions simultaneously
   between two communicating nodes using http for DTN use.  There is not
   intended to be a strict client/user-agent to server relationship as
   there is in the web.  Instead, sending data across a path of six
   nodes, four nodes between source and destination, will require a
   minimum of five separate per-hop http transactions between each pair
   of nodes to move the data onwards to the next node.  This breaks the
   traditional end-to-end control loop and transfer into separate
   control loops and transfers suitable for the DTN environment.

   When two nodes come into contact, a request for files to be copied,
   stored, and carried onwards can be made by the receiving node issuing
   an http GET request.  Alternatively, the sending node can simply
   issue a series of http PUT requests once a connection is established,
   if it believes that putting the data to the receiving node moves it
   closer to its eventual destination.  The receiving node can always
   reject transfers with error codes.

   http/1.1 pipelining and persistence permits multiple PUTs to be made
   in sequence.  Support for these in implementations is crucial to the
   mechanisms outlined here.

   The key to enabling http use for DTN networking is an added Content-
   Destination: header, which specifies the final destination of the
   file, and can be used by routing in the http-using applications to
   decide over which links the file should be sent.  Content-* headers
   are special, in that they may not be ignored (section 9.6 of
   [RFC2119]).  Recipients not understanding Content-Destination: will
   generate a 501 (Not Implemented) error code.  This separates http use
   in DTNs described here from normal end-to-end http web use. http DTN
   nodes MUST support Content-Destination:

Wood & Holliday        Expires September 14, 2008               [Page 4]

Internet-Draft            http for DTN delivery               March 2008

   The information provided in Content-Destination: identifying the
   destination may be an IP address, DNS name, Bundle Endpoint
   Identifier (EID) or other text-string identifier useful to the local
   DTN routing mechanisms being used.

   Similarly, a Content-Source: header provides the original source of
   the data.  This MUST be implemented.

   For DTN use, DTN http nodes MUST also implement Content-Length:,
   Content-Range: and Content-MD5 headers.  This permits partial
   delivery of files and resends of missing pieces.  The Content-MD5:
   header provides a simple end-to-end reliability check.  The Content-
   MD5: header is intended to be generated by the source node first
   sending the data, and not recomputed at other nodes.

   DTN http nodes MUST implement the Host: header.  This field MAY be
   left blank to request available files from the peer node, rather than
   identifying a desired file from a distant source by hostname.  A
   sender placing a new file into the DTN network for onward
   transmission MUST have the Content-Source: field of the data being
   sent match its Host: field.

   Hop-by-hop http headers MAY be implemented.  The headers described in
   section 13.5.1 of [RFC2616] are available.  New hop-by-hop headers
   MUST use the Connection: header approach described in section 14.10
   of [RFC2616].

   DTN http nodes may GET and PUT to link-local multicast addresses.
   This permits efficient sharing of files on shared LANs, with
   recipients requesting resends via Content-Range: and checking
   assembly of file pieces using the Content-MD5: header.

3.  Other useful proposed http headers

   A number of other http headers are proposed here, as likely to be
   useful.  These SHOULD be implemented.

   An http object is just one binary file; the ability to group objects
   together is useful (and is done in bundles by the bundle protocol).
   If we call a group of related objects travelling together between the
   same source and destination a 'package' (a name chosen to avoid any
   confusion with the 'bundle' specification), we can then define simple
   headers to be sent before each object:

   Package-ID: - provides a unique text-string identifier for the

Wood & Holliday        Expires September 14, 2008               [Page 5]

Internet-Draft            http for DTN delivery               March 2008

   Package-Item: n of m (e.g. 1 of 7) - order of this http file in the

   Package-MD5: - checksum across all Content-MD5 headers added together
   in order

   A way to request missing Package-Items (from the previous node or
   from the source) is likely to be very useful.

   Some sort of header protection is likely also a good idea.  So,
   Header-MD5: could cover some important http headers.  Header-MD5
   could be preserved across hops if possible, avoiding unnecessary
   header reordering.  Timestamps prevent this, however - this needs
   more thought, particularly on where timestamps are placed in http

   Timestamps and how they are handled needs to be examined here in
   greater detail.  What if different machines have different notions of

   For larger files, stronger checksums than MD5 should be looked at.

4.  Other suggestions on http for dtn use

   x-application-dtn has previously been proposed as a MIMEtype
   identifying Bundle Protocol bundles delivered by http.  This provides
   a way to support legacy Bundle Protocol implementations to upgrade in

   Moving http transfers over DTN networks using the Bundle Protocol has
   already been proposed [Ott06].  By changing how http is used - hop-
   by-hop rather than end-to-end - this draft has outlined how http can
   be used directly and independently in DTN networks without requiring
   the bundle protocol as a carrier.

5.  Security Considerations

   Security considerations and examination of https is required here.

   Because there is a need for each node to validate that a file has
   been received correctly, privately-keyed hashes that can only be
   checked at the destination should be avoided, and http security
   mechanisms should be used instead.

Wood & Holliday        Expires September 14, 2008               [Page 6]

Internet-Draft            http for DTN delivery               March 2008

6.  IANA Considerations

   It may make sense to use a non-standard port for http use, rather
   than the well-known port 80.  If so, such a port should be requested
   from IANA.

   It may be necessary to request a dedicated IPv4 all-hosts multicast
   address and a dedicated IPv6 link-local multicast addresses for local
   http DTN use, if local http multicast is considered desirable.

7.  Acknowledgements

   Work on the Saratoga protocol inspired some of the concepts used
   here.  We thank Wes Eddy for his review comments.

8.  References

8.1.  Normative References

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

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

8.2.  Informative References

              Eddy, W., Wood, L., and W. Ivancic, "Checksum Ciphersuites
              for the Bundle Protocol",
              draft-irtf-dtnrg-bundle-checksum-02 (work in progress),
              March 2008.

              Wood, L., McKim, J., Eddy, W., Ivancic, W., and C.
              Jackson, "Saratoga: A Scalable File Transfer Protocol",
              draft-wood-tsvwg-saratoga-01 (work in progress),
              February 2008.

   [Ott06]    Ott, J. and D. Kutscher, "Bundling the Web: HTTP over
              DTN", WNEPT 2006 Workshop on Networking in Public
              Transport, QShine Conference Ontario, August 2006.

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant

Wood & Holliday        Expires September 14, 2008               [Page 7]

Internet-Draft            http for DTN delivery               March 2008

              Networking Architecture", RFC 4838, April 2007.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

Authors' Addresses

   Lloyd Wood
   Cisco Systems
   11 New Square Park, Bedfont Lakes
   Feltham, Middlesex  TW14 8HA
   United Kingdom

   Phone: +44-20-8824-4236
   Email: lwood@cisco.com

   Peter Holliday
   Cisco Systems
   Level 12
   300 Adelaide Street
   Brisbane, Queensland  4000

   Phone: +61-2-6216-0604
   Email: phollida@cisco.com

Wood & Holliday        Expires September 14, 2008               [Page 8]

Internet-Draft            http for DTN delivery               March 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Wood & Holliday        Expires September 14, 2008               [Page 9]