idnits 2.17.1 draft-wood-dtnrg-saratoga-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors 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 (October 20, 2013) is 3841 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-tcp-clayer-07 == Outdated reference: A later version (-22) exists of draft-wood-tsvwg-saratoga-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Wood 3 Internet-Draft Surrey alumni 4 Intended status: Experimental J. McKim 5 Expires: April 23, 2014 RSIS 6 W. Eddy 7 MTI Systems 8 W. Ivancic 9 NASA 10 C. Jackson 11 SSTL 12 October 20, 2013 14 Using Saratoga with a Bundle Agent as a Convergence Layer for Delay- 15 Tolerant Networking 16 draft-wood-dtnrg-saratoga-13 18 Abstract 20 Saratoga is a simple, lightweight, UDP-based transfer protocol. This 21 describes how to use Saratoga as a Delay-Tolerant Networking (DTN) 22 "convergence layer" with the Bundle Protocol and its Bundle Agents, 23 building on the Saratoga specification in draft-wood-tsvwg-saratoga. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 23, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 Table of Contents 56 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 58 3. Using Saratoga with a DTN Bundle Agent . . . . . . . . . . . 4 59 4. Proactive and Reactive Fragmentation . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 7. A Note on Naming . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Informative References . . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Background 68 The Saratoga protocol is specified in [I-D.wood-tsvwg-saratoga]. 69 Saratoga can optionally be used for Delay/Disruption-Tolerant 70 Networking (DTN) [RFC4838], as a "convergence layer" to exchange 71 bundles between peer nodes. Saratoga was originally designed prior 72 to work on the Bundle Protocol [RFC5050] by the DTN Research Group 73 (DTNRG). It was later recognized that Saratoga could also be used to 74 reliably exchange bundles between DTNRG Bundle Agents by using a 75 logical mapping from DTNRG bundles to Saratoga files and back. The 76 DTN concept encompasses networks where ad-hoc, intermittent 77 connectivity is expected, connections may be infrequently established 78 or short-lived, and end-to-end paths are not present. As Saratoga 79 was designed for intermittent, disrupted, space communications, 80 Saratoga's operating environment is a DTN network. This makes the 81 Saratoga transfer protocol a natural fit as a convergence layer for 82 the DTNRG's Bundle Protocol, although the Bundle Protocol is not 83 necessary for operation of Saratoga. 85 This document contains notes on use of Saratoga for the bundle 86 transfer procedure. 88 Bundle transfers over Saratoga from space and the UK-DMC satellite, 89 with use of proactive fragmentation, have now been demonstrated. 90 More details are provided in [IAC-2008] [SSTL-2008] [Ivancic10]. 92 2. Applicability Statement 94 Why use Saratoga as a DTN convergence layer? The DTN architecture 95 already has a number of choices of convergence layer. Convergence 96 layers have been proposed for various link types, e.g. Ethernet or 97 Bluetooth. As IP already runs over many link types, a convergence 98 layer that can run over many links using IP is likely to take 99 advantage of TCP or UDP. 101 For traversing the terrestrial Internet while supporting congestion 102 control, a simple TCP convergence layer has been implemented in the 103 DTN software reference implementation [I-D.irtf-dtnrg-tcp-clayer]. A 104 simple UDP convergence layer, able to be used over dedicated private 105 links where congestion control is not required, is also present. 106 However, that simple UDP convergence layer presumes that a bundle 107 will always fit into a single UDP packet, does not support 108 segmentation of bundles across multiple UDP packets, and does not 109 guarantee reliable delivery with retransmissions. Its use is 110 discouraged [I-D.irtf-dtnrg-udp-clayer]. 112 Two protocols capable of supporting segmentation of large bundles 113 across multiple UDP packets, with ARQ-based flexible delivery robust 114 to packet loss, are Saratoga [I-D.wood-tsvwg-saratoga] and the 115 Licklider Transmission Protocol (LTP) [RFC5325]. 117 Both Saratoga and LTP were designed based on experience gained with 118 using the CCSDS File Delivery Protocol (CFDP), which was developed 119 for the Consultative Committee for Space Data Systems (CCSDS). The 120 main design difference between LTP and Saratoga is that LTP transfers 121 arbitrary un-named data blobs (binary large objects), requiring a 122 higher layer (normally delay-tolerant-networking bundling) to handle 123 naming, while Saratoga transfers named files including file metadata, 124 and can be independent of higher layers. Both protocols can run over 125 the User Datagram Protocol, UDP [RFC0768], though LTP also is 126 intended to run at other layers in the stack (including directly over 127 the link), while Saratoga is only intended to run above the UDP or 128 UDP-Lite transport protocols. If errors in delivered content can be 129 tolerated (perhaps because the data being transferred has its own 130 integrity checks), Saratoga can also be used to transfer an entire 131 file or stream without error checking, using UDP-Lite [RFC3828], 132 which can protect only header content from errors. 134 Saratoga includes a file checksum mechanism to detect transfer errors 135 and to provide an overall degree of reliability. Licklider has no 136 similar reliability mechanism, although Licklider's optional security 137 mechanism [RFC5327] can be implemented to give some error detection. 139 Saratoga can also be used for delivery over unidirectional broadcast 140 links. Another UDP-based convergence layer proposed for 141 unidirectional links is Uni-DTN [I-D.kutscher-dtnrg-uni-clayer]. 142 Uni-DTN is based on FLUTE forward layered coding for multicast 143 delivery. Saratoga presumes that the forward error coding needed to 144 prevent errors in transmission is present at another layer in the 145 stack, usually near the physical layer. 147 3. Using Saratoga with a DTN Bundle Agent 149 While Saratoga was first developed for efficient file transfer, the 150 similarity between bundle payloads and files, in that both are 151 arbitrary blobs of some number of octets, allows Saratoga to be used 152 as a convergence layer for exchanging bundles between DTN bundle 153 agents. This section explains the basic concepts involved in mapping 154 bundle exchange onto the file transfer mechanism. 156 Routing of bundles is outside the scope of Saratoga and of this 157 document. Once a complete bundle file has been transferred between 158 peers using Saratoga, that bundle can be forwarded onwards along a 159 next available hop in any way. Saratoga provides a mechanism for 160 forwarding, but does provide input to routing or forwarding 161 decisions. 163 A DTN bundle agent can work alongside a Saratoga peer to move 164 bundles. One simple method of communicating bundles between the 165 bundle agent and the Saratoga peer is to have a shared directory that 166 is accessible to both the bundle and Saratoga processes. To send a 167 bundle, the bundle agent can place the complete bundle (the 168 concatenated set of Bundle Protocol blocks) into a file in this 169 shared directory. The local Saratoga instance is then able to _put_ 170 this bundle to peers or allow them to _get_ it. A flag bit in the 171 Saratoga METADATA and DATA packets indicates whether a particular 172 file is a bundle or not. This enables the receiving Saratoga peer to 173 know whether to handle the file itself, or to pass it to the local 174 bundle agent. 176 When using Saratoga as a convergence layer to transfer bundles, the 177 local bundle agent will either place bundles as files for Saratoga to 178 transfer from its directory, or otherwise use interprocess 179 communication to notify Saratoga of and provide a bundle to be 180 transferred. 182 Key to the use of Saratoga for bundle transfer are: 184 - indicating the capability to interoperate with a local bundle 185 agent. This involves advertising the capability to handle bundles 186 via setting Flag bit 10 in Saratoga BEACON packets, and indicating 187 when a bundle is being transferred by setting Flag bits 10 and 11 in 188 the METADATA and DATA packets. 190 - identifying the Bundle Agent in use, by providing an Endpoint 191 Identifier (EID) in the Saratoga BEACON packet. 193 Note that the name of a file holding a bundle is actually 194 unimportant, as long as it can be determined that it does hold a 195 bundle. The filename becomes temporary, and local only to the 196 transfer. One implementation strategy is to name each bundle file 197 with a file name constructed from two fields of the Primary Bundle 198 Header: the DTN Endpoint Identifier (EID) of the destination node and 199 the bundle's creation time field. In the rare case of filename 200 collisions in using this scheme, additional octets can be appended to 201 the filename following some arbitrary local scheme. Bundle files 202 might be placed in different directories with different Saratoga-peer 203 access controls depending on the intended next-hop, if this 204 information is known ahead of time. In any case, Saratoga only 205 provides the transfer mechanism, and any forwarding decisions based 206 on routing intelligence would be made within the DTN bundle agents. 207 All of this detail is considered a matter of implementation for the 208 bundle agent, and is not specified here. 210 The identity field in the Saratoga BEACON packet allows a local DTN 211 bundle agent to advertise its administrative EID via Saratoga. Other 212 Saratoga peers that hear that BEACON can then notify their local DTN 213 bundle agents of the contact. These notifications might be used to 214 integrate contact information into a routing information base, as 215 they are similar to the "hello" packets used in several routing 216 protocols. However, this is outside the scope of this document. 218 The "epoch" format used in Saratoga timestamps in file object records 219 is the number of seconds since January 1, 2000 in UTC, which is the 220 same epoch used in the DTN Bundle Protocol for timestamps. This must 221 include all leapseconds. 223 We expect that Saratoga instances will often work in conjunction with 224 DTN bundle agents to fill the role of a convergence-layer adapter 225 between bundle agents connected via point-to-point links. Saratoga 226 implementations designed to work this way should have a way of 227 notifying bundle agents when they receive BEACONs from other nodes, 228 and when transfers have completed. In order for custody transfer to 229 function properly, notifications between the Saratoga instances and 230 bundle agents on both sides of a fully-successful bundle file 231 transfer are required. 233 When Saratoga is used as a convergence-layer adapter, it is desirable 234 to turn on Saratoga's end-to-end checksum facilty to provide an 235 indication of correct bundle transfer. This is necessary due to the 236 bundle protocol design not including its own reliability checks for 237 internal robustness. See discussion of this problem with the bundle 238 protocol in [I-D.irtf-dtnrg-bundle-checksum]. 240 4. Proactive and Reactive Fragmentation 242 Proactive fragmentation - splitting a bundle, before transfer, into 243 multiple separate Saratoga transfers that are reassembled after 244 delivery at the receiving peer - is relatively straightforward. 245 Reactive fragmentation - recovery of disrupted partial transfers - is 246 less so. 248 For bundle file transfers, the local bundle agent could interact with 249 Saratoga in order to perform a reactive fragmentation of the bundle 250 whose transfer was interrupted by expiration of the inactivity timer. 251 For DTN custody transfer, we expect complications to be encountered 252 in making this reactive fragmentation work properly, and the details 253 required to implement this functionality are left out of this 254 specification until more experience has been obtained with reactive 255 fragmentation in general. 257 This document does not specify the functionality required for 258 reactive fragmentation of bundles as described in [RFC4838], other 259 than what is needed to support disrupted delivery and hop-by-hop 260 custody transfer of complete bundles. Reactive fragmentation of 261 bundles lies outside the scope of custody transfer of complete 262 bundles, and of this document. 264 However, the status of a transfer that Saratoga provides to a bundle 265 agent could be used to trigger the reactive fragmentation of bundles 266 if a bundle file transfer is interrupted part-way through (assuming 267 at least the bundle protocol headers and some portion of the data was 268 successfully transferred first). This would allow for efficient 269 recovery when unplanned interruptions occur. This requires some 270 coordination between the Saratoga node and the local bundle agent at 271 each end. The local API or coupling between the Saratoga peer and 272 its bundle agent does not affect the interoperability between either 273 the Saratoga peers or the DTN bundle agents, assuming that both sides 274 agree that fragmentation will occur at the lowest un-acknowledged 275 octet of the bundle file after the disruption. Reactive 276 fragmentation and any forwarding of the fragments onwards for 277 reassembly at some downstream node is solely a bundle-agent problem. 279 5. IANA Considerations 281 This document has no actions for IANA. 283 6. Security Considerations 285 When Saratoga is also used with a bundle agent, the security and 286 reliability considerations that have been outlined in detail in 287 [I-D.irtf-dtnrg-bundle-checksum] should be borne in mind. 289 Security in DTNs is in general considered an open issue. If a 290 framework of techniques for handling security in DTN scenarios 291 emerges, Saratoga might be adapted to conform to this. 293 7. A Note on Naming 295 Saratoga is named for the USS Saratoga (CV-3), the aircraft carrier 296 sunk at Bikini Atoll and now a popular diving site. 298 The philosophy behind the protocol and its use described here can be 299 summarized as Saratoga Carries Upper Bundles Adequately, or SCUBA. 301 8. Informative References 303 [I-D.irtf-dtnrg-bundle-checksum] 304 Eddy, W., Wood, L., and W. Ivancic, "Reliability-only 305 Ciphersuites for the Bundle Protocol", draft-irtf-dtnrg- 306 bundle-checksum-09 (work in progress), May 2011. 308 [I-D.irtf-dtnrg-tcp-clayer] 309 Demmer, M., Ott, J., and S. Perreault, "Delay Tolerant 310 Networking TCP Convergence Layer Protocol", draft-irtf- 311 dtnrg-tcp-clayer-07 (work in progress), September 2013. 313 [I-D.irtf-dtnrg-udp-clayer] 314 Kruse, H. and S. Ostermann, "UDP Convergence Layers for 315 the DTN Bundle and LTP Protocols", draft-irtf-dtnrg-udp- 316 clayer-00 (work in progress), November 2008. 318 [I-D.kutscher-dtnrg-uni-clayer] 319 Kutscher, D., "Uni-DTN: A DTN Convergence Layer Protocol 320 for Unidirectional Transport", draft-kutscher-dtnrg-uni- 321 clayer-00 (work in progress), April 2007. 323 [I-D.wood-tsvwg-saratoga] 324 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 325 Jackson, "Saratoga: A Scalable File Transfer Protocol", 326 draft-wood-tsvwg-saratoga-14 (work in progress) , October 327 2013. 329 [IAC-2008] 330 Wood, L., Ivancic, W., Eddy, W., Stewart, D., Northam, J., 331 Jackson, C., and A. da Silva Curiel, "Use of the Delay- 332 Tolerant Networking Bundle Protocol from Space", 333 conference paper IAC-08-B.2.3.10, 59th International 334 Astronautical Congress, Glasgow , September 2008. 336 [Ivancic10] 337 Ivancic, W., Eddy, W., Stewart, D., Wood, L., Northam, J., 338 and C. Jackson, "Experience with delay-tolerant networking 339 from orbit", International Journal of Satellite 340 Communications and Networking, Special Issue on best 341 papers of the Fourth Advanced Satellite Mobile Systems 342 Conference (ASMS 2008), vol. 28, issues 5-6, pp. 335-351, 343 September-December 2010. 345 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 346 August 1980. 348 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 349 G. Fairhurst, "The Lightweight User Datagram Protocol 350 (UDP-Lite)", RFC 3828, July 2004. 352 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 353 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 354 Networking Architecture", RFC 4838, April 2007. 356 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 357 Specification", RFC 5050, November 2007. 359 [RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider 360 Transmission Protocol - Motivation", RFC 5325, September 361 2008. 363 [RFC5327] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 364 Transmission Protocol - Security Extensions", RFC 5327, 365 September 2008. 367 [SSTL-2008] 368 , "UK-DMC satellite first to transfer sensor data from 369 space using 'bundle' protocol", press release, Surrey 370 Satellite Technology Ltd , September 2008. 372 Authors' Addresses 373 Lloyd Wood 374 University of Surrey alumni 375 Sydney, New South Wales 376 Australia 378 Email: L.Wood@society.surrey.ac.uk 380 Jim McKim 381 RS Information Systems 382 NASA Glenn Research Center 383 21000 Brookpark Road, MS 142-1 384 Cleveland, OH 44135 385 USA 387 Phone: +1-216-433-6536 388 Email: James.H.McKim@grc.nasa.gov 390 Wesley M. Eddy 391 MTI Systems 392 MS 500-ASRC 393 NASA Glenn Research Center 394 21000 Brookpark Road 395 Cleveland, OH 44135 396 USA 398 Phone: +1-216-433-6682 399 Email: weddy@grc.nasa.gov 401 Will Ivancic 402 NASA Glenn Research Center 403 21000 Brookpark Road, MS 54-5 404 Cleveland, OH 44135 405 USA 407 Phone: +1-216-433-3494 408 Email: William.D.Ivancic@grc.nasa.gov 409 Chris Jackson 410 Surrey Satellite Technology Ltd 411 Tycho House 412 Surrey Space Centre 413 20 Stephenson Road 414 Guildford, Surrey GU2 7YE 415 United Kingdom 417 Phone: +44-1483-803-803 418 Email: C.Jackson@sstl.co.uk