Internet DRAFT - draft-perreault-dtnrg-http
draft-perreault-dtnrg-http
Network Working Group S. Perreault
Internet-Draft J-P. Dionne
Intended status: Experimental Viagenie
Expires: February 23, 2013 August 22, 2012
HTTP over Bundle Protocol for Delay-Tolerant Networks (DTN)
draft-perreault-dtnrg-http-00
Abstract
This document defines how HTTP is transported over DTN using the
Bundle Protocol.
Status of this Memo
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 23, 2013.
Copyright Notice
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.
Perreault & Dionne Expires February 23, 2013 [Page 1]
Internet-Draft HTTP over BP August 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Example Use Case . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Considerations . . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. HTTP over TLS . . . . . . . . . . . . . . . . . . . . . . . 5
4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Piece . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Close . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Prefetch . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Perreault & Dionne Expires February 23, 2013 [Page 2]
Internet-Draft HTTP over BP August 2012
1. Introduction
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
2. Example Use Case
DTN is often applied to space networking scenarios. Figure 3 shows
one such application.
Perreault & Dionne Expires February 23, 2013 [Page 3]
Internet-Draft HTTP over BP August 2012
+--------+ +------------+ +-----------+ +------------+
| 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.
3. Design Considerations
3.1. Requirements
It is intended that the format described in this document have the
following features:
o Support for partial HTTP messages because HTTP message length can
be larger than bundle payload length.
o Support for multiple HTTP messages per bundle for efficiency
purposes.
Perreault & Dionne Expires February 23, 2013 [Page 4]
Internet-Draft HTTP over BP August 2012
o Support for infinite-length HTTP messages because those HTTP
messages are used, for example, in media streaming.
o 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.
3.2. HTTP over TLS
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.
4. Message Format
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
Type: An SDNV identifying the TLV type.
Length: An SDNV containing the length of the Value field, in bytes.
Value: 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.
Perreault & Dionne Expires February 23, 2013 [Page 5]
Internet-Draft HTTP over BP August 2012
4.1. Piece
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.
RID (Request ID): An SDNV uniquely identifying the request/response
exchange.
Offset: 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
Perreault & Dionne Expires February 23, 2013 [Page 6]
Internet-Draft HTTP over BP August 2012
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).
4.2. Close
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.
4.3. Prefetch
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:
Perreault & Dionne Expires February 23, 2013 [Page 7]
Internet-Draft HTTP over BP August 2012
+----------------+---------------+
| 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.
4.4. Reliability
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.
5. References
[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
Perreault & Dionne Expires February 23, 2013 [Page 8]
Internet-Draft HTTP over BP August 2012
HTTP/1.1", RFC 2817, May 2000.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
Authors' Addresses
Simon Perreault
Viagenie
246 Aberdeen
Quebec, QC G1R 2E1
Canada
Phone: +1 418 656 9254
Email: simon.perreault@viagenie.ca
URI: http://viagenie.ca
Jean-Philippe Dionne
Viagenie
246 Aberdeen
Quebec, QC G1R 2E1
Canada
Phone: +1 418 656 9254
Email: simon.perreault@viagenie.ca
URI: http://viagenie.ca
Perreault & Dionne Expires February 23, 2013 [Page 9]
