| Network Working Group | S. Perreault |
| Internet-Draft | J-P. Dionne |
| Intended status: Experimental | Viagénie |
| Expires: February 21, 2013 | August 22, 2012 |
HTTP over Bundle Protocol for Delay-Tolerant Networks (DTN)
draft-perreault-dtnrg-http-00
This document defines how HTTP is transported over DTN using the Bundle Protocol.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
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."
This Internet-Draft will expire on February 21, 2013.
Copyright (c) 2012 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 (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Hypertext Transfer Protocol (HTTP) [RFC2616] 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 [RFC5050]).
HTTP over BP can be used directly by BP nodes as illustrated in Figure 1.
+-------+ +-------+
|HTTP/BP| |HTTP/BP|
|client |=====<BP>=====|server |
+-------+ +-------+
Figure 1: Direct Usage Scenario
Regular HTTP clients and servers can also be accomodated using an HTTP/BP proxy as illustrated in Figure 2. 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.
+--------Logical HTTP proxy--------+
+------+ | +-------+ +-------+ | +------+
| HTTP | | |HTTP/BP| |HTTP/BP| | | HTTP |
|client|---<IP>---| proxy |=====<BP>=====| proxy |---<IP>---|server|
+------+ | +-------+ +-------+ | +------+
+----------------------------------+
Figure 2: Proxied Usage Scenario
DTN is often applied to space networking scenarios. Figure 3 shows one such application.
+--------+ +------------+ +-----------+ +------------+
| Sensor |--| Spacecraft |------<BP>------| 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
...
Figure 3: Use of HTTP over BP in a Space DTN
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 Figure 1 and Figure 3 can be applied to any DTN deployment.
It is intended that the format described in this document have the following features:
HTTP over TLS is implicitly supported with the CONNECT method [RFC2817]. 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 ([RFC5050] 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 :
: :
Figure 4: Generic TLV Format
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 :
: :
Figure 5: Piece Format
Note that the Length field includes the RID and Offset fields.
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 [RFC2616] 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 |
+----------------+---------------+
Figure 6: Close Format
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 /
/ /
| |
+--------------------------------+
Figure 7: Prefetch Format
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.
| [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. |
| [RFC2817] | Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. |
| [RFC5050] | Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. |