idnits 2.17.1 draft-wood-dtnrg-saratoga-07.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 (May 8, 2010) is 5102 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-bundle-checksum-07 == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-tcp-clayer-02 == Outdated reference: A later version (-22) exists of draft-wood-tsvwg-saratoga-05 Summary: 0 errors (**), 0 flaws (~~), 4 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 University of Surrey 4 Intended status: Experimental J. McKim 5 Expires: November 9, 2010 RSIS 6 W. Eddy 7 ASRC 8 W. Ivancic 9 NASA 10 C. Jackson 11 SSTL 12 May 8, 2010 14 Using Saratoga with a Bundle Agent 15 as a Convergence Layer for Delay-Tolerant Networking 16 draft-wood-dtnrg-saratoga-07 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 November 9, 2010. 42 Copyright Notice 44 Copyright (c) 2010 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. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3 61 3. Using Saratoga with a DTN Bundle Agent . . . . . . . . . . . . 4 62 4. Proactive and Reactive Fragmentation . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 7. A Note on Naming . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. Informative References . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Background 71 The Saratoga protocol is specified in [I-D.wood-tsvwg-saratoga]. 72 Saratoga can optionally be used for Delay/Disruption-Tolerant 73 Networking (DTN) [RFC4838], as a "convergence layer" to exchange 74 bundles between peer nodes. Saratoga was originally designed prior 75 to work on the Bundle Protocol [RFC5050] by the DTN Research Group 76 (DTNRG). It was later recognized that Saratoga could also be used to 77 reliably exchange bundles between DTNRG Bundle Agents by using a 78 logical mapping from DTNRG bundles to Saratoga files and back. The 79 DTN concept encompasses networks where ad-hoc, intermittent 80 connectivity is expected, connections may be infrequently established 81 or short-lived, and end-to-end paths are not present. As Saratoga 82 was designed for intermittent, disrupted, space communications, 83 Saratoga's operating environment is a DTN network. This makes the 84 Saratoga transfer protocol a natural fit as a convergence layer for 85 the DTNRG's Bundle Protocol, although the Bundle Protocol is not 86 necessary for operation of Saratoga. 88 This document contains notes on use of Saratoga for the bundle 89 transfer procedure. 91 Bundle transfers over Saratoga from space and the UK-DMC satellite, 92 with use of proactive fragmentation, have now been demonstrated. 93 More details are provided in [IAC-2008] [SSTL-2008]. 95 2. Applicability Statement 97 Why use Saratoga as a DTN convergence layer? The DTN architecture 98 already has a number of choices of convergence layer. Convergence 99 layers have been proposed for various link types, e.g. Ethernet or 100 Bluetooth. As IP already runs over many link types, a convergence 101 layer that can run over many links using IP is likely to take 102 advantage of TCP or UDP. 104 For traversing the terrestrial Internet while supporting congestion 105 control, a simple TCP convergence layer has been implemented in the 106 DTN software reference implementation [I-D.irtf-dtnrg-tcp-clayer]. A 107 simple UDP convergence layer, able to be used over dedicated private 108 links where congestion control is not required, is also present. 109 However, that simple UDP convergence layer presumes that a bundle 110 will always fit into a single UDP packet, does not support 111 segmentation of bundles across multiple UDP packets, and does not 112 guarantee reliable delivery with retransmissions. Its use is 113 discouraged [I-D.irtf-dtnrg-udp-clayer]. 115 Two protocols capable of supporting segmentation of large bundles 116 across multiple UDP packets, with ARQ-based flexible delivery robust 117 to packet loss, are Saratoga [I-D.wood-tsvwg-saratoga] and the 118 Licklider Transmission Protocol (LTP) [RFC5325]. 120 Both Saratoga and LTP were designed based on experience gained with 121 using the CCSDS File Delivery Protocol (CFDP), which was developed 122 for the Consultative Committee for Space Data Systems (CCSDS). The 123 main design difference between LTP and Saratoga is that LTP transfers 124 arbitrary un-named data blobs (binary large objects), requiring a 125 higher layer (normally delay-tolerant-networking bundling) to handle 126 naming, while Saratoga transfers named files including file metadata, 127 and can be independent of higher layers. Both protocols can run over 128 the User Datagram Protocol, UDP [RFC0768], though LTP also is 129 intended to run at other layers in the stack (including directly over 130 the link), while Saratoga is only intended to run above the UDP or 131 UDP-Lite transport protocols. If errors in delivered content can be 132 tolerated (perhaps because the data being transferred has its own 133 integrity checks), Saratoga can also be used to transfer an entire 134 file or stream without error checking, using UDP-Lite [RFC3828], 135 which can protect only header content from errors. 137 Saratoga includes a file checksum mechanism to detect transfer errors 138 and to provide an overall degree of reliability. Licklider has no 139 similar reliability mechanism, although Licklider's optional security 140 mechanism [RFC5327] can be implemented to give some error detection. 142 Saratoga can also be used for delivery over unidirectional broadcast 143 links. Another UDP-based convergence layer proposed for 144 unidirectional links is Uni-DTN [I-D.kutscher-dtnrg-uni-clayer]. 145 Uni-DTN is based on FLUTE forward layered coding for multicast 146 delivery. Saratoga presumes that the forward error coding needed to 147 prevent errors in transmission is present at another layer in the 148 stack, usually near the physical layer. 150 3. Using Saratoga with a DTN Bundle Agent 152 While Saratoga was first developed for efficient file transfer, the 153 similarity between bundle payloads and files, in that both are 154 arbitrary blobs of some number of octets, allows Saratoga to be used 155 as a convergence layer for exchanging bundles between DTN bundle 156 agents. This section explains the basic concepts involved in mapping 157 bundle exchange onto the file transfer mechanism. 159 Routing of bundles is outside the scope of Saratoga and of this 160 document. Once a complete bundle file has been transferred between 161 peers using Saratoga, that bundle can be forwarded onwards along a 162 next available hop in any way. Saratoga provides a mechanism for 163 forwarding, but does provide input to routing or forwarding 164 decisions. 166 A DTN bundle agent can work alongside a Saratoga peer to move 167 bundles. One simple method of communicating bundles between the 168 bundle agent and the Saratoga peer is to have a shared directory that 169 is accessible to both the bundle and Saratoga processes. To send a 170 bundle, the bundle agent can place the complete bundle (the 171 concatenated set of Bundle Protocol blocks) into a file in this 172 shared directory. The local Saratoga instance is then able to _put_ 173 this bundle to peers or allow them to _get_ it. A flag bit in the 174 Saratoga METADATA and DATA packets indicates whether a particular 175 file is a bundle or not. This enables the receiving Saratoga peer to 176 know whether to handle the file itself, or to pass it to the local 177 bundle agent. 179 When using Saratoga as a convergence layer to transfer bundles, the 180 local bundle agent will either place bundles as files for Saratoga to 181 transfer from its directory, or otherwise use interprocess 182 communication to notify Saratoga of and provide a bundle to be 183 transferred. 185 Key to the use of Saratoga for bundle transfer are: 187 - indicating the capability to interoperate with a local bundle 188 agent. This involves advertising the capability to handle bundles 189 via setting Flag bit 10 in Saratoga BEACON packets, and indicating 190 when a bundle is being transferred by setting Flag bits 10 and 11 in 191 the METADATA and DATA packets. 193 - identifying the Bundle Agent in use, by providing an Endpoint 194 Identifier (EID) in the Saratoga BEACON packet. 196 Note that the name of a file holding a bundle is actually 197 unimportant, as long as it can be determined that it does hold a 198 bundle. The filename becomes temporary, and local only to the 199 transfer. One implementation strategy is to name each bundle file 200 with a file name constructed from two fields of the Primary Bundle 201 Header: the DTN Endpoint Identifier (EID) of the destination node and 202 the bundle's creation time field. In the rare case of filename 203 collisions in using this scheme, additional octets can be appended to 204 the filename following some arbitrary local scheme. Bundle files 205 might be placed in different directories with different Saratoga-peer 206 access controls depending on the intended next-hop, if this 207 information is known ahead of time. In any case, Saratoga only 208 provides the transfer mechanism, and any forwarding decisions based 209 on routing intelligence would be made within the DTN bundle agents. 210 All of this detail is considered a matter of implementation for the 211 bundle agent, and is not specified here. 213 The identity field in the Saratoga BEACON packet allows a local DTN 214 bundle agent to advertise its administrative EID via Saratoga. Other 215 Saratoga peers that hear that BEACON can then notify their local DTN 216 bundle agents of the contact. These notifications might be used to 217 integrate contact information into a routing information base, as 218 they are similar to the "hello" packets used in several routing 219 protocols. However, this is outside the scope of this document. 221 The "epoch" format used in Saratoga timestamps in file object records 222 is the number of seconds since January 1, 2000 in UTC, which is the 223 same epoch used in the DTN Bundle Protocol for timestamps. This 224 should include all leapseconds. 226 We expect that Saratoga instances will often work in conjunction with 227 DTN bundle agents to fill the role of a convergence-layer adapter 228 between bundle agents connected via point-to-point links. Saratoga 229 implementations designed to work this way should have a way of 230 notifying bundle agents when they receive BEACONs from other nodes, 231 and when transfers have completed. In order for custody transfer to 232 function properly, notifications between the Saratoga instances and 233 bundle agents on both sides of a fully-successful bundle file 234 transfer are required. 236 When Saratoga is used as a convergence-layer adapter, it is desirable 237 to turn on Saratoga's end-to-end checksum facilty to provide an 238 indication of correct bundle transfer. This is necessary due to the 239 bundle protocol design not including its own reliability checks for 240 internal robustness. See discussion of this problem with the bundle 241 protocol in [I-D.irtf-dtnrg-bundle-checksum]. 243 4. Proactive and Reactive Fragmentation 245 Proactive fragmentation - splitting a bundle, before transfer, into 246 multiple separate Saratoga transfers that are reassembled after 247 delivery at the receiving peer - is relatively straightforward. 248 Reactive fragmentation - recovery of disrupted partial transfers - is 249 less so. 251 For bundle file transfers, the local bundle agent could interact with 252 Saratoga in order to perform a reactive fragmentation of the bundle 253 whose transfer was interrupted by expiration of the inactivity timer. 254 For DTN custody transfer, we expect complications to be encountered 255 in making this reactive fragmentation work properly, and the details 256 required to implement this functionality are left out of this 257 specification until more experience has been obtained with reactive 258 fragmentation in general. 260 This document does not specify the functionality required for 261 reactive fragmentation of bundles as described in [RFC4838], other 262 than what is needed to support disrupted delivery and hop-by-hop 263 custody transfer of complete bundles. Reactive fragmentation of 264 bundles lies outside the scope of custody transfer of complete 265 bundles, and of this document. 267 However, the status of a transfer that Saratoga provides to a bundle 268 agent could be used to trigger the reactive fragmentation of bundles 269 if a bundle file transfer is interrupted part-way through (assuming 270 at least the bundle protocol headers and some portion of the data was 271 successfully transferred first). This would allow for efficient 272 recovery when unplanned interruptions occur. This requires some 273 coordination between the Saratoga node and the local bundle agent at 274 each end. The local API or coupling between the Saratoga peer and 275 its bundle agent does not affect the interoperability between either 276 the Saratoga peers or the DTN bundle agents, assuming that both sides 277 agree that fragmentation will occur at the lowest un-acknowledged 278 octet of the bundle file after the disruption. Reactive 279 fragmentation and any forwarding of the fragments onwards for 280 reassembly at some downstream node is solely a bundle-agent problem. 282 5. IANA Considerations 284 This document has no actions for IANA. 286 6. Security Considerations 288 When Saratoga is also used with a bundle agent, the security and 289 reliability considerations that have been outlined in detail in 290 [I-D.irtf-dtnrg-bundle-checksum] should be borne in mind. 292 Security in DTNs is in general considered an open issue. If a 293 framework of techniques for handling security in DTN scenarios 294 emerges, Saratoga might be adapted to conform to this. 296 7. A Note on Naming 298 Saratoga is named for the USS Saratoga (CV-3), the aircraft carrier 299 sunk at Bikini Atoll and now a popular diving site. 301 The philosophy behind the protocol and its use described here can be 302 summarized as Saratoga Carries Upper Bundles Adequately, or SCUBA. 304 8. Informative References 306 [I-D.irtf-dtnrg-bundle-checksum] 307 Eddy, W., Wood, L., and W. Ivancic, "Reliability-only 308 Ciphersuites for the Bundle Protocol", 309 draft-irtf-dtnrg-bundle-checksum-07 (work in progress) , 310 May 2010. 312 [I-D.irtf-dtnrg-tcp-clayer] 313 Demmer, M. and J. Ott, "Delay Tolerant Networking TCP 314 Convergence Layer Protocol", 315 draft-irtf-dtnrg-tcp-clayer-02 (work in progress), 316 November 2008. 318 [I-D.irtf-dtnrg-udp-clayer] 319 Kruse, H. and S. Ostermann, "UDP Convergence Layers for 320 the DTN Bundle and LTP Protocols", 321 draft-irtf-dtnrg-udp-clayer-00 (work in progress), 322 November 2008. 324 [I-D.kutscher-dtnrg-uni-clayer] 325 Kutscher, D., "Uni-DTN: A DTN Convergence Layer Protocol 326 for Unidirectional Transport", 327 draft-kutscher-dtnrg-uni-clayer-00 (work in progress), 328 April 2007. 330 [I-D.wood-tsvwg-saratoga] 331 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 332 Jackson, "Saratoga: A Scalable File Transfer Protocol", 333 draft-wood-tsvwg-saratoga-05 (work in progress) , 334 May 2010. 336 [IAC-2008] 337 Wood, L., Ivancic, W., Eddy, W., Stewart, D., Northam, J., 338 Jackson, C., and A. da Silva Curiel, "Use of the Delay- 339 Tolerant Networking Bundle Protocol from Space", 340 conference paper IAC-08-B.2.3.10, 59th International 341 Astronautical Congress, Glasgow , September 2008. 343 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 344 August 1980. 346 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 347 G. Fairhurst, "The Lightweight User Datagram Protocol 348 (UDP-Lite)", RFC 3828, July 2004. 350 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 351 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 352 Networking Architecture", RFC 4838, April 2007. 354 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 355 Specification", RFC 5050, November 2007. 357 [RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider 358 Transmission Protocol - Motivation", RFC 5325, 359 September 2008. 361 [RFC5327] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 362 Transmission Protocol - Security Extensions", RFC 5327, 363 September 2008. 365 [SSTL-2008] 366 "UK-DMC satellite first to transfer sensor data from space 367 using 'bundle' protocol", press release, Surrey Satellite 368 Technology Ltd , September 2008. 370 Authors' Addresses 372 Lloyd Wood 373 Centre for Communication Systems Research, University of Surrey 374 Guildford, Surrey GU2 7XH 375 United Kingdom 377 Phone: +44-1483-698123 378 Email: L.Wood@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 389 Wesley M. Eddy 390 ASRC Aerospace Corporation 391 MS 500-ASRC 392 NASA Glenn Research Center 393 21000 Brookpark Road, MS 54-5 394 Cleveland, OH 44135 395 USA 397 Phone: +1-216-433-6682 398 Email: weddy@grc.nasa.gov 400 Will Ivancic 401 NASA Glenn Research Center 402 21000 Brookpark Road, MS 54-5 403 Cleveland, OH 44135 404 USA 406 Phone: +1-216-433-3494 407 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