HTTP over Bundle Protocol for Delay-Tolerant
Networks (DTN)Viagénie246 AberdeenQuébecQCG1R 2E1Canada+1 418 656 9254simon.perreault@viagenie.cahttp://viagenie.caViagénie246 AberdeenQuébecQCG1R 2E1Canada+1 418 656 9254simon.perreault@viagenie.cahttp://viagenie.caThis document defines how HTTP is transported over DTN using the Bundle
Protocol.The Hypertext Transfer Protocol (HTTP) is the
most popular application-layer protocol on the Internet. Porting it to
DTN will allow a tremendous body of knowledge and running code to be
reused.This document describes how HTTP messages are formatted and then
inserted into the payload of the bundles (see Bundle Protocol ).HTTP over BP can be used directly by BP nodes as illustrated in .Regular HTTP clients and servers can also be accomodated using an
HTTP/BP proxy as illustrated in . In this case,
the proxy speaks BP on one side and IP on the other (and presumably
TCP, although HTTP can make use of other transport protocols over IP).
From the point of view of the regular HTTP client and server, the two
HTTP/BP proxies and the BP link are seen as one logical regular HTTP
proxy.DTN is often applied to space networking scenarios. shows one such application.In this example, a mission operation IP network is linked to a
spacecraft IP network using BP. Each BP endpoint is augmented with an
HTTP/BP proxy allowing HTTP to operate end-to-end, across the DTN, from
one IP network to another. This enables, for example, a monitoring
station on the ground to access a sensor on the spacecraft using regular
HTTP interfaces. BP is transparent to them and they can be programmed
to use HTTP without having to care about the details of DTN.This is only one use case. The logical scenarios illustrated in and can be applied to any
DTN deployment.It is intended that the format described in this document have the
following features:
Support for partial HTTP messages because HTTP message length can
be larger than bundle payload length.Support for multiple HTTP messages per bundle for efficiency
purposes.Support for infinite-length HTTP messages because those HTTP
messages are used, for example, in media streaming.Support for pre-fetching related HTTP resources so as to reduce
round-trips, which is very important in DTN. In a disconnected
network, it may be very useful to pre-fetch some data during the
windows when communications are possible.HTTP over TLS is implicitly supported with the CONNECT method . Note that the use of encryption will defeat
optimizations such as pre-fetching that HTTP/BP proxies can provide
with non-encrypted HTTP.HTTP over BP occupies the payload block (
section 4.5.3). The whole block consists of a series of TLVs
(Type-Length-Value). Each TLV has the following format:An SDNV identifying the TLV type.An SDNV containing the length of the Value
field, in bytes.Zero or more bytes whose meaning depends on the
Type SDNV.Multiple such TLVs MAY be included in a bundle's payload block. There
is no limit on the number of TLVs besides pre-existing limits on bundle
size.This document defines types 0, 1, and 2. Other types MAY be defined in
the future. An implementation of HTTP over BP MUST completely ignore
any TLV whose type is unknown.The Piece TLV contains a piece of HTTP message. Its type is 0. It
has the following format:Note that the Length field includes the RID and Offset fields.
An SDNV uniquely identifying the
request/response exchange.An SDNV indicating, in the full HTTP message,
the number of bytes coming before the first byte in this
piece.Following this is the piece of HTTP message itself. The HTTP message
includes the headers and the body, and there is no limitation on where
a piece begins or ends. Therefore, the HTTP headers MAY be split among
multiple pieces, likewise for the body, and a piece MAY contain part
of the headers and body simultaneously. A receiver MUST be prepared to
handle all possible cases.HTTP relies on the transport-layer protocol to associate responses
with requests. Since BP is inherently connectionless, a new mechanism
is necessary for this purpose: the Request ID. The client sending a
request MUST generate an ID such that the 3-tuple comprising the
source EID, the destination EID, and the RID is unique across time.
The server will respond with the same RID.An HTTP message MAY be split into as many pieces as the sender
desires. Note that some HTTP messages are effectively infinite in
length (e.g., a response containing live streaming video).Pieces MAY not be all the same size and MAY be sent out of order.
Note also that bundles may be reordered during transport. In
consequence, the receiver MUST reassemble the pieces using the offset
and length values.The sender MUST NOT send overlapping pieces. If any overlap is
detected by the receiver, the message SHOULD be dropped.The total length of the HTTP message is not available at the bundling
layer. The receiver will determine the total length of the HTTP
message in an HTTP-specific manner (e.g., for HTTP 1.1 see section 4.4).The Close TLV is used to indicate the termination of an HTTP
exchange. It plays a role analogous to the RST flag in TCP. Its type
is 1. Its format is as follows:The RID SDNV indicates the request/response exhange that is being
terminated.The Offset SDNV indicates the number of bytes that are to be received
before the HTTP exchange is closed. An Offset of zero means that the
Close takes effect immediately, no matter how many bytes have been
received.An HTTP/BP proxy SHOULD send a Close TLV when the corresponding
connection on the IP side (TCP, SCTP, or other) is terminated before
the HTTP request/response exchange has completed, unless it has
already sent or received a Close TLV for this RID.It is often important on the DTN to eliminate as many round-trips as
possible. With HTTP, many heuristics can be used to this end. For
example, one technique consists in transferring multiple related HTTP
resources across the DTN in anticipation of future requests for them.
For a local cache to be able to correctly compute the cacheability
properties of a resource, it must have access to the request and
response headers.The Prefetch TLV contains an HTTP request concatenated with the
corresponding HTTP response. Its format is as follows:The Type SDNV has value 2.The request and response contained in the Prefetch TLV MUST NOT be
infinite in length.The mechanisms that trigger Prefetch TLVs on the sender side, as well
as the way they are interpreted on the receiver side are out of scope
for this document.HTTP depends on the transport protocol (traditionally TCP) to provide
reliability. Over BP, custody transfer SHOULD be used.Implementations of HTTP over BP SHOULD provide user-configurable
timeouts for each HTTP transaction state item that is created. An HTTP
transaction SHOULD be aborted after a user-specified period of
inactivity. The timeouts MAY be much longer than what is commonly used
with TCP.Implementations MAY set bundle lifetimes based on the value of the
Expires HTTP header and/or the Cache-Control "max-age" parameter, when
they are present.Hypertext Transfer Protocol -- HTTP/1.1Department of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425+1(949)824-1715fielding@ics.uci.eduWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682jg@w3.orgCompaq Computer CorporationWestern Research Laboratory250 University AvenuePalo AltoCA94305mogul@wrl.dec.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682frystyk@w3.orgXerox CorporationMIT Laboratory for Computer Science, NE43-3563333 Coyote Hill RoadPalo AltoCA94034masinter@parc.xerox.comMicrosoft Corporation1 Microsoft WayRedmondWA98052paulle@microsoft.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682timbl@w3.org
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
Upgrading to TLS Within HTTP/1.1This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]Bundle Protocol SpecificationThis document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).</t><t> This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.