idnits 2.17.1 draft-wood-tsvwg-saratoga-05.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 5095 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3309 (Obsoleted by RFC 4960) == Outdated reference: A later version (-10) exists of draft-ietf-ledbat-congestion-01 == Outdated reference: A later version (-09) exists of draft-wood-dtnrg-http-dtn-delivery-05 == Outdated reference: A later version (-14) exists of draft-wood-dtnrg-saratoga-07 -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 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 MTI Systems 8 W. Ivancic 9 NASA 10 C. Jackson 11 SSTL 12 May 8, 2010 14 Saratoga: A Scalable File Transfer Protocol 15 draft-wood-tsvwg-saratoga-05 17 Abstract 19 This document specifies the Saratoga transfer protocol. Saratoga was 20 originally developed to efficiently transfer remote-sensing imagery 21 from a low-Earth-orbiting satellite constellation, but is useful for 22 many other scenarios, including ad-hoc peer-to-peer communications, 23 delay-tolerant networking, and grid computing. Saratoga is a simple, 24 lightweight, content dissemination protocol that builds on UDP, and 25 optionally uses UDP-Lite. Saratoga is intended for use when moving 26 files or streaming data between peers which may have only sporadic or 27 intermittent connectivity, and is capable of transferring very large 28 amounts of data reliably under adverse conditions. The Saratoga 29 protocol is designed to cope with highly asymmetric link or path 30 capacity between peers, and can support fully-unidirectional data 31 transfer if required. In scenarios with dedicated links, Saratoga 32 focuses on high link utilization to make the most of limited 33 connectivity times, while standard congestion control mechanisms can 34 be implemented for operation over shared links. Loss recovery is 35 implemented via a simple negative-ack ARQ mechanism. The protocol 36 specified in this document is considered to be appropriate for 37 experimental use on private IP networks. 39 Status of this Memo 41 This Internet-Draft is submitted to IETF in full conformance with the 42 provisions of BCP 78 and BCP 79. This document may not be modified, 43 and derivative works of it may not be created, except to format it 44 for publication as an RFC and to translate it into languages other 45 than English. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on November 9, 2010. 59 Copyright Notice 61 Copyright (c) 2010 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Background and Introduction . . . . . . . . . . . . . . . . . 4 77 2. Overview of Saratoga File Transfer . . . . . . . . . . . . . . 6 78 3. Optional Parts of Saratoga . . . . . . . . . . . . . . . . . . 11 79 4. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.1. BEACON . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 4.3. METADATA . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 4.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 4.5. HOLESTOFILL . . . . . . . . . . . . . . . . . . . . . . . 27 85 5. The Directory Entry . . . . . . . . . . . . . . . . . . . . . 33 86 6. Behavior of a Saratoga Peer . . . . . . . . . . . . . . . . . 35 87 6.1. Saratoga Transactions . . . . . . . . . . . . . . . . . . 35 88 6.2. Beacons . . . . . . . . . . . . . . . . . . . . . . . . . 38 89 6.3. Upper-Layer Interface . . . . . . . . . . . . . . . . . . 39 90 6.4. Inactivity Timer . . . . . . . . . . . . . . . . . . . . . 39 91 7. Mailing list . . . . . . . . . . . . . . . . . . . . . . . . . 40 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 95 11. A Note on Naming . . . . . . . . . . . . . . . . . . . . . . . 41 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 42 99 Appendix A. Appendix: Timestamp/Nonce field considerations . . . 43 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 102 1. Background and Introduction 104 Saratoga is a file transfer and content dissemination protocol 105 capable of efficiently sending both small and very large files as 106 well as streaming continuous content. Saratoga was originally 107 designed for the purpose of large file transfer from small low-Earth- 108 orbit satellites. It has been used in daily operations since 2004 to 109 move mission imaging data files on the order of several hundred 110 megabytes each from the Disaster Monitoring Constellation (DMC) 111 remote-sensing satellites to ground stations. 113 The DMC satellites, built at the University of Surrey by Surrey 114 Satellite Technology Ltd (SSTL), all use IP for payload 115 communications and delivery of Earth imagery. At the time of this 116 writing in October 2009, seven DMC satellites have been launched into 117 orbit; six are currently operational; and further DMC satellites are 118 under construction. The DMC satellites use Saratoga to provide 119 imagery under the aegis of the International Charter on Space and 120 Major Disasters. A pass of connectivity between a satellite and 121 ground station offers an 8-12 minute time window in which to transfer 122 imagery files using a minimum of an 8.1 Mbps downlink and a 9.6 kbps 123 uplink. The newer DMC satellites have faster downlinks, with some 124 capable of 80 Mbps. Others are planned to provide upwards of 200 125 Mbps, without significant increases in uplink rates. This high 126 degree of asymmetry, and need to fully utilize the downlink to move 127 the volume of data required within the limited time available, 128 motivates much of Saratoga's design. 130 Further details on how these DMC satellites use IP to communicate 131 with the ground and the terrestrial Internet are discussed in other 132 documents [Hogie05][Wood07a][Wood07b]. 134 Store-and-forward delivery relies on reliable hop-by-hop transfers of 135 files, removing the need for the final receiver to talk to the 136 original sender across long delays and allowing for the possibility 137 that an end-to-end path may never exist between sender and receiver 138 at any given time. Use of store-and-forward hop-by-hop delivery is 139 typical of scenarios in space exploration for both near-Earth and 140 deep-space missions, and useful for other scenarios, such as 141 underwater networking, ad-hoc sensor networks, and some message- 142 ferrying relay scenarios. Saratoga is intended to be useful for 143 relaying data in these scenarios and can optionally also be used to 144 carry the Bundle Protocol "bundles" that is proposed for use in Delay 145 and Disruption-Tolerant Networking (DTN) by the IRTF DTN Research 146 Group [RFC5050]. How Saratoga can optionally function as a "bundle 147 convergence layer" alongside a DTN bundle agent is specified in a 148 companion document [I-D.wood-dtnrg-saratoga]. 150 High link utilization is important during periods of limited 151 connectivity. Given that Saratoga was originally developed for 152 scheduled peer-to-peer communications over dedicated links in private 153 networks where each application has the entire link for the duration 154 of its transfer, early Saratoga implementations deliberately lack any 155 form of congestion control and send at line rate. Newer 156 implementations may perform TCP-Friendly Rate Control (TFRC) 157 [RFC3448] or other congestion control mechanisms such as LEDBAT 158 [I-D.ietf-ledbat-congestion], if appropriate for the environment and 159 where simultaneous sharing of capacity with other traffic and 160 applications is required. 162 Saratoga contains a Selective Negative Acknowledgement (SNACK) 163 mechanism to provide reliable retransmission of data. This was 164 intended to correct losses of corrupted link-layer frames due to 165 channel noise over a space link. Packet losses in the DMC are due to 166 corruption introducing non-recoverable errors in the frame. The DMC 167 design uses point-to-point links and scheduling of applications so 168 that the link is dedicated to one application transfer at a time, 169 meaning that packet loss can not be due to congestion as applications 170 compete for link capacity. In other wireless environments that may 171 be shared by many nodes and applications, allocation of channel 172 resources to nodes becomes a MAC-layer function. Forward Error 173 Coding (FEC) to get the most reliable transmission through a channel 174 is best left near the physical layer so that it can be tailored for 175 the channel. Use of FEC complements Saratoga's transport-level 176 negative-acknowledgement approach to provide a reliable ARQ mechanism 177 [RFC3366]. 179 Saratoga is scalable in that it is capable of efficiently 180 transferring small or large files, by choosing a width of file offset 181 descriptor appropriate for the filesize, and advertising accepted 182 offset descriptor sizes. 16-bit, 32-bit, 64-bit and 128-bit 183 descriptors can be selected, for maximum file sizes of 64KiB-1, 184 4GiB-1, 2^64-1 and 2^128-1 octets. Earth imaging files currently 185 transferred by Saratoga are mostly up to a few gigabytes in size. 186 Some implementations do transfer more than 4 GiB in size, and so 187 require offset descriptors larger than 32 bits. We expect that a 188 128-bit descriptor will satisfy all future needs, but we expect 189 current implementations to only support up to 32-bit or 64-bit 190 descriptors, depending on their application needs. The 16-bit 191 descriptor is useful for small messages, including messages from 192 8-bit devices, and is always supported. The 128-bit descriptor is 193 useful for moving very large files stored on a 128-bit filesystem, 194 such as on OpenSolaris ZFS. 196 Saratoga can be used with either IPv4 or IPv6. Compatibility between 197 Saratoga and the wide variety of links that can already carry IP 198 traffic is assured. 200 Saratoga was originally implemented as outlined in [Jackson04], but 201 the specification given here differs substantially, as we have added 202 a number of features, while cleaning up the initial Saratoga 203 specification. The original Saratoga code uses a version number of 204 0, while code that implements this version of the protocol advertises 205 a version number of 1. Further discussion of the history and 206 development of Saratoga is given in [Wood07b]. 208 This document contains an overview of the transfer process and 209 transactions using Saratoga in Section 2, followed by a formal 210 definition of the packet types used by Saratoga in Section 4, and the 211 details of the various protocol mechanisms in Section 6. 213 Here, Saratoga transaction types are labelled with underscores around 214 lowercase names (such as a "_get_" transaction), while Saratoga 215 packet types are labelled in all capitals (such as a "REQUEST" 216 packet) in order to distinguish between the two. 218 The remainder of this specification uses 'file' as a shorthand for 219 'binary object', which may be a DTN bundle, or other type of data. 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in RFC 2119. [RFC2119] 225 2. Overview of Saratoga File Transfer 227 Saratoga is a peer-to-peer protocol in the sense that multiple files 228 may be transferred in both directions simultaneously between two 229 communicating Saratoga peers, and there is not intended to be a 230 strict client-to-server relationship. 232 Saratoga nodes are simple file servers. Saratoga supports several 233 types of operations on files including "pull" downloads, "push" 234 uploads, directory listing, and deletion requests. Each operation is 235 handled as a distinct "transaction" between the peers. 237 Saratoga nodes MAY advertise their presence, capabilities, and 238 desires by sending BEACON packets. These BEACONs are sent to either 239 a reserved, unforwardable, multicast address when using IPv4, or a 240 link-local all-Saratoga-peers multicast address when using IPv6. A 241 BEACON might also be unicast to another known node as a sort of 242 "keepalive". Saratoga nodes may dynamically discover other Saratoga 243 nodes either through listening for BEACONs, through pre- 244 configuration, or via some other trigger from a user, lower-layer 245 protocol, or another process. The BEACON is simply useful in low- 246 delay ad-hoc networking or as explicit confirmation that another node 247 is present; it is not required in order to begin a Saratoga 248 transaction. BEACONs have been used by the DMC satellites to 249 indicate to ground stations that a link has become functional, a 250 solid-state data recorder is online, and the software is ready to 251 transfer any requested files. 253 A Saratoga transaction begins with either a _get_, _put_, _getdir_, 254 or _delete_ transaction REQUEST packet corresponding to a desired 255 download, upload, directory listing, or deletion operation. The most 256 common envisioned transaction is the _get_, which begins with a 257 single Saratoga REQUEST packet sent from the peer wishing to receive 258 the file, to the peer who currently has the file. If the transaction 259 is rejected, then a brief METADATA packet that conveys rejection is 260 generated. If the file-serving peer accepts the transaction, it 261 generates and sends a more useful descriptive METADATA packet, 262 followed by some number of DATA packets constituting the requested 263 file. 265 These DATA packets are finished by (and can intermittently include) a 266 DATA packet with a flag bit set that demands the file-receiver send a 267 reception report in the form of a HOLESTOFILL packet. The 268 HOLESTOFILL packet is a Selective Negative Acknowledgement listing 269 spans of octets within the file that have not yet been received as 270 well as whether or not the METADATA packet was received. From this 271 HOLESTOFILL packet, the file-sender begins a cycle of selective 272 retransmissions of DATA packets, until it sees a HOLESTOFILL packet 273 that acknowledges total reception of all file data. 275 In the example scenario in Figure 1, a _get_ request is granted. The 276 reliable file delivery experiences loss of a single DATA packet due 277 to channel-induced errors. 279 File-Receiver File-Sender 281 REQUEST ---------------------> 282 (transfer accepted) <--------- METADATA 283 HOLESTOFILL -----------------> (voluntarily sent at start) 284 <------------------------- DATA #1 285 (lost) <------ DATA #2 286 <------------------------- DATA #3 (bit set 287 requesting HOLESTOFILL) 288 HOLESTOFILL -----------------> 289 (indicating that range in DATA #2 was lost) 290 <------------------------- DATA #2 (bit set 291 requesting HOLESTOFILL) 292 HOLESTOFILL -----------------> 293 (complete file and METADATA received) 295 Figure 1: Example _get_ transaction sequence 297 A _getdir_ request proceeds similarly, though the DATA packets 298 contain the contents of a directory listing, described later, rather 299 than a given file's bytes. _getdir_ is the only request to apply to 300 directories. 302 The HOLESTOFILL and DATA packets are allowed to be sent at any time 303 within the scope of a transaction in order for the file-sending node 304 to optimize buffer management and transmission order. For example, 305 if the file-receiver already has the first half of a file from a 306 previous disrupted transfer, it may send a HOLESTOFILL at the 307 beginning of the transaction indicating that it has the first half of 308 the file, and so only needs the last half of the file. Thus, 309 efficient recovery from interrupted sessions between peers becomes 310 possible, similar to ranged FTP and HTTP requests. 312 In deep-space scenarios, the large propagation delays and round-trip 313 times involved prohibit ping-pong packet exchanges for starting 314 transactions. The Saratoga _put_ transaction is useful in such 315 cases. A _put_ is initiated by the file-sender sending a METADATA 316 packet followed by immediate DATA packets. This is highly desirable 317 in long-propagation deep-space (and similar) scenarios, without first 318 waiting for a HOLESTOFILL. This can be considered an "optimistic" 319 mode of protocol operation, as it assumes the transaction request 320 will be granted. If the sender of a PUT request sees a METADATA 321 packet indicating that the request was declined, it MUST stop sending 322 any DATA packets within that transaction immediately. Since this 323 type of _put_ is open-loop for some period of time, it should not be 324 used in scenarios where congestion is a valid concern; in these 325 cases, the file-sender should wait on its METADATA to be acknowledged 326 by a HOLESTOFILL before sending DATA packets within the transaction. 328 Figure 2 illustrates the sequence of packets in an example _put_ 329 transaction where the second DATA packet is lost. Other than the way 330 that it is initiated, a _put_ transaction is identical to a _get_ 331 transaction. 333 File-Sender File-Receiver 335 METADATA ----------------> 336 (transfer accepted) <---------- HOLESTOFILL 337 DATA #1 ----------------> 338 DATA #2 ---> (lost) 339 DATA #3 (bit set ------------> 340 requesting HOLESTOFILL) 341 (DATA #2 lost) <------------- HOLESTOFILL 342 DATA #2 (bit set -----------> 343 requesting HOLESTOFILL) 344 (transfer complete) <---------- HOLESTOFILL 346 Figure 2: Example PUT transaction sequence 348 The _delete_ transactions are simple single packet requests that 349 trigger a HOLESTOFILL packet with a status code that indicates 350 whether the file was deleted or not. If the file is not able to be 351 deleted for some reason, this reason can be conveyed in the Status 352 field of the HOLESTOFILL packet. 354 A _get_ REQUEST packet that does not specify a filename (i.e. the 355 request contains a zero-length File Path field) is specially defined 356 to be a request for any chosen file that the peer wishes to send it. 357 This allows a Saratoga peer to blindly request any files that the 358 other Saratoga peer has ready for it, without prior knowledge of the 359 directory listing, and without requiring the ability to examine files 360 or decode remote file names/paths for meaningful information such as 361 final destination. 363 If a file is larger than Saratoga can be expected to transfer during 364 a time-limited contact, there are at least two feasible options: 366 (1) The application can use proactive fragmentation to create 367 multiple smaller-sized files. Saratoga can transfer some number of 368 these smaller files fully during a contact. 370 (2) To avoid file fragmentation, a Saratoga file-receiver can retain 371 a partially-transferred file and request transfer of the unreceived 372 bytes during a later contact. This uses a HOLESTOFILL packet to make 373 clear how much of the file has been successfully received and where 374 transfer should be resumed from. On resumption, the new METADATA 375 (including file length, file timestamps, and possibly MD5 sum) MUST 376 match that of the previous METADATA in order to re-establish the 377 transfer. Otherwise, the file-receiver MUST assume that the file has 378 changed and purge the DATA received during the first contact. 380 If a file contains separate parts that require reliable transmission 381 without errors or that can tolerate errors in delivered content, 382 proactive fragmentation can be used to split the file into separate 383 reliable and unreliable files that can be transferred separately, 384 using UDP or UDP-Lite. 386 If parts of a file require reliability but the rest can be sent by 387 unreliable transfer, the file-sender can use its knowledge of the 388 internal file structure and vary DATA packet size so that the 389 reliable parts always start after the offset field and are covered by 390 the UDP-Lite checksum. 392 A file that permits unreliable delivery may be transferred onwards 393 using UDP, although the METADATA flag indicating that unreliable 394 transmission is permitted is retained for later hops, which may 395 revert to using UDP-Lite. If the current sender does not understand 396 the internal file format to be able to decide what parts must be 397 protected, the current sender or receiver does not support UDP-Lite, 398 or the current protocol stack only implements error-free frame 399 delivery below the UDP layer, then the file may be delivered using 400 UDP. 402 Like the BEACON packets, a _put_ or a response to a _get_ may be sent 403 to the dedicated IPv4 Saratoga multicast address (allocated to 404 224.0.0.108) or the dedicated IPv6 link-local multicast address 405 (allocated to FF02:0:0:0:0:0:0:6C) for multiple file-receivers on the 406 link to hear. This is at the discretion of the file-sender, if it 407 believes that there is interest from multiple receivers. In-progress 408 DATA transfers may also be moved seamlessly from unicast to multicast 409 if the file-sender learns during a transfer, from receipt of further 410 unicast _get_ REQUEST packets, that multiple nodes are interested in 411 the file. The associated METADATA packet is multicast when this 412 transition takes place, and is then repeated periodically while the 413 DATA stream is being sent, to inform newly-arrived listeners about 414 the file being multicast. Acknowledgements MUST NOT be demanded by 415 multicast DATA packets, to prevent ack implosion at the file-sender, 416 and instead holestofill information is aggregated and sent 417 voluntarily by all file-receivers. File-receivers respond to 418 multicast DATA with multicast HOLESTOFILL packets. File-receivers 419 should introduce a short random delay before sending a HOLESTOFILL 420 packet, to prevent ack implosion after a channel-induced loss, and 421 must listen for HOLESTOFILL packets from others, to avoid duplicating 422 fill requests. The file-sender SHOULD repeat any initial unicast 423 portion of the transfer as multicast last of all, and may repeat and 424 cycle through multicast of the file several times while file- 425 receivers express interest via HOLESTOFILL or _get_ packets. Once in 426 multicast and with METADATA being repeated periodically, new file- 427 receivers do not need to send individual REQUEST packets. If a 428 transfer has been started using UDP-Lite and new receivers indicate 429 UDP-only capability, multicast transfers MUST switch to using UDP to 430 accommodate them. 432 3. Optional Parts of Saratoga 434 Implementing support for some parts of Saratoga is optional. These 435 parts are: 437 - sending and parsing BEACONs 439 - support for working with DTN bundles and a bundle agent as an 440 application driving Saratoga. Use of a filesystem is expected. 442 - transfers permitting some errors in content delivered, using UDP- 443 Lite. These can be useful for decreasing delivery time over 444 unreliable channels, especially for unidirectional links - but 445 requires that lower-layer frames permit delivery of unreliable data. 447 - streaming data, including real-time streaming of content of unknown 448 length. This streaming can be unreliable (without resend requests) 449 or reliable (with resend requests). Session protocols such as http 450 expect reliable streaming, and can be used in delay-tolerant networks 451 [I-D.wood-dtnrg-http-dtn-delivery]. Although Saratoga data delivery 452 is inherently one-way, where a stream of DATA packets elicits a 453 stream of HOLESTOFILL packets, bidirectional duplex communication can 454 be established by using two Saratoga transfers flowing in opposite 455 directions. 457 - sending and responding to packet timestamps in DATA and HOLESTOFILL 458 packets. These timestamps are useful for streaming and for giving a 459 file-sender an indication of path latency for rate control. There is 460 no need for a file-receiver to understand the format used for these 461 timestamps for it to be able to receive and reflect them. 463 - performing congestion control at the sender, based on feedback from 464 acknowledgement HOLESTOFILL packets, or simple open-loop rate control 466 - multicast DATA transfers, if judged useful for the environment in 467 which Saratoga is deployed. 469 4. Packet Types 471 Saratoga is defined for use with UDP over either IPv4 or IPv6 472 [RFC0768]. UDP checksums, which are mandatory with IPv6, MUST be 473 used with IPv4. Within either version of IP datagram, a Saratoga 474 packet appears as a typical UDP header followed by an octet 475 indicating how the remainder of the packet is to be interpreted: 477 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | UDP source port | UDP destination port | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | UDP length | UDP checksum | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |Ver|Packet Type| other Saratoga fields ... // 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+// 487 Saratoga data transfers can also be carried out using UDP-Lite 488 [RFC3828]. If Saratoga can be carried over UDP-Lite, the 489 implementation MUST also support UDP. All packet types except DATA 490 MUST be sent using UDP with checksums turned on. For reliable 491 transfers, DATA packets are sent using UDP with checksums turned on. 492 For files where unreliable transfer has been indicated as desired and 493 possible, the sender MAY send DATA packets unreliably over UDP-Lite, 494 where UDP-Lite protects only the Saratoga headers and parts of the 495 file that must be transmitted reliably. 497 The two-bit Saratoga version field ("Ver") identifies the version of 498 the Saratoga protocol that the packet conforms to. The value 01 499 should be used in this field for implementations conforming to the 500 specification in this document, which specifies version 1 of 501 Saratoga. The value 00 was used in earlier implementations, prior to 502 the formal specification and public submission of the protocol 503 design, and is incompatible with version 01 in several respects. 505 The six-bit Saratoga "Packet Type" field indicates how the remainder 506 of the packet is intended to be decoded and processed: 508 +---+-------------+-------------------------------------------+ 509 | # | Type | Use | 510 +---+-------------+-------------------------------------------+ 511 | 0 | BEACON | Beacon packet indicating peer status | 512 | 1 | REQUEST | Commands peer to start a transfer | 513 | 2 | METADATA | Carries file transfer metadata | 514 | 3 | DATA | Carries octets of file data | 515 | 4 | HOLESTOFILL | Signals list of unreceived data to sender | 516 +---+-------------+-------------------------------------------+ 518 Several of these packet types include a Flags field, for which only 519 some of the bits have defined meanings and usages in this document. 520 Other, undefined, bits may be reserved for future use. Following the 521 principle of being conservative in what you send and liberal in what 522 you accept, a packet sender MUST set any undefined bits to zero, and 523 a packet recipient MUST NOT rely on these undefined bits being zero 524 on reception. 526 The specific formats for the different types of packets are given in 527 this section. Some packet types contain file offset descriptor 528 fields, which contain unsigned integers. The lengths of the offset 529 descriptors are fixed within a transfer, but vary between file 530 transfers. The size is set for each particular transfer, depending 531 on the choice of offset descriptor width made in the METADATA packet, 532 which in turn depends on the size of file being transferred. 534 In this document, all of the packet structure figures illustrating a 535 packet format assume 32-bit lengths for these offset descriptor 536 fields, and indicate the transfer-dependent length of the fields by 537 using a "(descriptor)" designation within the [field] in all packet 538 diagrams. That is: 540 The example 32-bit descriptors shown in all diagrams here 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 [ (descriptor) ] 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 are suitable for files of up to 4GiB - 1 octets in length, and may be 547 replaced in a file transfer by descriptors using a different length, 548 depending on the size of file to be transferred: 550 128-bit descriptor for very long files (optional) 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 [ (descriptor) / 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 / (descriptor, continued) / 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 / (descriptor, continued) / 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 / (descriptor, continued) ] 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 64-bit descriptor for longer files (optional) 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 [ (descriptor) / 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 / (descriptor, continued) ] 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 16-bit descriptor for short files (MUST be supported) 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 [ (descriptor) ] 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 For offset descriptors and types of content being transferred, the 576 related flag bits in BEACON and REQUEST indicate capabilities, while 577 in METADATA and DATA those flag bits are used slightly differently, 578 to indicate the content being transferred. 580 Saratoga packets are intended to fit within link MTUs to avoid the 581 inefficiencies and overheads of lower-layer fragmentation. A 582 Saratoga implementation itself does not perform any form of MTU 583 discovery, but is assumed to be configured with knowledge of usable 584 maximum IP MTUs for the link interfaces it uses. 586 4.1. BEACON 588 BEACON packets may be multicast periodically by nodes willing to act 589 as Saratoga peers. Some implementations have done so every 100 590 milliseconds, but this rate is arbitrary, and should be chosen to be 591 appropriate for the environment and implementation. 593 The main purpose for sending BEACONs is to announce the presence of 594 the node to potential peers (e.g. satellites, ground stations) to 595 provide automatic service discovery, and also to confirm the activity 596 or presence of the peer. 598 The Endpoint Identifier (EID) in the BEACON serves to uniquely 599 identify the Saratoga peer. Whenever the Saratoga peer begins using 600 a new IP address, it SHOULD issue a BEACON on it and repeat the 601 BEACON periodically, to enable listeners to associate the IP address 602 with the EID and the peer. 604 Format 606 0 1 2 3 607 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 |0 1| Type | Flags | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Endpoint identifier... // 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+// 614 where 616 +------------+------------------------------------------------------+ 617 | Field | Description | 618 +------------+------------------------------------------------------+ 619 | Type | 0 | 620 | Flags | convey whether or not the peer is ready to | 621 | | send/receive and what the maximum supported file | 622 | | size range and descriptor is. | 623 | Endpoint | This can be used to uniquely identify the sending | 624 | identifier | Saratoga peer, or the administrative node that the | 625 | | BEACON-sender is associated with. If Saratoga is | 626 | | being used with a bundle agent, a bundle endpoint ID | 627 | | (EID) can be used here. | 628 +------------+------------------------------------------------------+ 630 The Flags field is used to provide some additional information about 631 the peer. The first octet of the Flags field is currently in use. 632 The later two octets are for future use, and MUST be set to zero. 634 The two highest-order bits (bits 8 and 9 above) indicate the maximum 635 supported file size parameters that the peer's Saratoga 636 implementation permits. Other Saratoga packet types contain 637 variable-length fields that convey file sizes or offsets into a file 638 -- the file offset descriptors. These descriptors may be 16-bit, 32- 639 bit, 64-bit, or 128-bit in length, depending on the size of the file 640 being transferred and/or the integer types supported by the sending 641 peer. The indicated bounds for the possible values of these bits are 642 summarized below: 644 +-------+-------+-------------------------+-------------------+ 645 | Bit 8 | Bit 9 | Supported Field Sizes | Maximum File Size | 646 +-------+-------+-------------------------+-------------------+ 647 | 0 | 0 | 16 bits | 2^16 - 1 octets. | 648 | 0 | 1 | 16 or 32 bits | 2^32 - 1 octets. | 649 | 1 | 0 | 16, 32, or 64 bits | 2^64 - 1 octets. | 650 | 1 | 1 | 16, 32, 64, or 128 bits | 2^128 - 1 octets. | 651 +-------+-------+-------------------------+-------------------+ 653 If a Saratoga peer advertises it is capable of receiving a certain 654 size of file, then it MUST also be capable of receiving files sent 655 using smaller descriptor values. This avoids overhead on small 656 files, while increasing interoperability between peers. 658 It is likely when sending unbounded streams that a larger offset 659 descriptor field size will be preferred to minimise problems with 660 offset sequences wrapping. Protecting against sequence wrapping is 661 discussed in the HOLESTOFILL section. 663 +-----+-------+-----------------------------------------------------+ 664 | Bit | Value | Meaning | 665 +-----+-------+-----------------------------------------------------+ 666 | 10 | 0 | not able to pass bundles to a local bundle agent; | 667 | | | handles files. | 668 | 10 | 1 | can pass marked bundles to a local bundle agent. | 669 +-----+-------+-----------------------------------------------------+ 671 Bit 10 is reserved for DTN bundle agent use, indicating whether the 672 sender is capable of handling bundles via a local bundle agent. This 673 is described in [I-D.wood-dtnrg-saratoga]. 675 Any type of host identifier can be used in the endpoint identifier 676 field, as long as it is a reasonably unique string within the range 677 of operational deployment. This field encompasses the remainder of 678 the packet, and might contain non-UTF-8 and/or null characters. 680 +-----+-------+--------------------------------------+ 681 | Bit | Value | Meaning | 682 +-----+-------+--------------------------------------+ 683 | 11 | 0 | not capable of supporting streaming. | 684 | 11 | 1 | capable of supporting streaming. | 685 +-----+-------+--------------------------------------+ 687 Bit 11 is used to indicate whether the sender is capable of sending 688 and receiving continuous streams. 690 +--------+--------+------------------------------------------------+ 691 | Bit 12 | Bit 13 | Capability and willingness to send files | 692 +--------+--------+------------------------------------------------+ 693 | 0 | 0 | cannot send files at all. | 694 | 0 | 1 | invalid. | 695 | 1 | 0 | capable of sending, but not willing right now. | 696 | 1 | 1 | capable of and willing to send files. | 697 +--------+--------+------------------------------------------------+ 698 +--------+--------+-------------------------------------------------+ 699 | Bit 14 | Bit 15 | Capability and willingness to receive files | 700 +--------+--------+-------------------------------------------------+ 701 | 0 | 0 | cannot receive files at all. | 702 | 0 | 1 | invalid. | 703 | 1 | 0 | capable of receiving, but will reject METADATA. | 704 | 1 | 1 | capable of and willing to receive files. | 705 +--------+--------+-------------------------------------------------+ 707 Also in the Flags field, bits 12 and 14 act as capability bits, while 708 bits 13 and 15 augment those flags with bits indicating current 709 willingness to use the capability. 711 Bits 12 and 13 deal with sending, while bits 14 and 15 deal with 712 receiving. If bit 12 is set, then the peer has the capability to 713 send files. If bit 14 is set, then the peer has the capability to 714 receive files. Bits 13 and 15 indicate willingness to send and 715 receive files, respectively. 717 A peer that is able to act as a file-sender MUST set the capability 718 bit 12 in all BEACONs that it sends, regardless of whether it is 719 willing to send any particular files to a particular peer at a 720 particular time. Bit 13 indicates the current presence of data to 721 send and a willingness to send it in general, in order to augment the 722 capability advertised by bit 12. 724 If bit 14 is set, then the peer is capable of acting as a receiver, 725 although it still might not currently be ready or willing to receive 726 files (for instance, it may be low on free storage). This bit MUST 727 be set in any BEACON packets sent by nodes capable of acting as file- 728 receivers. Bit 15 augments this by expresses a current general 729 willingness to receive and accept files. 731 +-----+-------+-----------------------------------------------------+ 732 | Bit | Value | Meaning | 733 +-----+-------+-----------------------------------------------------+ 734 | 16 | 0 | supports DATA transfers over UDP only. | 735 | 16 | 1 | supports DATA transfers over both UDP and UDP-Lite. | 736 +-----+-------+-----------------------------------------------------+ 738 Bit 16 is used to indicate whether the sender is capable of sending 739 and receiving unreliable transfers via UDP-Lite. 741 4.2. REQUEST 743 A REQUEST packet is a command to perform either a _get_, _getdir_, or 744 _delete_ transaction. 746 Format 748 0 1 2 3 749 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 |0 1| Type | Flags | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Id | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | variable-length File Path ... / 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 / / 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 / | null byte | / 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 / variable-length Authentication Field (optional) | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 where 766 +--------+----------------------------------------------------------+ 767 | Field | Description | 768 +--------+----------------------------------------------------------+ 769 | Type | 1 | 770 | Flags | provide additional information about the requested | 771 | | file/operation; see table below for definition. | 772 | Id | uniquely identifies the transaction between two peers. | 773 | File | the path of the requested file/directory following the | 774 | Path | rules described below. | 775 +--------+----------------------------------------------------------+ 777 The Id that is used during transactions serves to uniquely associate 778 a given packet with a particular transaction. This enables multiple 779 simultaneous data transfer transactions between two peers, with each 780 peer deciding how to multiplex and prioritise the parallel flows it 781 sends. The Id for a transaction is selected by the initiator so as 782 to not conflict with any other in-progress or recent transactions 783 with the same host. This Id should be unique and generated using 784 properties of the file, which will remain constant across a host 785 reboot. The 3-tuple of both host identifiers and a carefully- 786 generated transaction Id field can be used to uniquely index a 787 particular transaction's state. 789 In the Flags field, the bits labelled 8 and 9 in the figure above 790 indicate the maximum supported file length fields that the peer can 791 handle, and are interpreted exactly as the bits 8 and 9 in the BEACON 792 packet described above. The remaining defined bits are: 794 +-----+-------+-----------------------------------------------------+ 795 | Bit | Value | Meaning | 796 +-----+-------+-----------------------------------------------------+ 797 | 10 | 0 | The requester cannot handle bundles locally. | 798 | 10 | 1 | The requester can handle bundles. | 799 | 11 | 0 | The requester cannot receive streams. | 800 | 11 | 1 | The requester is also able to receive streams. | 801 | 14 | 0 | a _get_ or _getdir_ transaction is requested | 802 | 14 | 1 | a _delete_ transaction is requested | 803 | 15 | 0 | the File Path field holds a file for a _get_ or | 804 | | | _delete_ | 805 | 15 | 1 | the File Path field specifies a directory name for | 806 | | | a _getdir_ or _delete_ | 807 | 16 | 0 | The requester is able to receive DATA over UDP | 808 | | | only. | 809 | 16 | 1 | The requester is also able to receive DATA over | 810 | | | UDP-Lite. | 811 +-----+-------+-----------------------------------------------------+ 813 The File Path portion of a _get_ packet is a null-terminated UTF-8 814 encoded string [RFC3629] that represents the path and base file name 815 on the file-sender of the file (or directory) that the file-receiver 816 wishes to perform the _get_, _getdir_, or _delete_ operation on. 817 Implementations SHOULD only send as many octets of File Path as are 818 needed for carrying this string, although some implementations MAY 819 choose to send a fixed-size File Path field in all REQUEST packets 820 that is filled with null octets after the last UTF-8 encoded octet of 821 the path. A maximum of 1024 octets for this field, and for the File 822 Path fields in other Saratoga packet types, is used to limit the 823 total packet size to within a single IPv6 minimum MTU (minus some 824 padding for network layer headers), and thus avoid the need for 825 fragmentation. The 1024-octet maximum applies after UTF-8 encoding 826 and null termination. 828 As in the standard Internet File Transfer Protocol (FTP) [RFC0959], 829 for path separators, Saratoga allows the local naming convention on 830 the peers to be used. There are security implications to processing 831 these strings without some intelligent filtering and checking on the 832 filesystem items they refer to, as discussed in the Security 833 Considerations section later within this document. 835 If the File Path field is empty, i.e. is a null-terminated zero- 836 length string one octet long, then this indicates that the file- 837 receiver is ready to receive any file that the file-sender would like 838 to send it, rather than requesting a particular file. This allows 839 the file-sender to determine the order and selection of files that it 840 would like to forward to the receiver in more of a "push" manner. Of 841 course, file retrieval could also follow a "pull" manner, with the 842 file-receiving host requesting specific files from the file-sender. 843 This may be desirable at times if the file-receiver is low on storage 844 space, or other resources. The file-receiver could also use the 845 Saratoga _getdir_ transaction results in order to select small files, 846 or make other optimizations, such as using its local knowledge of 847 contact times to pick files of a size likely to be able to be 848 delivered completely. File transfer through pushing sender-selected 849 files implements delivery prioritization decisions made solely at the 850 Saratoga file-sending node. File transfer through pulling specific 851 receiver-selected files implements prioritization involving more 852 participation from the Saratoga file-receiver. This is how Saratoga 853 implements Quality of Service (QoS). 855 The null-terminated File Path string MAY be followed by an optional 856 Authentication Field that can be used to validate the REQUEST packet. 857 Any value in the Authentication Field is the result of a computation 858 of packet contents that SHOULD include, at a minimum, source and 859 destination IP addresses and port numbers and packet length in a 860 'pseudo-header', as well as the content of all Saratoga fields from 861 Version to File Path, excluding the predictable null-termination 862 octet. This Authentication Field can be used to allow the REQUEST 863 receiver to discriminate between other peers, and permit and deny 864 various REQUEST actions as appropriate. The format of this field is 865 unspecified for local use. 867 REQUEST packets may be sent multicast, to learn about all listening 868 nodes. A multicast _get_ request for a file that elicits multiple 869 METADATA responses should be followed by unicast HOLESTOFILL packets 870 with status errors cancelling all but one of the proposed transfers. 871 File timestamps in the Directory Entry can be used to select the most 872 recent version of an offered file, and the host to fetch it from. 874 If the receiver already has the file at the expected file path and is 875 requesting an update to that file, REQUEST can be sent after a 876 METADATA advertising that file, to allow the sender to determine 877 whether a replacement for the file should be sent. 879 Delete requests are ignored for files currently being transferred. 881 4.3. METADATA 883 METADATA packets are sent as part of a data transfer transaction 884 (_get_, _getfile_, and _put_). A METADATA packet says how large the 885 file is and what its name is, as well as what size of file offset 886 descriptor is chosen for the session. METADATA packets are normally 887 sent at the start of a data transfer, but may be repeated if 888 requested. 890 Format 892 0 1 2 3 893 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |0 1| Type | Flags |Sumtype| 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Id | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | / 900 / / 901 / example error-detection checksum (128-bit MD5 shown) / 902 / / 903 / | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | / 906 / single Directory Entry describing file / 907 / (variable length) / 908 / // 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-// 911 where 913 +-----------+-------------------------------------------------------+ 914 | Field | Description | 915 +-----------+-------------------------------------------------------+ 916 | Type | 2 | 917 | Flags | indicate additional boolean metadata about a file | 918 | Sumtype | indicates whether a checksum is present after the Id, | 919 | | and what type it is. | 920 | Id | identifies the transaction that this packet describes | 921 | Checksum | an example included checksum covering file contents | 922 | Directory | describes file system information about the file, | 923 | Entry | including file length, file timestamps, etc.; the | 924 | | format is specified in Section 5 | 925 +-----------+-------------------------------------------------------+ 927 The first octet of the Flags field is currently specified for use. 928 The later two octets are reserved for future use, and MUST be set to 929 zero. 931 In the Flags field, the bits labelled 8 and 9 in the figure above 932 indicate the exact size of the offset descriptor fields used in this 933 particular packet and are interpreted exactly as the bits 8 and 9 in 934 the BEACON packet described above. The value of these bits 935 determines the size of the File Length field in the current packet, 936 as well as indicating the size of the offset fields used in DATA and 937 HOLESTOFILL packets within the session that will follow this packet. 939 +--------+--------+-------------------------------------------------+ 940 | Bit 10 | Bit 11 | Type of transfer | 941 +--------+--------+-------------------------------------------------+ 942 | 0 | 0 | a file is being sent. | 943 | 0 | 1 | the file being sent should be interpreted as a | 944 | | | directory record. | 945 | 1 | 0 | a bundle is being sent. | 946 | 1 | 1 | an indefinite-length stream is being sent. | 947 +--------+--------+-------------------------------------------------+ 949 Also inside the Flags field, bits 10 and 11 indicate what is being 950 transferred - a file, special file that contains directory records, 951 bundle, or stream. The value 01 indicates that the METADATA and DATA 952 packets are being generated in response to a _getdir_ REQUEST, and 953 that the assembled DATA contents should be interpreted as a sequence 954 of Directory Records, as defined in Section 5. 956 +-----+-------+-----------------------------------------------------+ 957 | Bit | Value | Meaning | 958 +-----+-------+-----------------------------------------------------+ 959 | 12 | 0 | This transfer is in progress. | 960 | 12 | 1 | This transfer is no longer in progress, and has | 961 | | | been terminated. | 962 +-----+-------+-----------------------------------------------------+ 964 Bit 12 indicates whether the transfer is in progress, or has been 965 terminated by the sender. It is normally set to 1 only when METADATA 966 is resent to indicate that a stream transfer has been ended. 968 +--------+----------------------------------------------------------+ 969 | Bit 13 | Use | 970 +--------+----------------------------------------------------------+ 971 | 0 | This file's content MUST be delivered reliably without | 972 | | errors using UDP. | 973 | 1 | This file's content MAY be delivered unreliably, without | 974 | | errors, or partly unreliably, where errors are | 975 | | tolerated, using UDP-Lite. | 976 +--------+----------------------------------------------------------+ 978 Bit 13 indicates whether the file must be sent reliably or can be 979 sent at least partly unreliably, using UDP-Lite. This flag can only 980 be set if the originator of the file knows that at least some of the 981 file content is suitable for sending unreliably and is robust to 982 errors. This flag reflects a property of the file itself. This flag 983 may still be set if the immediate file-receiver is only capable of 984 UDP delivery, on the assumption that this preference will be 985 preserved for later transfers where UDP-Lite transfers may be taken 986 advantage of by senders with knowledge of the internal file 987 structure. The file-sender may know that the receiver is capable of 988 handling UDP-Lite, either from a _get_ REQUEST, from exchange of 989 BEACONs, or a-priori. 991 The high four bits of the Flags field, bits 28-31, are used to 992 indicate if an error-detection checksum has been included in the 993 METADATA for the file to be transferred. Here, bits 0000 indicate 994 that no checksum is present, with the implicit assumption that the 995 application will do its own end-to-end check. Other values indicate 996 the type of checksum to use. The choice of checksum depends on the 997 available computing power and the length of the file to be 998 checksummed. Longer files require stronger checksums to ensure 999 error-free delivery. The checksum of the file to be transferred is 1000 carried as shown, with a fixed-length field before the varying-length 1001 File Length and File Name information fields. 1003 Assigned values for the checksum field are: 1005 +-----------+-------------------------------------------------------+ 1006 | Value | Use | 1007 | (0-15) | | 1008 +-----------+-------------------------------------------------------+ 1009 | 0 | No checksum is provided. | 1010 | 1 | 32-bit CRC32 checksum, suitable for small files. | 1011 | 2 | 128-bit MD5 checksum, suitable for larger files | 1012 | 3 | 160-bit SHA-1 checksum, suitable for larger files but | 1013 | | slower to process than MD5. | 1014 +-----------+-------------------------------------------------------+ 1016 It is expected that higher values will be allocated to new and 1017 stronger checksums able to better protect larger files. A checksum 1018 SHOULD be included for files being transferred. The checksum SHOULD 1019 be as strong as possible. Streaming of an indefinite-length stream 1020 MUST set the checksum field to zero. 1022 It is expected that a minimum of the MD5 checksum will be used, 1023 unless the Saratoga implementation is used exclusively for small 1024 transfers at the low end of the 16-bit file descriptor range, such as 1025 on low-performing hardware, where the weaker CRC-32c checksum can 1026 suffice. 1028 The CRC32 checksum is computed as described for the CRC-32c algorithm 1029 given in [RFC3309]. 1031 The MD5 Sum field is generated via the MD5 algorithm [RFC1321], 1032 computed over the entire contents of the file being transferred. The 1033 file-receiver can compute the MD5 result over the reassembled 1034 Saratoga DATA packet contents, and compare this to the METADATA's MD5 1035 Sum field in order to gain confidence that there were no undetected 1036 protocol errors or UDP checksum weaknesses encountered during the 1037 transfer. Although MD5 is known to be less than optimal for security 1038 uses, it remains excellent for non-security use in error detection 1039 (as is done here in Saratoga), and has better performance 1040 implications than cryptographically-stronger alternatives given the 1041 limited available processing of many DTN use cases. 1043 Checksums may be privately keyed for local use, to allow transmission 1044 of authenticated or encrypted files delivered in DATA packets. This 1045 has limitations, discussed further in the Security Considerations 1046 section at end. 1048 Use of the checksum to ensure that a file has been correctly relayed 1049 to the receiving node is important. A provided checksum MUST be 1050 checked against the received data file. If checksum verification 1051 fails, either due to corruption or due to the receiving node not 1052 having the right key for a keyed checksum), the file MUST be 1053 discarded. If the file is to be relayed onwards later to another 1054 Saratoga peer, the metadata, including the checksum, MUST be retained 1055 with the file and SHOULD be retransmitted onwards unchanged with the 1056 file for end-to-end coverage. If it is necessary to recompute the 1057 checksum or encrypted data for the new peer, either because a 1058 different key is in use or the existing checksum algorithm is not 1059 supported, the new checksum MUST be computed before the old checksum 1060 is verified, to ensure overlapping checksum coverage and detect 1061 errors introduced in file storage. 1063 If the METADATA is in response to a _get_ REQUEST including a file 1064 record, and the record information for the held file matches what the 1065 requester already has, as has been indicated by a previously-received 1066 METADATA advertisement from the requester, then only the METADATA is 1067 sent repeating this information and verifying that the file is up to 1068 date. If the record information does not match and a newer file can 1069 be supplied, the METADATA begins a transfer with following DATA 1070 packets to update the file. 1072 4.4. DATA 1074 A series of DATA packets form the main part of a data transfer 1075 transaction (_get_, _put_, or _getdir_). The payloads constitute the 1076 actual file data being transferred. 1078 Format 1080 0 1 2 3 1081 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 |0 1| Type | Flags | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Id | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | / 1088 / Timestamp/nonce information (optional) / 1089 / / 1090 / | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 [ Offset (descriptor) ] 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 where 1097 +---------------+---------------------------------------------------+ 1098 | Field | Description | 1099 +---------------+---------------------------------------------------+ 1100 | Type | 3 | 1101 | Flags 8 and 9 | bit 8 and 9 specify the size of offset | 1102 | | descriptor, as elsewhere. | 1103 | Flag 10 | bit 10, with bit 11, indicates whether a file, | 1104 | | bundle, stream or directory entry is being | 1105 | | carried. This bit will normally be zero for | 1106 | | files. | 1107 | Flag 11 | bit 11 is used with bit 10. Normally this bit | 1108 | | will be zero for files. | 1109 | Flag 12 | bit 12 indicates that an optional timestamp or | 1110 | | nonce is included in the DATA header before the | 1111 | | offset descriptor. | 1112 | Flag 15 | bit 15 requests an immediate HOLESTOFILL ack to | 1113 | | be generated in response to receiving this | 1114 | | packet. | 1115 | Id | identifies the transaction that this packet | 1116 | | belongs to | 1117 | Offset | the offset in octets to the location where the | 1118 | | first byte of this packet's payload is to be | 1119 | | written | 1120 +---------------+---------------------------------------------------+ 1122 The DATA packet has a minimum size of ten octets, using sixteen-bit 1123 descriptors and no timestamps. 1125 DATA packets are normally sent error-free using UDP for reliable 1126 transfer (of both content and delivery). However, for transfers that 1127 can tolerate content errors, DATA packets MAY be sent using UDP-Lite. 1128 If UDP-Lite is used, the file-sender must know that the file-receiver 1129 is capable of handling UDP-Lite, and the file contents to be 1130 transferred should be resilient to errors. The UDP-Lite checksum 1131 MUST protect the Saratoga headers, up to and including the offset 1132 descriptor, and MAY protect more of each packet's payload, depending 1133 on the file-sender's knowledge of the internal structure of the file 1134 and the file's reliability requirements. 1136 Flag bits 8 and 9 are set to indicate the size of the offset 1137 descriptor as described for BEACON and METADATA packets, so that each 1138 DATA packet is self-describing. This allows the DATA packet to be 1139 used to construct a file even when the initial METADATA is lost and 1140 must be resent. The flag values for bits 8, 9, 10 and 11 MUST be the 1141 same as indicated in the initial METADATA packet. 1143 +--------+--------+-------------------------------------------------+ 1144 | Bit 10 | Bit 11 | Type of transfer | 1145 +--------+--------+-------------------------------------------------+ 1146 | 0 | 0 | a file is being sent. | 1147 | 0 | 1 | the file being sent should be interpreted as a | 1148 | | | directory record. | 1149 | 1 | 0 | a bundle is being sent. | 1150 | 1 | 1 | an indefinite-length stream is being sent. | 1151 +--------+--------+-------------------------------------------------+ 1153 Also inside the Flags field, bits 10 and 11 indicate what is being 1154 transferred - a file, special file that contains directory records, 1155 bundle, or stream. The value 01 indicates that the METADATA and DATA 1156 packets are being generated in response to a _getdir_ REQUEST, and 1157 that the assembled DATA contents should be interpreted as a sequence 1158 of Directory Records, as defined in Section 5. 1160 +-----+-------+-----------------------------------------------------+ 1161 | Bit | Value | Meaning | 1162 +-----+-------+-----------------------------------------------------+ 1163 | 12 | 0 | This packet does not include an optional | 1164 | | | timestamp/nonce field. | 1165 | 12 | 1 | This packet includes an optional timestamp/nonce | 1166 | | | field. | 1167 +-----+-------+-----------------------------------------------------+ 1169 Flag bit 12 indicates that an optional timestamp/nonce is carried in 1170 the packet before the offset field. This timestamp/nonce field is 1171 always sixteen bytes long. Timestamps are particularly useful when 1172 streaming. Timestamps are normally only meaningful to the sender, 1173 and the receiver simply echoes the timestamps back as specified for 1174 HOLESTOFILL packets. Timestamps are particularly useful when 1175 streaming. Timestamps are discussed further in Appendix A. 1177 +-----+-------+------------------------------------+ 1178 | Bit | Value | Meaning | 1179 +-----+-------+------------------------------------+ 1180 | 15 | 0 | No response is requested. | 1181 | 15 | 1 | A HOLESTOFILL packet is requested. | 1182 +-----+-------+------------------------------------+ 1184 Within the Flags field, if bit 15 of the packet is set, the file- 1185 receiver is to immediately generate a HOLESTOFILL packet to provide 1186 the file-sender with up-to-date information regarding the status of 1187 the file transfer. This flag is set carefully and rarely. It may be 1188 set periodically, but infrequently. Asymmetric links with 1189 constrained backchannels can only carry a limited amount of 1190 HOLESTOFILL packets before ack congestion becomes a problem. This 1191 flag SHOULD NOT be set if an unreliable stream is being transferred, 1192 or if multicast is in use. This flag SHOULD be set periodically for 1193 reliable file transfers, or reliable streaming. 1195 Immediately following the DATA header is the payload, which consumes 1196 the remainder of the packet and whose length is implicitly defined by 1197 the end of the packet. The payload octets are directly formed from 1198 the continuous octets starting at the specified Offset in the file 1199 being transferred. No special coding is performed. A zero-octet 1200 payload length is allowable. 1202 The length of the Offset fields used within all DATA packets for a 1203 given transaction MUST be consistent with the length indicated by 1204 bits 8 and 9 of the transactions METADATA packet. If the METADATA 1205 packet has not yet been received, a file-receiver SHOULD request it 1206 via a HOLESTOFILL packet, and MAY choose to enqueue received DATA 1207 packets for later processing after the METADATA arrives. 1209 4.5. HOLESTOFILL 1211 The HOLESTOFILL packet type is used for feedback from a Saratoga 1212 file-receiver to a Saratoga file-sender to indicate transaction 1213 progress and request transmission (usually re-transmission) of 1214 specific sets of octets within the current transaction (called 1215 "holes"). This can be used to clean up losses (or indicate no 1216 losses) at the end of, or during, a transaction, or to efficiently 1217 resume a transfer that was interrupted in a previous transaction. 1219 Format 1221 0 1 2 3 1222 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 |1 0| Type | Flags | Status | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Id | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | / 1229 / Timestamp/nonce information (optional) / 1230 / / 1231 / | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 [ Progress Indicator (descriptor) ] 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 [ In-Response-To (descriptor) ] 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | (possibly, several Hole fields) / 1238 / ... / 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 where 1243 +----------------+--------------------------------------------------+ 1244 | Field | Description | 1245 +----------------+--------------------------------------------------+ 1246 | Type | 4 | 1247 | Flags | are defined below. | 1248 | Id | identifies the transaction that this packet | 1249 | | belongs to. | 1250 | Status | a value of 0x00 indicates the transfer is | 1251 | | sucessfully proceeding. All other values are | 1252 | | errors terminating the transfer, explained | 1253 | | below. | 1254 | Zero-Pad | an octet fixed at 0x00 to allow later fields to | 1255 | | be conveniently aligned for processing. | 1256 | Progress | the offset of the lowest-numbered octet of the | 1257 | Indicator | file not yet received. | 1258 | In-Response-To | This is only present if the timestamp flag is | 1259 | (optional | set. If the HOLESTOFILL packet is voluntary and | 1260 | timestamp) | the voluntary flag is set, this should repeat | 1261 | | the timestamp of the DATA packet containing the | 1262 | | highest offset seen. If the HOLESTOFILL packet | 1263 | | is in response to a mandatory request, this will | 1264 | | repeat the timestamp of the requesting DATA | 1265 | | packet. The file-sender may use these | 1266 | | timestamps to estimate latency. There are | 1267 | | special considerations for streaming, to protect | 1268 | | against the ambiguity of wrapped offset | 1269 | | descriptor sequence numbers, discussed below. | 1270 | In-Response-To | the offset of the highest-numbered octet within | 1271 | (descriptor) | a DATA packet that generated this HOLESTOFILL | 1272 | | packet, or the offset of the highest-numbered | 1273 | | octet seen if this HOLESTOFILL is generated | 1274 | | voluntarily and the voluntary flag is set. | 1275 | Holes | indications of offset ranges of missing data, | 1276 | | defined below. | 1277 +----------------+--------------------------------------------------+ 1279 The HOLESTOFILL packet has a minimum size of twelve octets, using 1280 sixteen-bit descriptors, a progress indicator but no Hole fields, and 1281 no timestamps. 1283 The Id field is needed to associate the packet with the transaction 1284 that it refers to. Using the Id as a key, the receiver of a packet 1285 can determine the lengths of the Progress Indicator, In-Response-To, 1286 and Hole offsets used within the HOLESTOFILL packet, as this file 1287 offset descriptor size was set in the initial METADATA packet that 1288 established the Id and in DATA packets that the file receiver is 1289 responding to. 1291 Flags bits 8 and 9 are set to indicate the size of the offset 1292 descriptor as described for BEACON and METADATA packets, so that each 1293 HOLESTOFILL packet is self-describing. The flag values here MUST be 1294 the same as indicated in the initial METADATA and DATA packets. 1296 Other bits in the Flags field are defined as: 1298 +-----+-------+---------------------------------------------------+ 1299 | Bit | Value | Meaning | 1300 +-----+-------+---------------------------------------------------+ 1301 | 12 | 0 | This packet does not include a timestamp field. | 1302 | 12 | 1 | This packet includes an optional timestamp field. | 1303 +-----+-------+---------------------------------------------------+ 1305 Flag bit 12 indicates that an optional sixteen-byte timestamp/nonce 1306 field is carried in the packet before the Progress Indicator 1307 descriptor, as discussed for the DATA packet format. Timestamps are 1308 discussed further in Appendix A. 1310 +-----+-------+----------------------------------------+ 1311 | Bit | Value | Meaning | 1312 +-----+-------+----------------------------------------+ 1313 | 13 | 0 | file's METADATA has been received. | 1314 | 13 | 1 | file's METADATA has not been received. | 1315 +-----+-------+----------------------------------------+ 1317 If bit 13 of a HOLESTOFILL packet has been set to indicate that the 1318 METADATA has not yet been received, then the METADATA should be 1319 resent. This flag should normally be clear. 1321 +-----+-------+-----------------------------------------------------+ 1322 | Bit | Value | Meaning | 1323 +-----+-------+-----------------------------------------------------+ 1324 | 14 | 0 | this packet contains the complete current set of | 1325 | | | holes at the file-receiver. | 1326 | 14 | 1 | this packet contains incomplete hole-state; holes | 1327 | | | shown in this packet should supplement other | 1328 | | | incomplete hole-state known to the file-sender. | 1329 +-----+-------+-----------------------------------------------------+ 1331 Bit 14 of the HOLESTOFILL packet is only set when there are too many 1332 holes to fit within a single HOLESTOFILL packet due to MTU 1333 limitations. This causes the hole list to be spread out over 1334 multiple HOLESTOFILL packets, each of which conveys distinct sets of 1335 holes. This could occur, for instance, in a large file _put_ 1336 scenario with a long-delay feedback loop and poor physical layer 1337 conditions. These multiple HOLESTOFILL packets will share In- 1338 Response-To information. When losses are light and/or hole reporting 1339 and repair is relatively frequent, all holes should easily fit within 1340 a single HOLESTOFILL packet, and this flag will be clear. Bit 14 1341 should normally be clear. 1343 In some rare cases of high loss, there may be too many holes in the 1344 received data to convey within a single HOLESTOFILL's size, which is 1345 limited by the link MTU size. In this case, multiple HOLESTOFILL 1346 packets may be generated, and Flags bit 14 should be set on each 1347 HOLESTOFILL packet accordingly, to indicate that each packet holds 1348 incomplete results. The complete group of HOLESTOFILL packets, each 1349 containing incomplete information, will share common In-Response-To 1350 information to distinguish them from any earlier groups. 1352 +-----+-------+----------------------------------------------------+ 1353 | Bit | Value | Meaning | 1354 +-----+-------+----------------------------------------------------+ 1355 | 15 | 0 | This HOLESTOFILL was requested by the file-sender. | 1356 | 15 | 1 | This HOLESTOFILL is sent voluntarily. | 1357 +-----+-------+----------------------------------------------------+ 1359 Flag bit 15 indicates whether the HOLESTOFILL is sent voluntarily or 1360 due to a request by the sender. It affects content of the In- 1361 Response-To timestamp and descriptor fields. 1363 In the case of a transfer proceeding normally, immediately following 1364 the HOLESTOFILL packet header shown above, is a set of "Hole" 1365 definitions. Each Hole definition is a pair of unsigned integers. 1366 For a 32-bit offset descriptor, each Hole definition consists of two 1367 four-octet unsigned integers: 1369 Hole Definition Format 1371 0 1 2 3 1372 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 [ offset to start of hole (descriptor) ] 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 [ offset to end of hole (descriptor) ] 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 The start of the hole means the offset of the first unreceived byte 1380 in that hole. The end of the hole means the last unreceived byte in 1381 that hole. 1383 For 16-bit descriptors, each Hole definition holds two two-octet 1384 unsigned integers, while Hole definitions for 64- and 128-bit 1385 descriptors require two eight- and two sixteen-octet unsigned 1386 integers respectively. 1388 Since each Hole definition takes up eight octets when 32-bit offset 1389 lengths are used, we expect that well over 100 such definitions can 1390 fit in a single HOLESTOFILL packet, given the IPv6 minimum MTU. 1392 A 'voluntary' HOLESTOFILL is sent at the start of each transaction, 1393 once METADATA information has been received. This indicates that the 1394 receiver is ready to receive the file, or indicates an error or 1395 rejection code, described below. A HOLESTOFILL indicating a 1396 successfully established transfer has a Progress Indicator of zero 1397 and an In-Response-To field of zero. 1399 On receiving a HOLESTOFILL packet, the sender SHOULD prioritize 1400 sending the necessary data to fill those holes, in order to advance 1401 the Progress Indicator at the receiver. 1403 A completed transfer is inferred from the reported receiver window 1404 position. In the final HOLESTOFILL packet sent by the receiver once 1405 the file to be transferred has been completely received, bit 14 MUST 1406 be 0 (indicating a complete set of holes in this packet), there MUST 1407 NOT be any holestofill offset pairs indicating holes, the In- 1408 Response-To field points to the last byte of the file, and the 1409 voluntary flag MUST be set. This 'completed' HOLESTOFILL may be 1410 repeated, depending on subsequent sender behaviour, while internal 1411 state about the transfer remains available to the receiver. 1413 In the case of an error causing a transfer to be aborted, the Status 1414 field holds a code that can be used to explain the cause of the error 1415 to the other peer. A zero value indicates that there have been no 1416 significant errors (this is called a "success HOLESTOFILL" within 1417 this document), while any non-zero value means the transaction should 1418 be aborted (this is called a "failure HOLESTOFILL"). 1420 +------------+------------------------------------------------------+ 1421 | Status | Meaning | 1422 | Value | | 1423 +------------+------------------------------------------------------+ 1424 | 0x00 | Success, No Errors. | 1425 | 0x01 | Unspecified Error. | 1426 | 0x02 | Unable to send file due to resource constraints. | 1427 | 0x03 | Unable to receive file due to resource constraints. | 1428 | 0x04 | File not found. | 1429 | 0x05 | Access Denied. | 1430 | 0x06 | Unknown Id field for transaction. | 1431 | 0x07 | Did not delete file. | 1432 | 0x08 | File length is longer than REQUEST indicates support | 1433 | | for. | 1434 | 0x09 | File offset descriptors do not match expected use or | 1435 | | file length. | 1436 | 0x0A | Unsupported packet type received. | 1437 | 0x0B | DATA flag bits describing transfer have changed | 1438 | | unexpectedly. | 1439 | 0x0C | Receiver is no longer interested in receiving this | 1440 | | file. | 1441 | 0x0D | Receiver wants sender to pause its transfer. | 1442 | 0x0E | Receiver wants sender to resume a previously-paused | 1443 | | transfer. | 1444 +------------+------------------------------------------------------+ 1446 The recipient of a failure HOLESTOFILL MUST NOT try to process the 1447 Progress Indicator, In-Response-To, or Hole offsets, because, in some 1448 types of error conditions, the packet's sender may not have any way 1449 of setting them to the right length for the transaction. 1451 When sending an indefinite-length stream, the possibility of offset 1452 sequence numbers wrapping back to zero must be considered. This can 1453 be protected against by using large offsets, and by the stream 1454 receiver. The receiver MUST separate out holes before the offset 1455 wraps to zero from holes after the wrap, and send Hole definitions in 1456 different HOLESTOFILL packets, with Flag 14 set to mark them as 1457 incomplete. Any Hole straddling a sequence wrap MUST be broken into 1458 two separate Holes, with the second Hole starting at zero. The 1459 timestamps in HOLESTOFILL packets carrying any pre-wrap holes should 1460 be earlier than the timestamp in later packets, and should repeat the 1461 timestamp of the last DATA packet seen for that offset sequence 1462 before the following wrap to zero occurred. Receivers indicate that 1463 they no longer wish to receive streams by sending Status Code 0x0C. 1465 5. The Directory Entry 1467 Directory Entries have two uses within Saratoga: 1469 1. Within a METADATA packet, a Directory Entry is used to give 1470 information about the file being transferred, in order to 1471 facilitate proper reassembly of the file and to help the file- 1472 receiver understand how recently the file may have been created 1473 or modified. 1475 2. When a peer requests a directory listing via a _getdir_ REQUEST, 1476 the other peer generates a file containing a series of one or 1477 more concatenated Directory Entry records, and transfers this 1478 file as it would transfer the response to a normal _get_ REQUEST, 1479 sending the records together within DATA packets. This file may 1480 be either temporary or within-memory and not actually a part of 1481 the host's file system itself. 1483 Directory Entry Format 1485 0 1 2 3 1486 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 [ Size (descriptor) ] 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Mtime | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Ctime | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Properties | / 1495 +-+-+-+-+-+-+-+-+ / 1496 / / 1497 / File Path (max 1024 octets,variable length) / 1498 / ... // 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-// 1501 where 1503 +------------+------------------------------------------------------+ 1504 | field | description | 1505 +------------+------------------------------------------------------+ 1506 | Size | the size of the file or directory in octets. | 1507 | Mtime | a timestamp showing when the file or directory was | 1508 | | modified. | 1509 | Ctime | a timestamp of the last status change for this file | 1510 | | or directory. | 1511 | Properties | if set, bit 7 of this field indicates that the entry | 1512 | | corresponds to a directory. Bit 6, if set, | 1513 | | indicates that the file is "special". A special | 1514 | | file may not be directly transferable as it | 1515 | | corresponds to a symbolic link, a named pipe, a | 1516 | | device node, or some other "special" filesystem | 1517 | | object. A file-sender may simply choose not to | 1518 | | include these types of files in the results of a | 1519 | | _getdir_ request. | 1520 | File Path | contains the file's name relative within the | 1521 | | requested path of the _getdir_ transaction, a | 1522 | | maximum of 1024-octet UTF-8 string, that is | 1523 | | null-terminated to indicate the beginning of the | 1524 | | next directory entry in _getdir_ results | 1525 +------------+------------------------------------------------------+ 1526 +-------+-------+---------------------+ 1527 | Bit 6 | Bit 7 | Properties conveyed | 1528 +-------+-------+---------------------+ 1529 | 0 | 0 | normal file. | 1530 | 0 | 1 | normal directory. | 1531 | 1 | 0 | special file. | 1532 | 1 | 1 | special directory. | 1533 +-------+-------+---------------------+ 1535 Whether a particular Directory Entry is being interpreted as the 1536 contents of a METADATA packet, or as the result of a _getdir_ 1537 transaction, the width of the Size field is the same as that used for 1538 all lengths and offsets within the transfer, given by the METADATA 1539 and DATA Flags bits 8 and 9. 1541 Streams listed in a directory should be marked as special. If a 1542 stream is being transferred, its size is unknown -- otherwise it 1543 would be a file. The size property of a Directory Entry for a stream 1544 is therefore expected to be zero. 1546 It is expected that files are only listed in Directory Entries if 1547 they can be transferred to the requester. An implementation only 1548 capable of receiving small files using 16-bit descriptors will only 1549 see small files capable of being transferred to it when browsing the 1550 filesystem of an implementation capable of larger sizes. Directory 1551 sizes are not sent, and a Size of 0 is given instead for directories. 1553 The "epoch" format used in the timestamps for Mtime and Ctime in file 1554 object records is the number of seconds since January 1, 2000 in UTC, 1555 which is the same epoch used in the DTN Bundle Protocol for 1556 timestamps and postpones wrapping for 30 years beyond typical 1970- 1557 based timestamps. This should include all leapseconds. 1559 A file-receiver should preserve the timestamp information received in 1560 the METADATA for its own copy of the file, to allow newer versions of 1561 files to propagate and supercede older versions. 1563 6. Behavior of a Saratoga Peer 1565 This section describes some details of Saratoga implementations and 1566 uses the RFC 2119 standards language to describe which portions are 1567 needed for interoperability. 1569 6.1. Saratoga Transactions 1571 Following are descriptions of the packet exchanges between two peers 1572 for each type of transaction. 1574 6.1.1. The _get_ Transaction 1576 1. A peer (the file-receiver) sends a REQUEST packet to its peer 1577 (the file-sender). The Flags bits are set to indicate that this 1578 is not a _delete_ request, nor does the File Path indicate a 1579 directory. Each _get_ transaction corresponds to a single file, 1580 and fetching multiple files requires sending multiple REQUEST 1581 packets and using multiple transaction Ids. If a specific file is 1582 being requested, then its name is filled into the File Path 1583 field, otherwise it is left null and the file-sender will send a 1584 file of its choice. 1586 2. If the request is rejected, then a HOLESTOFILL packet containing 1587 an error code in the Status field is sent and the transaction is 1588 terminated. This HOLESTOFILL packet MUST be sent to reject and 1589 terminate the transaction. The error code MAY make use of the 1590 "Unspecified Error" value for security reasons. Some REQUESTs 1591 might also be rejected for specifying files that are too large to 1592 have their lengths encoded within the maximum integer field width 1593 advertised by bits 8 and 9 of the REQUEST. 1595 3. If the request is accepted, then a HOLESTOFILL packet MUST be 1596 sent with an error code of 0x00 and an In-Response-To field of 1597 zero. 1599 4. Otherwise, if the request is granted, then the file-sender 1600 generates and sends a METADATA packet along with the contents of 1601 the file as a series of DATA packets. In the absence of 1602 HOLESTOFILL packets, if the file-sender believes it has finished 1603 sending the file, it MUST send the last DATA packet with the 1604 Flags bit set requesting a HOLESTOFILL response from the file- 1605 receiver. This can be followed by empty DATA packets with the 1606 Flags bit set requesting a HOLESTOFILL until either a HOLESTOFILL 1607 packet is received, or the inactivity timer expires. All of the 1608 DATA packets MUST use field widths for the file offset descriptor 1609 fields that match what the Flags of the METADATA packet 1610 specified. Some arbitrarily selected DATA packets may have the 1611 Flags bit set that requests a HOLESTOFILL packet. The file- 1612 receiver MAY voluntarily send HOLESTOFILL packets at other times, 1613 where the In-Response-To field MUST set to zero. The file- 1614 receiver SHOULD voluntarily send a HOLESTOFILL packet in response 1615 to the first DATA packet. 1617 5. As the file-receiver takes in the DATA packets, it writes them 1618 into the file locally. The file-receiver keeps track of missing 1619 data in a hole list. Periodically the file sender will set the 1620 ack flag bit in a DATA packet and request a HOLESTOFILL packet 1621 from the file-receiver, with a copy of this hole list. File- 1622 receivers MUST send a HOLESTOFILL packet immediately in response 1623 to receiving a DATA packet with the Flags bit set requesting a 1624 HOLESTOFILL. 1626 6. If the file-sender receives a HOLESTOFILL packet with a non-zero 1627 number of holes, it re-fetches the file data at the specified 1628 offsets and re-transmits it. If the METADATA packet requires 1629 retransmission, this is indicated by a bit in the HOLESTOFILL 1630 packet, and the METADATA packet is retransmitted. The file- 1631 sender MUST retransmit data from any holes reported by the file- 1632 receiver before proceeding further with new DATA packets. 1634 7. When the file-receiver has fully received the file data and the 1635 METADATA packet, then it sends a HOLESTOFILL packet indicating 1636 that the transaction is complete, and it terminates the 1637 transaction locally, although it MUST persist in responding to 1638 DATA packets requesting HOLESTOFILLs from the file-sender for 1639 some reasonable amount of time. 1641 Given that there may be a high degree of asymmetry in link bandwidth 1642 between the file-sender and file-receiver, the HOLESTOFILL packets 1643 should be carefully generated so as to not congest the feedback path. 1644 This means that both a file-sender should be cautious in setting the 1645 DATA Flags bit requesting HOLESTOFILLs, and also that a file-receiver 1646 should be cautious in gratuitously generating HOLESTOFILL packets of 1647 its own volition. On unidirectional links, a file-sender cannot 1648 reasonably expect to receive HOLESTOFILL packets, so should never 1649 request them. 1651 6.1.2. The _getdir_ Transaction 1653 A _getdir_ transaction proceeds through the same states as the _get_ 1654 transaction. The two differences are that the REQUEST has the 1655 directory bit set in its Flags field, and that, rather than 1656 transferring the contents of a file from the file-receiver to the 1657 file-sender, a set of records representing the contents of a 1658 directory are transferred. These can be parsed and dealt with by the 1659 file-receiver as desired. There is no requirement that a Saratoga 1660 peer send the full contents of a directory listing; a peer may filter 1661 the results to only those entries that are actually accessible to the 1662 requesting peer. 1664 For _getdir_ transactions, the METADATA's bits 8 and 9 in the Flags 1665 field specify both the width of the offset and length fields used 1666 within the transfers DATA and HOLESTOFILL packets, and also the width 1667 of file Size fields within Directory Entries in the interpreted 1668 _getdir_ results. These Flags bits are set to the minimum of the 1669 file-sender's locally-supported maximum width and the advertised 1670 maximum width within the REQUEST packet, and any file system entries 1671 that would normally be contained in the results, but that have sizes 1672 greater than this width can convey, MUST be filtered out. 1674 6.1.3. The _delete_ Transaction 1676 1. A peer sends a REQUEST packet with the bit set indicating that it 1677 is a deletion request and the path to be deleted is filled into 1678 the File Path field. The File Path MUST be filled in for 1679 _delete_ transactions, unlike for _get_ transactions. 1681 2. The other peer replies with a feedback HOLESTOFILL packet having 1682 a Status code that indicates whether the deletion was granted and 1683 occurred successfully (indicated by the 0x00 Status field in a 1684 success HOLESTOFILL), or whether some error occurred (indicated 1685 by the non-zero Status field in a failure HOLESTOFILL). This 1686 HOLESTOFILL packet MUST have no Holes and 16-bit width zero- 1687 valued Progress Indicator and In-Response-To fields. 1689 6.1.4. The _put_ Transaction 1691 A _put_ transaction proceeds exactly as a _get_, except the file- 1692 sender and file-receiver roles are exchanged between peers, and no 1693 REQUEST packet is ever sent. The file-sending end senses that the 1694 transaction is in progress when it receives METADATA or DATA packets 1695 for which it has no knowledge of the Id field. If the file-receiver 1696 decides that it will store and handle this request (at least 1697 provisionally), then it MUST send a voluntary (ie, not requested) 1698 success HOLESTOFILL packet to the file-sender. Otherwise, it sends a 1699 failure HOLESTOFILL packet. After sending a failure HOLESTOFILL 1700 packet, it may ignore future packets with the same Id field from the 1701 file-sender, but it should, at a low rate, periodically regenerate 1702 the failure HOLESTOFILL packet if the flow of packets does not stop. 1704 6.2. Beacons 1706 Sending BEACON packets is not needed in any of the transactions 1707 discussed in this specification, but optional BEACONs can provide 1708 useful information in many situations. If a node periodically 1709 generates BEACON packets, then it should do so at a low rate which 1710 does not significantly affect in-progress data transfers. 1712 A node that supports multiple versions of Saratoga (e.g. version 1 1713 from this specification along with the older version 0), MAY send 1714 multiple BEACON packets showing different version numbers. The 1715 version number in a single BEACON should not be used to infer the 1716 larger set of protocol versions that a peer is compatible with. 1718 If a node receives BEACONs from a peer, then it SHOULD NOT attempt to 1719 start any _get_, _getdir_, or _delete_ transactions with that peer if 1720 bit 14 is not set in the latest received BEACONs. Likewise, if 1721 received BEACONs from a peer do not have bit 15 set, then _put_ 1722 transactions SHOULD NOT be attempted to that peer. Unlike the 1723 capabilities bits which prevent certain types of transactions from 1724 being attempted, the willingness bits are advisory, and transactions 1725 MAY be attempted even if the node is not advertising a willingness, 1726 as long as it advertises a capability. This avoids waiting for a 1727 willingness indication across long-delay links. 1729 6.3. Upper-Layer Interface 1731 No particular interface functionality is required in implementations 1732 of this specification. The means and degree of access to Saratoga 1733 configuration settings and transaction control that is offered to 1734 upper layers and applications is completely implementation-dependent. 1735 In general, it is expected that upper layers (or users) can set 1736 timeout values for transaction requests and for inactivity periods 1737 during the transaction, on a per-peer or per-transaction basis, but 1738 in some implementations where the Saratoga code is restricted to run 1739 only over certain interfaces with well-understood operational latency 1740 bounds, then these timers MAY be hard-coded. 1742 6.4. Inactivity Timer 1744 In order to determine the liveliness of a transaction, Saratoga nodes 1745 may implement an inactivity timer for each peer they are expecting to 1746 see packets from. For each packet received from a peer, its 1747 associated inactivity timer is reset. If no packets are received for 1748 some amount of time, and the inactivity timer expires, this serves as 1749 a signal to the node that it should abort (and optionally retry) any 1750 sessions that were in progress with the peer. Information from the 1751 link interface (i.e. link down) can override this timer for point-to- 1752 point links. 1754 The actual length of time that the inactivity timer runs for is a 1755 matter of both implementation and deployment situation. Relatively 1756 short timers (on the order of several round-trip times) allow nodes 1757 to quickly react to loss of contact, while longer timers allow for 1758 transaction robustness in the presence of transient link problems. 1759 This document deliberately does not specify a particular inactivity 1760 timer value nor any rules for setting the inactivity timer, because 1761 the protocol is intended to be used in both long- and short-delay 1762 regimes. 1764 Specifically, the inactivity timer is started on sending REQUEST or 1765 HOLESTOFILL packets. When sending packets not expected to elicit 1766 responses (BEACON, METADATA, or DATA without acknowledgement 1767 requests), there is no point to starting the local inactivity timer. 1769 For normal file transfers, there are simple rules for handling 1770 expiration of the inactivity timer during a _get_ or _put_ 1771 transaction. The file-sender SHOULD terminate the transaction state 1772 and cease to send DATA or METADATA packets. The file-receiver SHOULD 1773 stop sending HOLESTOFILL packets, and MAY choose to store the file in 1774 some cache location so that the transfer can be recovered. This is 1775 possible by waiting for an opportunity to re-attempt the transaction 1776 and immediately sending a HOLESTOFILL that only lists the parts of 1777 the file not yet received if the transaction is granted. In any 1778 case, a partially-received file MUST NOT be handled in any way that 1779 would allow another application to think it is complete. 1781 The file-sender may implement more complex timers to allow rate-based 1782 pacing or simple congestion control using information provided in 1783 HOLESTOFILL packets, but such possible timers and their effects are 1784 deliberately not specified here. 1786 7. Mailing list 1788 There is a mailing list for discussion of Saratoga and its 1789 implementations. Contact Lloyd Wood for details. 1791 8. Security Considerations 1793 The design of Saratoga provides limited, deliberately lightweight, 1794 services for authentication of session requests, and for 1795 authentication or encryption of data files via keyed metadata 1796 checksums. This document does not specify privacy or access control 1797 for data files transferred. Privacy, access, authentication and 1798 encryption issues may be addressed within an implementation or 1799 deployment in several ways that do not affect the file transfer 1800 protocol itself. As examples, IPsec may be used to protect Saratoga 1801 implementations from forged packets, to provide privacy, or to 1802 authenticate the identity of a peer. Other implementation-specific 1803 or configuration-specific mechanisms and policies might also be 1804 employed for authentication and authorization of requests. 1805 Protection of file data and meta-data can also be provided by a 1806 higher-level file encryption facility. If IPsec is not required, use 1807 of encryption before the file is given to Saratoga is preferable. 1808 Basic security practices like not accepting paths with "..", not 1809 following symbolic links, and using a chroot() system call, among 1810 others, should also be considered within an implementation. 1812 Note that Saratoga is intended solely for single-hop transfers 1813 between peers. A METADATA checksum using a previously shared key can 1814 be used to decrypt or authenticate delivered DATA files. Saratoga 1815 can only provide encryption across a single link, not end-to-end 1816 across concatenated links through untrusted peers, as checksum 1817 verification of file integrity is required at each node. End-to-end 1818 data encryption, if required, MUST be implemented by the application 1819 using Saratoga. 1821 9. IANA Considerations 1823 IANA has allocated port 7542 (tcp/udp) for use by Saratoga. 1825 saratoga 7542/tcp Saratoga Transfer Protocol 1826 saratoga 7542/udp Saratoga Transfer Protocol 1828 IANA has allocated a dedicated IPv4 all-hosts multicast address 1829 (224.0.0.108) and a dedicated IPv6 link-local multicast addresses 1830 (FF02:0:0:0:0:0:0:6c) for use by Saratoga. 1832 10. Acknowledgements 1834 Developing and deploying the on-orbit IP infrastructure of the 1835 Disaster Monitoring Constellation, in which Saratoga has proven 1836 useful, has taken the efforts of hundreds of people over more than a 1837 decade. We thank them all. 1839 Work on this document at NASA's Glenn Research Center was funded by 1840 NASA's Earth Science Technology Office (ESTO). 1842 We thank Stewart Bryant, Cathryn Peoples and Charles Smith for their 1843 review comments. We regard Charles as a named coauthor of this work. 1845 11. A Note on Naming 1847 Saratoga is named for the USS Saratoga (CV-3), the aircraft carrier 1848 sunk at Bikini Atoll that is now a popular diving site. 1850 12. References 1852 12.1. Normative References 1854 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1855 August 1980. 1857 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1858 April 1992. 1860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1861 Requirement Levels", BCP 14, RFC 2119, March 1997. 1863 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 1864 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 1865 September 2002. 1867 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1868 10646", STD 63, RFC 3629, November 2003. 1870 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1871 G. Fairhurst, "The Lightweight User Datagram Protocol 1872 (UDP-Lite)", RFC 3828, July 2004. 1874 12.2. Informative References 1876 [Hogie05] Hogie, K., Criscuolo, E., and R. Parise, "Using Standard 1877 Internet Protocols and Applications in Space", Computer 1878 Networks, Special Issue on Interplanetary Internet, vol. 1879 47, no. 5, pp. 603-650, April 2005. 1881 [I-D.ietf-ledbat-congestion] 1882 Shalunov, S., "Low Extra Delay Background Transport 1883 (LEDBAT)", draft-ietf-ledbat-congestion-01 (work in 1884 progress), March 2010. 1886 [I-D.wood-dtnrg-http-dtn-delivery] 1887 Wood, L. and P. Holliday, "Using HTTP for delivery in 1888 Delay/Disruption-Tolerant Networks", 1889 draft-wood-dtnrg-http-dtn-delivery-05 (work in progress) , 1890 May 2010. 1892 [I-D.wood-dtnrg-saratoga] 1893 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 1894 Jackson, "Using Saratoga with a Bundle Agent as a 1895 Convergence Layer for Delay-Tolerant Networking", 1896 draft-wood-dtnrg-saratoga-07 (work in progress) , 1897 May 2010. 1899 [Jackson04] 1900 Jackson, C., "Saratoga File Transfer Protocol", Surrey 1901 Satellite Technology Ltd internal technical document , 1902 2004. 1904 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 1905 STD 9, RFC 959, October 1985. 1907 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on 1908 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, 1909 August 2002. 1911 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 1912 Friendly Rate Control (TFRC): Protocol Specification", 1913 RFC 3448, January 2003. 1915 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1916 Specification", RFC 5050, November 2007. 1918 [Wood07a] Wood, L., Ivancic, W., Hodgson, D., Miller, E., Conner, 1919 B., Lynch, S., Jackson, C., da Silva Curiel, A., Cooke, 1920 D., Shell, D., Walke, J., and D. Stewart, "Using Internet 1921 Nodes and Routers Onboard Satellites", International 1922 Journal of Satellite Communications and 1923 Networking, Special Issue on Space Networks, vol. 25, no. 1924 2, pp. 195-216, March/April 2007. 1926 [Wood07b] Wood, L., Eddy, W., Ivancic, W., Miller, E., McKim, J., 1927 and C. Jackson, "Saratoga: a Delay-Tolerant Networking 1928 convergence layer with efficient link utilization", 1929 International Workshop on Satellite and Space 1930 Communications (IWSSC '07) Salzburg, September 2007. 1932 Appendix A. Appendix: Timestamp/Nonce field considerations 1934 The format of optional timestamps is implementation-dependent. How 1935 the contents of this timestamp field are used and interpreted depends 1936 on local needs and conventions and the local implementation. 1937 However, one simple suggested format for timestamps is to begin with 1938 a POSIX time_t representation of time, in network byte order. This 1939 is either a 32-bit or 64-bit signed integer representing the number 1940 of seconds since 1970. The remainder of this field can be used 1941 either for a representation of elapsed time within the current 1942 second, if that level of accuracy is required, or as a nonce field 1943 uniquely identifying the packet or including other information. Any 1944 locally-meaningful flags identifying a type of timestamp or timebase 1945 can be included before the end of the field. Unused parts of this 1946 field MUST be set to zero. 1948 There are many different representations of timestamps and timebases, 1949 and this draft is too short to cover them in detail. One suggested 1950 flag representation of different timestamp fields is to use the least 1951 significant bits at the end of the timestamp/nonce field as: 1953 +---------+---------------------------------------------------------+ 1954 | Status | Meaning | 1955 | Value | | 1956 +---------+---------------------------------------------------------+ 1957 | 0x00 | No flags set, local interpretation of field. | 1958 | 0x01 | 32-bit timestamp at start of field indicating whole | 1959 | | seconds from epoch. | 1960 | 0x02 | 64-bit timestamp at start of field indicating whole | 1961 | | seconds elapsed from epoch. | 1962 | 0x03 | 32-bit timestamp, as in 0x01, followed by 32-bit | 1963 | | timestamp indicating fraction of the second elapsed. | 1964 | 0x04 | 64-bit timestamp, as in 0x02, followed by 32-bit | 1965 | | timestamp indicating fraction of the second elapsed. | 1966 +---------+---------------------------------------------------------+ 1968 Other values may indicate specific epochs or timebases, as local 1969 requirements dictate. There are many ways to define and use time 1970 usefully. 1972 Timestamp values provide a useful mechanism for Saratoga peers to 1973 measure path and round-trip latency. The use of timestamp values may 1974 assist in developing algorithms for flow control (including TCP- 1975 Friendly Rate Control) or other purposes. 1977 Authors' Addresses 1979 Lloyd Wood 1980 Centre for Communication Systems Research, University of Surrey 1981 Guildford, Surrey GU2 7XH 1982 United Kingdom 1984 Phone: +44-1483-698123 1985 Email: L.Wood@surrey.ac.uk 1987 Jim McKim 1988 RS Information Systems 1989 NASA Glenn Research Center 1990 21000 Brookpark Road, MS 142-1 1991 Cleveland, OH 44135 1992 USA 1994 Phone: +1-216-433-6536 1995 Email: James.H.McKim@grc.nasa.gov 1996 Wesley M. Eddy 1997 MTI Systems 1998 MS 500-ASRC 1999 NASA Glenn Research Center 2000 21000 Brookpark Road, MS 54-5 2001 Cleveland, OH 44135 2002 USA 2004 Phone: +1-216-433-6682 2005 Email: wes@mti-systems.com 2007 Will Ivancic 2008 NASA Glenn Research Center 2009 21000 Brookpark Road, MS 54-5 2010 Cleveland, OH 44135 2011 USA 2013 Phone: +1-216-433-3494 2014 Email: William.D.Ivancic@grc.nasa.gov 2016 Chris Jackson 2017 Surrey Satellite Technology Ltd 2018 Tycho House 2019 Surrey Space Centre 2020 20 Stephenson Road 2021 Guildford, Surrey GU2 7YE 2022 United Kingdom 2024 Phone: +44-1483-803-803 2025 Email: C.Jackson@sstl.co.uk