idnits 2.17.1 draft-wood-dtnrg-http-dtn-delivery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 2008) is 5887 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-bundle-checksum-02 == Outdated reference: A later version (-22) exists of draft-wood-tsvwg-saratoga-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Wood 3 Internet-Draft P. Holliday 4 Intended status: Experimental Cisco Systems 5 Expires: September 14, 2008 March 13, 2008 7 Using HTTP for delivery in Delay/Disruption-Tolerant Networks 8 draft-wood-dtnrg-http-dtn-delivery-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 14, 2008. 35 Abstract 37 This document describes how to use the Hypertext Transfer Protocol, 38 http, for communication across delay- and disruption-tolerant 39 networks. http is well-known and simpler to deploy in these networks 40 than custom specialised alternatives such as the Bundle Protocol. 42 Table of Contents 44 1. Background and Introduction . . . . . . . . . . . . . . . . . . 3 45 2. Adapting the http delivery mechanism for DTNs . . . . . . . . . 4 46 3. Other useful proposed http headers . . . . . . . . . . . . . . 5 47 4. Other suggestions on http for dtn use . . . . . . . . . . . . . 6 48 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 49 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 50 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 51 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 53 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 55 Intellectual Property and Copyright Statements . . . . . . . . . . 9 57 1. Background and Introduction 59 Delay- and Disruption-Tolerant Networks (DTNs) are networks where 60 conditions are such that links between nodes are not always 61 permanent, may be of very long delay or exist only during very short 62 contact periods where the link is up, and may change over time 63 [RFC4838]. Some DTNs can be thought of as sparse ad-hoc networks, 64 with nodes communicating intermittently only when they come into 65 contact. Store-and-forward delivery of data is a useful way of 66 communicating across these networks. 68 A specialised store-and-forward protocol for DTN delivery has been 69 proposed in the IRTF DTN research group (DTNRG) - the Bundle Protocol 70 [RFC5050]. Criticisms of the Bundle Protocol's reliability and 71 complexity have been raised [I-D.irtf-dtnrg-bundle-checksum]. 73 This document outlines how the well-known Hypertext Transfer Protocol 74 (http) [RFC2616] can be used for store-and-forward communication 75 across DTNs. http is not used end-to-end as it is on the web. 76 Instead, applications running on each node in the network communicate 77 with their neighbours using dedicated hop-by-hop http transfers to 78 effect local data delivery. Additional http header information adds 79 context for onward forwarding and delivery to destination endpoints, 80 and provides the reliability and error-detection missing from 81 alternatives such as the Bundle Protocol. 83 http is a session layer, running over a transport layer providing 84 reliable delivery of the http stream between hops. This transport 85 layer is commonly TCP, although alternatives, such as SCTP, can also 86 be used. For long-delay networks, or for network conditions where 87 TCP or an equivalent is not suitable, an alternative transport layer 88 such as Saratoga [I-D.wood-tsvwg-saratoga] could be used under http 89 instead in hop-by-hop communications between nodes. 91 Steve Deering has often described IP as 'the waist in the hourglass' 92 - what is above IP can be changed, what is below IP can be changed, 93 but provided the new elements continue to interface to and work with 94 IP, the network stack remains functional. Here, http is the waist in 95 this particular hourglass; applications can use http to communicate, 96 provided http runs over a reliable transport stream. The transport 97 stream can be changed; http does not have to run over TCP/IP, but 98 could even be made to run directly over HDLC or a CCSDS reliable 99 bitstream. 101 This document contains an overview of how http can be simply adapted 102 to the DTN environment by the use of http/1.1 with persistence and 103 pipelining, the PUT and GET directives, and some trivial extra http 104 headers needed to indicate e.g. a destination in the DTN network. 106 The remainder of this specification uses 'file' as a shorthand for 107 'binary object', which may be an http 'object', file with an 108 associated MIMEtype, or other type of contiguous binary data. 110 A benefit to use of http is that the well-known MIMEtype mechanism, 111 used by http, provides hints on what received files are, and what 112 applications should do with them. The Bundle Protocol does not 113 support MIMEtypes, or any similar mechanism. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119. [RFC2119] 119 2. Adapting the http delivery mechanism for DTNs 121 Here, http is used as a peer-to-peer protocol in the sense that 122 multiple files may be transferred in both directions simultaneously 123 between two communicating nodes using http for DTN use. There is not 124 intended to be a strict client/user-agent to server relationship as 125 there is in the web. Instead, sending data across a path of six 126 nodes, four nodes between source and destination, will require a 127 minimum of five separate per-hop http transactions between each pair 128 of nodes to move the data onwards to the next node. This breaks the 129 traditional end-to-end control loop and transfer into separate 130 control loops and transfers suitable for the DTN environment. 132 When two nodes come into contact, a request for files to be copied, 133 stored, and carried onwards can be made by the receiving node issuing 134 an http GET request. Alternatively, the sending node can simply 135 issue a series of http PUT requests once a connection is established, 136 if it believes that putting the data to the receiving node moves it 137 closer to its eventual destination. The receiving node can always 138 reject transfers with error codes. 140 http/1.1 pipelining and persistence permits multiple PUTs to be made 141 in sequence. Support for these in implementations is crucial to the 142 mechanisms outlined here. 144 The key to enabling http use for DTN networking is an added Content- 145 Destination: header, which specifies the final destination of the 146 file, and can be used by routing in the http-using applications to 147 decide over which links the file should be sent. Content-* headers 148 are special, in that they may not be ignored (section 9.6 of 149 [RFC2119]). Recipients not understanding Content-Destination: will 150 generate a 501 (Not Implemented) error code. This separates http use 151 in DTNs described here from normal end-to-end http web use. http DTN 152 nodes MUST support Content-Destination: 154 The information provided in Content-Destination: identifying the 155 destination may be an IP address, DNS name, Bundle Endpoint 156 Identifier (EID) or other text-string identifier useful to the local 157 DTN routing mechanisms being used. 159 Similarly, a Content-Source: header provides the original source of 160 the data. This MUST be implemented. 162 For DTN use, DTN http nodes MUST also implement Content-Length:, 163 Content-Range: and Content-MD5 headers. This permits partial 164 delivery of files and resends of missing pieces. The Content-MD5: 165 header provides a simple end-to-end reliability check. The Content- 166 MD5: header is intended to be generated by the source node first 167 sending the data, and not recomputed at other nodes. 169 DTN http nodes MUST implement the Host: header. This field MAY be 170 left blank to request available files from the peer node, rather than 171 identifying a desired file from a distant source by hostname. A 172 sender placing a new file into the DTN network for onward 173 transmission MUST have the Content-Source: field of the data being 174 sent match its Host: field. 176 Hop-by-hop http headers MAY be implemented. The headers described in 177 section 13.5.1 of [RFC2616] are available. New hop-by-hop headers 178 MUST use the Connection: header approach described in section 14.10 179 of [RFC2616]. 181 DTN http nodes may GET and PUT to link-local multicast addresses. 182 This permits efficient sharing of files on shared LANs, with 183 recipients requesting resends via Content-Range: and checking 184 assembly of file pieces using the Content-MD5: header. 186 3. Other useful proposed http headers 188 A number of other http headers are proposed here, as likely to be 189 useful. These SHOULD be implemented. 191 An http object is just one binary file; the ability to group objects 192 together is useful (and is done in bundles by the bundle protocol). 193 If we call a group of related objects travelling together between the 194 same source and destination a 'package' (a name chosen to avoid any 195 confusion with the 'bundle' specification), we can then define simple 196 headers to be sent before each object: 198 Package-ID: - provides a unique text-string identifier for the 199 package 200 Package-Item: n of m (e.g. 1 of 7) - order of this http file in the 201 package 203 Package-MD5: - checksum across all Content-MD5 headers added together 204 in order 206 A way to request missing Package-Items (from the previous node or 207 from the source) is likely to be very useful. 209 Some sort of header protection is likely also a good idea. So, 210 Header-MD5: could cover some important http headers. Header-MD5 211 could be preserved across hops if possible, avoiding unnecessary 212 header reordering. Timestamps prevent this, however - this needs 213 more thought, particularly on where timestamps are placed in http 214 headers. 216 Timestamps and how they are handled needs to be examined here in 217 greater detail. What if different machines have different notions of 218 time? 220 For larger files, stronger checksums than MD5 should be looked at. 222 4. Other suggestions on http for dtn use 224 x-application-dtn has previously been proposed as a MIMEtype 225 identifying Bundle Protocol bundles delivered by http. This provides 226 a way to support legacy Bundle Protocol implementations to upgrade in 227 http. 229 Moving http transfers over DTN networks using the Bundle Protocol has 230 already been proposed [Ott06]. By changing how http is used - hop- 231 by-hop rather than end-to-end - this draft has outlined how http can 232 be used directly and independently in DTN networks without requiring 233 the bundle protocol as a carrier. 235 5. Security Considerations 237 Security considerations and examination of https is required here. 239 Because there is a need for each node to validate that a file has 240 been received correctly, privately-keyed hashes that can only be 241 checked at the destination should be avoided, and http security 242 mechanisms should be used instead. 244 6. IANA Considerations 246 It may make sense to use a non-standard port for http use, rather 247 than the well-known port 80. If so, such a port should be requested 248 from IANA. 250 It may be necessary to request a dedicated IPv4 all-hosts multicast 251 address and a dedicated IPv6 link-local multicast addresses for local 252 http DTN use, if local http multicast is considered desirable. 254 7. Acknowledgements 256 Work on the Saratoga protocol inspired some of the concepts used 257 here. We thank Wes Eddy for his review comments. 259 8. References 261 8.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 267 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 268 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 270 8.2. Informative References 272 [I-D.irtf-dtnrg-bundle-checksum] 273 Eddy, W., Wood, L., and W. Ivancic, "Checksum Ciphersuites 274 for the Bundle Protocol", 275 draft-irtf-dtnrg-bundle-checksum-02 (work in progress), 276 March 2008. 278 [I-D.wood-tsvwg-saratoga] 279 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 280 Jackson, "Saratoga: A Scalable File Transfer Protocol", 281 draft-wood-tsvwg-saratoga-01 (work in progress), 282 February 2008. 284 [Ott06] Ott, J. and D. Kutscher, "Bundling the Web: HTTP over 285 DTN", WNEPT 2006 Workshop on Networking in Public 286 Transport, QShine Conference Ontario, August 2006. 288 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 289 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 290 Networking Architecture", RFC 4838, April 2007. 292 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 293 Specification", RFC 5050, November 2007. 295 Authors' Addresses 297 Lloyd Wood 298 Cisco Systems 299 11 New Square Park, Bedfont Lakes 300 Feltham, Middlesex TW14 8HA 301 United Kingdom 303 Phone: +44-20-8824-4236 304 Email: lwood@cisco.com 306 Peter Holliday 307 Cisco Systems 308 Level 12 309 300 Adelaide Street 310 Brisbane, Queensland 4000 311 Australia 313 Phone: +61-2-6216-0604 314 Email: phollida@cisco.com 316 Full Copyright Statement 318 Copyright (C) The IETF Trust (2008). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 327 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 328 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 329 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org.