HTTP over Bundle Protocol for Delay-Tolerant Networks (DTN)

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 .

=====|server | +-------+ +-------+ ]]> 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.

---| proxy |==========| proxy |------|server| +------+ | +-------+ +-------+ | +------+ +----------------------------------+ ]]>

DTN is often applied to space networking scenarios. shows one such application.

------| Mission |--| Monitoring | | (HTTP | +----+-------+ | operation | | station | | server)| |HTTP/BP| +-------+--+ | (HTTP | +--------+ | proxy | |HTTP/BP| | client) | +-------+ | proxy | +------------+ +-------+ |-----------IP-----------| |------------IP-------------| <-------------------------------------- GET /sensors/heartbeat HTTP/1.1 Host: sensor.example.net HTTP/1.1 200 OK ------------------------------------------------------> Content-Length: ... Content-Type: text/html ... ]]> 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:

+----------------+---------------+ | Type | Length | +----------------+---------------+ : : : Value : : : 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:

+----------------+---------------+ | Type (0) | Length | +----------------+---------------+ | RID | Offset | +----------------+---------------+ : : : Piece of HTTP : : : 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:

+----------------+---------------+ | Type (1) | Length | +----------------+---------------+ | RID | Offset | +----------------+---------------+ 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:

+----------------+---------------+ | Type (2) | Length | +----------------+---------------+ | | / HTTP request / / / | | +--------------------------------+ | | / HTTP response / / / | | +--------------------------------+ 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.