idnits 2.17.1 draft-irtf-dtnrg-ltp-motivation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1298. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Sec 6' is mentioned on line 879, but not defined == Unused Reference: 'B97' is defined on line 1199, but no explicit reference was found in the text == Unused Reference: 'IPN' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'ECS94' is defined on line 1243, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-03 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-ltp (ref. 'LTP') == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-ltp-extensions-01 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-ltp-extensions (ref. 'LTPEXT') -- Obsolete informational reference (is this intentional?): RFC 3448 (ref. 'TFRC') (Obsoleted by RFC 5348) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'ECS94') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay Tolerant Networking Research Group S. Burleigh 3 Internet Draft NASA/Jet Propulsion Laboratory 4 M. Ramadas 5 March 2006 Ohio University 6 Expires September 2006 S. Farrell 7 Trinity College Dublin 9 Licklider Transmission Protocol - Motivation 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 1, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes the Licklider Transmission Protocol (LTP) 43 designed to provide retransmission-based reliability over links 44 characterized by extremely long message round-trip times (RTTs) 45 and/or frequent interruptions in connectivity. Since communication 46 across interplanetary space is the most prominent example of this 47 sort of environment, LTP is principally aimed at supporting "long- 48 haul" reliable transmission in interplanetary space, but has 49 applications in other environments as well. 51 In an Interplanetary Internet setting deploying the Bundling protocol 52 being developed by the Delay Tolerant Networking Research Group, LTP 53 is intended to serve as a reliable convergence layer over single hop 54 deep-space RF links. LTP does ARQ of data transmissions by soliciting 55 selective-acknowledgment reception reports. It is stateful and has 56 no negotiation or handshakes. 58 This document is a product of the Delay Tolerant Networking Research 59 Group and has been reviewed by that group. No objections to its 60 publication as an RFC were raised. 62 Table of Contents 64 1. Introduction ................................................. 3 65 2. Motivation ................................................... 4 66 2.1 IPN Operating Environment ................................ 4 67 2.2 Why not Standard Internet Protocols? ..................... 6 68 3. Features ..................................................... 7 69 3.1 Massive State Retention .................................. 8 70 3.1.1 Multiplicity of Protocol State Machines ............. 8 71 3.1.2 Session IDs ......................................... 9 72 3.1.3 Use of Non-volatile Storage ......................... 9 73 3.2 Absence of Negotiation ................................... 9 74 3.3 Partial Reliability ...................................... 10 75 3.4 Laconic Acknowledgment ................................... 11 76 3.5 Adjacency ................................................ 12 77 3.6 Optimistic and Dynamic Timeout Interval Computation ...... 13 78 3.7 Deferred Transmission .................................... 14 79 4. Overall Operation ............................................ 14 80 4.1 Nominal Operation ........................................ 14 81 4.2 Retransmission ........................................... 16 82 4.3 Accelerated Retransmission ............................... 18 83 4.4 Session Cancellation ..................................... 19 84 5. Functional Model ............................................. 20 85 5.1 Deferred Transmission .................................... 20 86 5.2 Timers ................................................... 20 87 6. Tracing LTP back to CFDP ..................................... 23 88 7. Security Considerations ...................................... 25 89 8. IANA Considerations .......................................... 25 90 9. Acknowledgments .............................................. 25 91 10. References ................................................... 25 92 10.1 Normative References ..................................... 25 93 10.2 Informative References ................................... 26 94 11. Author's Addresses ........................................... 26 95 1. Introduction 97 Discussions on this internet-draft are being made in the Delay 98 Tolerant Networking Research Group (DTNRG) mailing list. More 99 information can be found in the DTNRG web-site at 100 http://www.dtnrg.org 102 The Licklider Transmission Protocol (LTP) described in this memo is 103 designed to provide retransmission-based reliability over links 104 characterized by extremely long message round-trip times and/or 105 frequent interruptions in connectivity. Communication in 106 interplanetary space is the most prominent example of this sort of 107 environment, and LTP is principally aimed at supporting "long-haul" 108 reliable transmission over deep-space RF links. 110 Since 1982 the principal source of standards for space communications 111 has been the Consultative Committee for Space Data Systems (CCSDS) 112 [CCSDS]. Engineers of CCSDS member agencies have developed 113 communication protocols that function within the constraints imposed 114 by operations in deep space. These constraints differ sharply from 115 those within which the Internet typically functions: 117 o Extremely long signal propagation delays, on the order of 118 seconds, minutes, or hours rather than milliseconds. 120 o Frequent and lengthy interruptions in connectivity. 122 o Low levels of traffic coupled with high rates of 123 transmission error. 125 o Meager bandwidth and highly asymmetrical data rates. 127 The CCSDS File Delivery Protocol (CFDP) [CFDP] in particular, 128 automates reliable file transfer across interplanetary distances by 129 detecting data loss and initiating the requisite retransmission 130 without mission operator intervention. 132 CFDP by itself is sufficient for operating individual missions, but 133 its built-in networking capabilities are rudimentary. In order to 134 operate within the IPN environment it must rely on the routing and 135 incremental retransmission capabilities of the Bundling protocol [BP] 136 defined for Delay-Tolerant Networks [DTN]. LTP is intended to serve 137 as a reliable "convergence layer" protocol underlying Bundling in DTN 138 regions whose links are characterized by very long round-trip times. 139 Its design notions are directly descended from the retransmission 140 procedures defined for CFDP. 142 This document describes the motivation for LTP, its features, 143 functions, and overall design, and is part of a series of documents 144 describing LTP. Other documents in the series include the main 145 protocol specification document [LTP] and the protocol extensions 146 document [LTPEXT] respectively. 148 2. Motivation 150 2.1 IPN Operating Environment 152 There are a number of fundamental differences between the environment 153 for terrestrial communications and the operating environments 154 envisioned for the IPN. 156 The most challenging difference between communication among points on 157 Earth and communication among planets is round-trip delay, of which 158 there are two main sources, both relatively intractable: natural law 159 and economics. 161 The more obvious type of delay imposed by nature is signal 162 propagation time. Our inability to transmit data at speeds higher 163 than the speed of light means that while round-trip times in the 164 terrestrial Internet range from milliseconds to a few seconds, 165 minimum round-trip times to Mars range from 8 to 40 minutes, 166 depending on the planet's position. Round-trip times between Earth 167 and Jupiter's moon Europa run between 66 and 100 minutes. 169 Less obvious and more dynamic is the delay imposed by occultation. 170 Communication between planets must be by radiant transmission, which 171 is usually possible only when the communicating entities are in line 172 of sight of each other. An entity residing on a planetary surface 173 will be periodically taken out of sight by the planet's rotation (it 174 will be "on the other side of" the planet); an entity that orbits a 175 planet will be periodically taken out of sight by orbital motion (it 176 will be "behind" the planet); and planets themselves lose mutual 177 visibility when their trajectories take them to opposite sides of the 178 Sun. During the time that communication is impossible, delivery is 179 impaired and messages must wait in a queue for later transmission. 181 Round-trip times and occultations can at least be readily computed 182 given the ephemerides of the communicating entities. Additional 183 delay that is less easily predictable is introduced by discontinuous 184 transmission support, which is rooted in economics. 186 Communicating over interplanetary distances requires expensive 187 special equipment: large antennas, high-performance receivers, etc. 188 For most deep-space missions, even non-NASA ones, these are currently 189 provided by NASA's Deep Space Network (DSN) [DSN]. The communication 190 resources of the DSN are currently oversubscribed and will probably 191 remain so for the foreseeable future. While studies have been done 192 as to the feasibility of upgrading or replacing the current DSN, the 193 number of deep space missions will probably continue to grow faster 194 than the terrestrial infrastructure that supports them, making over- 195 subscription a persistent problem. Radio contact via the DSN must 196 therefore be carefully scheduled and is often severely limited. 198 This over-subscription means that the round-trip times experienced by 199 packets will be affected not only by the signal propagation delay and 200 occultation, but also by the scheduling and queuing delays imposed by 201 management of Earth-based resources: packets to be sent to a given 202 destination may have to be queued until the next scheduled contact 203 period, which may be hours, days, or even weeks away. While queuing 204 and scheduling delays are generally known well in advance except when 205 missions need emergency service (such as during landings and 206 maneuvers), the long and highly variable delays make the design of 207 timers, and retransmission timers in particular, quite difficult. 209 Another significant difference between deep space and terrestrial 210 communication is bandwidth availability. The combined effects of 211 large distances (resulting in signal attenuation), the expense and 212 difficulty of deploying large antennas to distant planets, and the 213 difficulty of generating electric power in space all mean that the 214 available bandwidth for communication in the IPN will likely remain 215 modest compared to terrestrial systems. Maximum data rates on the 216 order of a few tens of megabits per second will probably be the norm 217 for the next few decades. 219 Moreover, the available bandwidths are highly asymmetrical: data are 220 typically transmitted at different rates in different directions on 221 the same link. Current missions are usually designed with a much 222 higher data "return" rate (from spacecraft to Earth) than "command" 223 rate (from Earth to spacecraft). The reason for the asymmetry is 224 simple: nobody ever wanted a high-rate command channel, and, all else 225 being equal, it was deemed better to have a more reliable command 226 channel than a faster one. This design choice has led to data rate 227 asymmetries in excess of 100:1, sometimes approaching 1000:1. A 228 strong desire for a very robust command channel will probably remain, 229 so any transport protocol designed for use in the IPN will need to 230 function with a relatively low-bandwidth outbound channel to 231 spacecraft and landers. 233 The difficulty of generating power on and around other planets will 234 also result in relatively low signal-to-noise ratios and thus high 235 bit error rates. Current deep-space missions operate with raw bit 236 error rates on the order of 10^(-1) to 10^(-3); while heavy coding is 237 used to reduce error rates, the coding overhead further reduces the 238 residual bandwidth available for data transmission. 240 Signal propagation delay is the only truly immutable characteristic 241 that distinguishes the IPN from terrestrial communications. Queuing 242 and scheduling delays, low data rates, intermittent connectivity, and 243 high bit error rates can all be mitigated or eliminated by adding 244 more infrastructure. But this additional infrastructure is likely to 245 be provided (if at all) only in the more highly developed core areas 246 of the IPN. We see the IPN growing outwards from Earth as we explore 247 more and more planets, moons, asteroids, and possibly other stars. 248 This suggests that there will always be a "fringe" to the fabric of 249 the IPN, an area without a rich communications infrastructure. The 250 delay, data rate, connectivity, and error characteristics mentioned 251 above will probably always be an issue somewhere in the IPN. 253 2.2 Why not Standard Internet Protocols? 255 These environmental characteristics - long delays, low and asymmetric 256 bandwidth, intermittent connectivity, and relatively high error rates 257 - make using unmodified TCP for end to end communications in the IPN 258 infeasible. Using the TCP throughput equation from [TFRC] we can 259 calculate the loss event rate (p) required to achieve a given steady- 260 state throughput. Assuming the minimum RTT to Mars from planet Earth 261 is 8 minutes (one-way speed of light delay to Mars at its closest 262 approach to Earth is 4 minutes), assuming a packet size of 1500 263 bytes, assuming that the receiver acknowledges every other packet, 264 and ignoring negligible higher order terms in p (i.e., ignoring the 265 second additive term in the denominator of the TCP throughput 266 equation), we obtain the following table of loss event rates required 267 to achieve various throughput values. 269 Throughput Loss event rate (p) 270 ---------- ------------------- 271 10 Mbps 4.68 * 10^(-12) 272 1 Mbps 4.68 * 10^(-10) 273 100 Kbps 4.68 * 10^(-8) 274 10 Kbps 4.68 * 10^(-6) 276 Note that although multiple losses encountered in a single RTT are 277 treated as a single loss event in the TCP throughput equation from 278 [TFRC], such loss event rates are still unrealistic on deep space 279 links. 281 The above values are upper bounds on steady-state throughput. Since 282 the number of packets in an episode of connectivity will generally be 283 under 10,000 due to the low available bandwidth, TCP performance 284 would be dominated by its behavior during slow-start. This means 285 that even when Mars is at its closest approach to Earth it would take 286 a TCP session nearly 100 minutes to ramp up to an Earth-Mars 287 transmission rate of 20kbps. 289 Note: Lab experiments using a channel emulator and standard 290 applications show that even if TCP could be pushed to work 291 efficiently at such distances, many applications either rely on 292 several rounds of handshaking or have built-in timers that render 293 them non-functional when the round-trip-time is over a couple of 294 minutes. For example, it typically takes eight round trips for FTP 295 to get to a state where data can begin flowing. Since an FTP server 296 may time out and reset the connection after 5 minutes of inactivity, 297 a conformant standard FTP server could be unusable for communicating 298 even with the closest planets. 300 The SCTP [SCTP] protocol can multiplex bundles (Note : defined 301 differently from the DTN "bundle") for multiple sessions over a 302 single layer connection just as LTP, but still requires multiple 303 round trips prior to transmitting application data for session setup 304 and so clearly does not suit the needs of the IPN operating 305 environment. 307 3. Features 309 The design of LTP differs from that of TCP in several significant 310 ways. The common themes running through these differences are two 311 central design assumptions, both of which amount to making virtues of 312 necessity. 314 First: given the severe innate constraints on interplanetary 315 communication discussed above, we assume that the computational 316 resources available to LTP engines will always be ample compared to 317 the communication resources available on the link between them. 319 Certainly in many cases the computational resources available to a 320 given LTP engine - such as one on board a small robotic spacecraft - 321 will not be ample by the standards of the Internet. But in those 322 cases we expect that the associated communication resources 323 (transmitter power, antenna size) will be even less ample, preserving 324 the expected disproportion between the two. 326 Second, we note that establishing a communication link across 327 interplanetary distance entails enacting several hardware 328 configuration measures based on the presumed operational state of the 329 remote communicating entity like: 331 o orienting a directional antenna correctly; 333 o tuning a transponder to pre-selected transmission and/or 334 reception frequencies; 336 o diverting precious electrical power to the transponder at the 337 last possible moment, and for the minimum necessary length of 338 time. 340 We therefore assume that the operating environment in which LTP 341 functions is able to pass information on the link status (termed 342 "link state cues" in this document) to LTP, telling it which remote 343 LTP engine(s) should currently be transmitting to the local LTP 344 engine and vice versa. The operating environment itself must have 345 this information in order to configure communication link hardware 346 correctly. 348 3.1 Massive State Retention 350 Like any reliable transport service employing ARQ, LTP is "stateful". 351 In order to assure the reception of a block of data it has sent, LTP 352 must retain for possible retransmission all portions of that block 353 which might not have been received yet. In order to do so, it must 354 keep track of which portions of the block are known to have been 355 received so far, and which are not, together with any additional 356 information needed for purposes of retransmitting part or all of that 357 block. 359 Long round-trip times mean substantial delay between the transmission 360 of a block of data and the reception of an acknowledgment from the 361 block's destination, signaling arrival of the block. If LTP 362 postponed transmission of additional blocks of data until it received 363 acknowledgment of the arrival of all prior blocks, valuable 364 opportunities to utilize what little deep space transmission 365 bandwidth is available would be forever lost. 367 For this reason, LTP is based in part on a notion of massive state 368 retention. Any number of requested transmissions may be concurrently 369 "in flight" at various displacements along the link between two LTP 370 engines, and the LTP engines must necessarily retain transmission 371 status and retransmission resources for all of them. Moreover, if 372 any of the data of a given block are lost en route, it will be 373 necessary to retain the state of that transmission during an 374 additional round trip while the lost data are retransmitted; even 375 multiple retransmission cycles may be necessary. 377 In sum, LTP transmission state information persists for a long time 378 because a long time must pass before LTP can be assured of 379 transmission success - so LTP must retain a great deal of state 380 information. Since the alternatives are non-reliability on the one 381 hand and severe under-utilization of transmission opportunities on 382 the other, we believe such massive statefulness is cost-justified 383 (though probably not for all LTP applications). 385 3.1.1 Multiplicity of Protocol State Machines 387 This design decision is reflected in a significant structural 388 difference between LTP and TCP. 390 Both TCP and LTP provide mechanisms for multiplexing access by a 391 variety of higher-layer services or applications: LTP's "client 392 service IDs" correspond to TCP's port numbers. Also, both TCP and 393 LTP implement devices for encapsulating threads of retransmission 394 protocol (protocol state machines): LTP's "sessions" functionally 395 correspond to TCP connections. At any moment each such thread of 396 retransmission protocol is engaged in conveying a single block of 397 data from one protocol end-point to another. 399 However, a single TCP association (local host address, local port 400 number, foreign host address, foreign port number) can accommodate at 401 most one connection at any one time. In contrast, a single LTP 402 association (local engine ID, local client service ID, foreign engine 403 ID, foreign client service ID) can accommodate multiple concurrent 404 sessions, one for each block of data in transit on the association. 406 3.1.2 Session IDs 408 In TCP, the fact that any single association is occupied by at most 409 one connection at any time enables the protocol to use host addresses 410 and port numbers to demultiplex arriving data to the appropriate 411 protocol state machines. LTP's possible multiplicity of sessions per 412 association makes it necessary for each segment of application data 413 to include an additional demultiplexing token, a "session ID" that 414 uniquely identifies the session in which the segment was issued and, 415 implicitly, the block of data being conveyed by this session. 417 3.1.3 Use of Non-volatile Storage 419 Another important implication of massive statefulness is that 420 implementations of LTP should consider retaining transmission state 421 information in non-volatile storage of some kind, such as magnetic 422 disk or flash memory. 424 Transport protocols such as TCP typically retain transmission state 425 in dynamic RAM. If the device on which the software resides is 426 rebooted or powered down then, although all transmissions currently 427 in progress are aborted, the resulting degree of communication 428 disruption is limited because the number of concurrent connections is 429 limited. Rebooting or power-cycling a computer on which an LTP 430 engine resides could abort a much larger number of transmission 431 sessions in various stages of completion, at a much larger total 432 cost. 434 3.2 Absence of Negotiation 436 In the IPN, round-trip times may be so long and communication 437 opportunities so brief that a negotiation exchange, such as an 438 adjustment of transmission rate, might not be completed before 439 connectivity is lost. Even if connectivity is uninterrupted, waiting 440 for negotiation to complete before revising data transmission 441 parameters might well result in costly under-utilization of link 442 resources. 444 For this reason, LTP communication session parameters are asserted 445 unilaterally, subject to application-level network management 446 activity that may not take effect for hours, days, or weeks. 448 3.3 Partial Reliability 450 For environments where application data is not critical, overall link 451 bandwidth utilization may be improved if the data is transmitted on a 452 "best efforts" basis, i.e., without being subject to acknowledgment 453 and retransmission. However, we believe that for many applications, 454 unreliable transmission of data is likely to be useful only if any 455 application headers/meta-data describing the actual data are received 456 reliably. For example, suppose a block transmission involves a high- 457 definition photograph (and can afford to be sent on "best efforts"): 458 the first 40 bytes of the block might be a prologue containing 459 information such as camera settings and time of exposure, without 460 which the photograph data is useless, while the actual photograph 461 data is an array of fixed-length scan lines. In this case the 462 assured delivery of the first 40 bytes of the block is critical for 463 interpreting the data, but the loss of a few individual scan lines 464 may not be important enough to justify the cost of retransmission. A 465 more typical example would be when the bundling protocol [BP] was the 466 upper-layer protocol operating over LTP : if a bundle needs to be 467 transmitted on "best efforts", it would at least be expected to have 468 the bundle protocol header received reliably, or the bundle itself 469 would be meaningless to the receiving bundling node. 471 The motivation for "partially reliable" transmission, as opposed to 472 an alternative unreliable mode, is therefore to provide a mechanism 473 for upper layer protocols to get any of their header and meta-data 474 transmitted reliably (as necessary) but have the actual data 475 transmitted unreliably. LTP regards each block of data as comprising 476 two parts: a "red-part", whose delivery must be assured by 477 acknowledgment and retransmission as necessary, and a "green-part" 478 whose delivery is attempted but not assured. 480 The length of either part may be zero; that is, any given block may 481 be designated entirely red (retransmission continues until reception 482 of the entire block has been asserted by the receiver) or entirely 483 green (no part of the block is acknowledged or retransmitted). Thus 484 LTP can provide both TCP-like and UDP-like functionality concurrently 485 on a single association. 487 Note that in a red-green block transmission, the red-part data does 488 NOT convey any urgency or higher-priority semantics relative to the 489 block's green-part data; the red-part data is merely intended to 490 carry imperative meta-data without which green-part data reception is 491 likely to be futile. 493 3.4 Laconic Acknowledgment 495 Another respect in which LTP differs from TCP is that, while TCP 496 connections are bidirectional (blocks of application data may be 497 flowing in both directions on any single connection), LTP sessions 498 are unidirectional. This design decision derives from the fact that 499 the flow of data in deep space flight missions is usually 500 unidirectional. (Long round trip times make interactive spacecraft 501 operation infeasible, so spacecraft are largely autonomous and 502 command traffic is very light.) 504 One could imagine an LTP instance, upon being asked to transmit a 505 block of data, searching through all existing sessions in hopes of 506 finding one that was established upon reception of data from the new 507 block's destination; transmission of the new block could be 508 piggybacked on the acknowledgment traffic for that session. But the 509 prevailing unidirectionality of space data communications means that 510 such a search would frequently fail and a new unidirectional session 511 would have to be established anyway. Session bidirectionality 512 therefore seemed to entail somewhat greater complexity unmitigated by 513 any clear performance advantage, so we abandoned it. Bidirectional 514 data transfer is instead accomplished by opening two individual LTP 515 sessions. 517 Since they are not piggybacked on data segments, LTP data 518 acknowledgments - "reception reports" - are carried in a separate 519 segment type. To minimize consumption of low and asymmetric 520 transmission bandwidth in the IPN, these report segments are sent 521 infrequently; each one contains a comprehensive report of all data 522 received within some specified range of offsets from the start of the 523 transmitted block. The expectation is that most data segments will 524 arrive safely, so individual acknowledgment of each one would be 525 expensive in information-theoretical terms: the real information 526 provided per byte of acknowledgment data transmitted would be very 527 small. Instead, report segments are normally sent only upon 528 encountering explicit solicitations for reception reports - 529 "checkpoints" - in the sequence of incoming data segments. 531 The aggregate nature of reception reports gives LTP transmission an 532 episodic character: 534 o "Original transmissions" are sequences of data segments issued 535 in response to transmission requests from client services. 537 o "Retransmissions" are sequences of data segments issued in 538 response to the arrival of report segments that indicate 539 incomplete reception. 541 Checkpoints are mandatory only at the end of the red-part of each 542 original transmission and at the end of each retransmission. For 543 applications that require accelerated retransmission (and can afford 544 the additional bandwidth consumption entailed), reception reporting 545 can be more aggressive. Additional checkpoints may optionally be 546 inserted at other points in the red-part of an original transmission, 547 and additional reception reports may optionally be sent on an 548 asynchronous basis during reception of the red-part of an original 549 transmission. 551 3.5 Adjacency 553 TCP reliability is "end to end": traffic between two TCP endpoints 554 may traverse any number of intermediate network nodes, and two 555 successively transmitted segments may travel by entirely different 556 routes to reach the same destination. The underlying IP network- 557 layer protocol accomplishes this routing. Although TCP always 558 delivers data segments to any single port in order and without gaps, 559 the IP datagrams delivered to TCP itself may not arrive in the order 560 in which they were transmitted. 562 In contrast, LTP is a protocol for "point to point" reliability on a 563 single link: traffic between two LTP engines is expected not to 564 traverse any intermediate relays. Point-to-point topology is innate 565 in the nature of deep space communication, which is simply the 566 exchange of radiation between two mutually visible antennae. No 567 underlying network infrastructure is presumed, so no underlying 568 network-layer protocol activity is expected; the underlying 569 communication service is assumed to be a point-to-point link-layer 570 protocol such as CCSDS Telemetry/Telecommand [TM][TC] (or, for 571 terrestrial applications, PPP). The contents of link-layer frames 572 delivered to LTP are always expected to arrive in the order in which 573 they were transmitted, though possibly with any number of gaps due to 574 data loss or corruption. 576 Note that building an interplanetary network infrastructure - the 577 DTN-based architecture of the IPN - *on top of* LTP does not conflict 578 with LTP design principles. Bundling functions as an overlay network 579 protocol, and LTP bears essentially the same relationship to Bundling 580 that a reliable link protocol (for example, the ARQ capabilities of 581 LLC) would bear to IP. 583 The design of LTP relies heavily on this topological premise, in at 584 least two ways: 586 If two successively transmitted segments could travel by 587 materially different routes to reach the same destination, then 588 the assumption of rough determinism in timeout interval 589 computation discussed below would not hold. Our inability to 590 estimate timeout intervals with any accuracy would severely 591 compromise performance; while spurious timeouts cause redundant 592 retransmissions wasting precious bandwidth, overly conservative 593 timeout intervals delay loss recovery. 595 If data arrived at an LTP engine out of transmission order, then 596 the assumptions based on which the rules for reception reporting 597 are designed would no longer hold. A more complex and/or less 598 efficient retransmission mechanism would be needed. 600 3.6 Optimistic and Dynamic Timeout Interval Computation 602 TCP determines timeout intervals by measuring and recording actual 603 round trip times, then applying statistical techniques to recent RTT 604 history to compute a predicted round trip time for each transmitted 605 segment. 607 The problem is at once both simpler and more difficult for LTP: 609 Since multiple sessions can be conducted on any single 610 association, retardation of transmission on any single session 611 while awaiting a timeout need not degrade communication 612 performance on the association as a whole. Timeout intervals that 613 would be intolerably optimistic in TCP don't necessarily degrade 614 LTP's bandwidth utilization. 616 But the reciprocal half-duplex nature of LTP communication makes 617 it infeasible to use statistical analysis of round-trip history as 618 a means of predicting round-trip time. The round-trip time for 619 transmitted segment N could easily be orders of magnitude greater 620 than that for segment N-1 if there happened to be a transient loss 621 of connectivity between the segment transmissions. 623 Since statistics derived from round-trip history cannot safely be 624 used as a predictor of LTP round-trip times, we have to assume that 625 round-trip timing is at least roughly deterministic - i.e., that 626 sufficiently accurate RTT estimates can be computed individually in 627 real time from available information. 629 This computation is performed in two stages: 631 We calculate a first approximation of RTT by simply doubling the 632 known one-way light time to the destination and adding an 633 arbitrary margin for any additional anticipated latency, such as 634 queuing and processing delay at both ends of the transmission. 635 For deep space operations, the margin value is typically a small 636 number of whole seconds. Although such a margin is enormous by 637 Internet standards, it is insignificant compared to the two-way 638 light time component of round-trip time in deep space. We choose 639 to risk tardy retransmission, which will postpone delivery of one 640 block by a relatively tiny increment, in preference to premature 641 retransmission, which will unnecessarily consume precious 642 bandwidth and thereby degrade overall performance. 644 Then, to account for the additional delay imposed by interrupted 645 connectivity, we dynamically suspend timers during periods when 646 the relevant remote LTP engines are known to be unable to transmit 647 responses. This knowledge of the operational state of remote 648 entities is assumed to be provided by link state cues from the 649 operating environment, as discussed earlier. 651 3.7 Deferred Transmission 653 Link state cues also notify LTP when it is and isn't possible to 654 transmit segments by passing them to the underlying communication 655 service. 657 Continuous duplex communication is the norm for TCP operations in the 658 Internet; when communication links are not available, TCP simply does 659 not operate. In deep space communications, however, at no moment can 660 there ever be any expectation of two-way connectivity. It is always 661 possible for LTP to be generating outbound segments - in response to 662 received segments, timeouts, or requests from client services - that 663 cannot immediately be transmitted. These segments must be queued for 664 transmission at a later time when a link has been established, as 665 signaled by a link state cue. 667 4. Overall Operation 669 4.1 Nominal Operation 670 The nominal sequence of events in an LTP transmission session is as 671 follows. 673 Operation begins when a client service instance asks an LTP engine to 674 transmit a block to a remote client service instance. The sending 675 engine opens a Sending State Record (SSR) for a new session, thereby 676 starting the session, and notifies the client service instance that 677 the session has been started. The sending engine then initiates an 678 original transmission: it queues for transmission as many data 679 segments as are necessary to transmit the entire block, within the 680 constraints on maximum segment size imposed by the underlying 681 communication service. The last segment of the red-part of the block 682 is marked as the End of Red-Part (EORP) indicating the end of red- 683 part data for the block, and as a checkpoint indicating that the 684 receiving engine must issue a reception report upon receiving the 685 segment. The last segment of the block overall is marked End of 686 Block (EOB) indicating that the receiving engine can calculate the 687 size of the block by summing the offset and length of the data in the 688 segment. 690 At the next opportunity, subject to allocation of bandwidth to the 691 queue into which the block data segments were written, the enqueued 692 segments are transmitted to the LTP engine serving the remote client 693 service instance. A timer is started for the EORP, so that it can be 694 retransmitted automatically if no response is received. 696 On reception of the first data segment for the block, the receiving 697 engine opens a Receiving State Record (RSR) for the new session and 698 notifies the local instance of the relevant client service that the 699 session has been started. In the nominal case it receives all 700 segments of the original transmission without error. Therefore on 701 reception of the EORP data segment it responds by (a) queuing for 702 transmission to the sending engine a report segment indicating 703 complete reception and (b) delivering the received red-part of the 704 block to the local instance of the client service; on reception of 705 each data segment of the green-part, it responds by immediately 706 delivering the received data to the local instance of the client 707 service. 709 At the next opportunity, the enqueued report segment is immediately 710 transmitted to the sending engine and a timer is started so that the 711 report segment can be retransmitted automatically if no response is 712 received. 714 The sending engine receives the report segment, turns off the timer 715 for the EORP, enqueues for transmission to the receiving engine a 716 report-acknowledgment segment, notifies the local client service 717 instance that the red-part of the block has been successfully 718 transmitted, and closes the SSR for the session. 720 At the next opportunity, the enqueued report-acknowledgment segment 721 is immediately transmitted to the receiving engine. 723 The receiving engine receives the report-acknowledgment segment, 724 turns off the timer for the report segment, and closes the RSR for 725 the session. 727 Closing both the SSR and RSR for a session terminates the session. 729 4.2 Retransmission 731 Loss or corruption of transmitted segments may cause the operation of 732 LTP to deviate from the nominal sequence of events described above. 734 Loss of one or more red-part data segments other than the EORP 735 segment triggers data retransmission: 737 Rather than returning a single reception report indicating complete 738 reception, the receiving engine returns a reception report comprising 739 as many report segments as are needed in order to report in detail on 740 all red-part data reception for this session (other than data 741 reception that was previously reported in response to any 742 discretionary checkpoints, described later), within the constraints 743 on maximum segment size imposed by the underlying communication 744 service. [Still, only one report segment is normally returned; 745 multiple report segments are needed only when a large number of 746 segments comprising non-contiguous intervals of red-part block data 747 are lost or when the receiver-to-sender path MTU is small.] A timer 748 is started for each report segment. 750 On reception of each report segment the sending engine responds as 751 follows : 753 It turns off the timer for the checkpoint referenced by the report 754 segment, if any. 756 It enqueues a reception-acknowledgment segment acknowledging the 757 report segment (to turn off the report retransmission timer at the 758 receiving engine). This segment is sent immediately at the next 759 transmission opportunity. 761 If the reception claims in the report segment indicate that not 762 all data within the scope have been received, it normally 763 initiates a retransmission by enqueuing all data segments not yet 764 received. The last such segment is marked a checkpoint and 765 contains the report serial number of the report segment to which 766 the retransmission is a response. These segments are likewise 767 sent at the next transmission opportunity, but only after all data 768 segments previously queued for transmission to the receiving 769 engine have been sent. A timer is started for the checkpoint, so 770 that it can be retransmitted automatically if no responsive report 771 segment is received. 773 On the other hand, if the reception claims in the report segment 774 indicate that all data within the scope of the report segment have 775 been received, and the union of all reception claims received so 776 far in this session indicate that all data in the red-part of the 777 block have been received, then the sending engine notifies the 778 local client service instance that the red-part of the block has 779 been successfully transmitted and closes the SSR for the session. 781 On reception of a checkpoint segment with a non-zero report serial 782 number, the receiving engine responds as follows : 784 It first turns off the timer for the referenced report segment. 786 It then returns a reception report comprising as many report 787 segments as are needed in order to report in detail on all data 788 reception within the scope of the referenced report segment, 789 within the constraints on maximum segment size imposed by the 790 underlying communication service; a timer is started for each 791 report segment. 793 If at this point all data in the red-part of the block have been 794 received, the receiving engine delivers the received block's red- 795 part to the local instance of the client service and, upon 796 reception of reception-acknowledgment segments acknowledging all 797 report segments, closes the RSR for the session. Otherwise the 798 data retransmission cycle continues. 800 Loss of any checkpoint segment or of the responsive report segment 801 causes the checkpoint timer to expire. When this occurs, the sending 802 engine normally retransmits the checkpoint segment. Similarly, loss 803 of a report segment or of the responsive report-acknowledgment 804 segment causes the report segment's timer to expire. When this 805 occurs, the receiving engine normally retransmits the report segment. 807 Note that reception of a previously received report segment that was 808 retransmitted due to loss of the report-acknowledgment segment causes 809 another responsive report-acknowledgment segment to be transmitted, 810 but is otherwise ignored; if any of the data retransmitted in 811 response to the previously received report segment were lost, further 812 retransmission of those data will be requested by one or more new 813 report segments issued in response to that earlier retransmission's 814 checkpoint. Thus unnecessary retransmission is suppressed. 816 Note also that the responsibility for responding to segment loss in 817 LTP is shared between the sender and receiver of a block: the sender 818 retransmits checkpoint segments in response to checkpoint timeouts, 819 and it retransmits missing data in response to reception reports 820 indicating incomplete reception, while the receiver additionally 821 retransmits report segments in response to timeouts. An alternative 822 design would have been to make the sender responsible for all 823 retransmission, in which case the receiver would not expect report- 824 acknowledgment segments and would not retransmit report segments. 825 There are two disadvantages to this approach: 827 First, because of constraints on segment size that might be 828 imposed by the underlying communication service, it is at least 829 remotely possible that the response to any single checkpoint might 830 be multiple report segments. An additional sender-side mechanism 831 for detecting and appropriately responding to the loss of some 832 proper subset of those reception reports would be needed. We 833 believe the current design is simpler. 835 Second, an engine that receives a block needs a way to determine 836 when the session can be closed. In the absence of explicit final 837 report acknowledgment (which entails retransmission of the report 838 in case of the loss of the report acknowledgment), the 839 alternatives are (a) to close the session immediately on 840 transmission of the report segment that signifies complete 841 reception and (b) to close the session on receipt of an explicit 842 authorization from the sender. In case (a), loss of the final 843 report segment would cause retransmission of a checkpoint by the 844 sender, but the session would no longer exist at the time the 845 retransmitted checkpoint arrived; the checkpoint could reasonably 846 be interpreted as the first data segment of a new block, most of 847 which was lost in transit, and the result would be redundant 848 retransmission of the entire block. In case (b), the explicit 849 session termination segment and the responsive acknowledgment by 850 the receiver (needed in order to turn off the timer for the 851 termination segment, which in turn would be needed in case of in- 852 transit loss or corruption of that segment) would somewhat 853 complicate the protocol, increase bandwidth consumption, and 854 retard the release of session state resources at the sender. Here 855 again we believe that the current design is simpler and more 856 efficient. 858 4.3 Accelerated Retransmission 860 Data segment retransmission occurs only on receipt of a report 861 segment indicating incomplete reception; report segments are normally 862 transmitted only at the end of original transmission of the red-part 863 of a block or at the end of a retransmission. For some applications 864 it may be desirable to trigger data segment retransmission 865 incrementally during the course of red-part original transmission so 866 that the missing segments are recovered sooner. This can be 867 accomplished in two ways: 869 Any red-part data segment prior to the EORP can additionally be 870 flagged as a checkpoint. Reception of each such "discretionary" 871 checkpoint causes the receiving engine to issue a reception 872 report. 874 At any time during the original transmission of a block's red-part 875 (that is, prior to reception of any data segment of the block's 876 green-part), the receiving engine can unilaterally issue 877 additional asynchronous reception reports. Note that the CFDP 878 protocol's "Immediate" mode is an example of this sort of 879 asynchronous reception reporting [Sec 6]. The reception reports 880 generated for accelerated retransmission are processed in exactly 881 the same way as the standard reception reports. 883 4.4 Session Cancellation 885 A transmission session may be canceled by either the sending or the 886 receiving engine in response either to a request from the local 887 client service instance or to an LTP operational failure as noted 888 earlier. Session cancellation is accomplished as follows. 890 The canceling engine deletes all currently queued segments for the 891 session and notifies the local instance of the affected client 892 service that the session is canceled. If no segments for this 893 session have yet been sent to or received from the corresponding LTP 894 engine, then at this point the canceling engine simply closes its 895 state record for the session and cancellation is complete. 897 Otherwise, a session cancellation segment is queued for transmission. 898 At the next opportunity, the enqueued cancellation segment is 899 immediately transmitted to the LTP engine serving the remote client 900 service instance. A timer is started for the segment, so that it can 901 be retransmitted automatically if no response is received. 903 The corresponding engine receives the cancellation segment, enqueues 904 for transmission to the canceling engine a cancellation- 905 acknowledgment segment, deletes all other currently queued segments 906 for the indicated session, notifies the local client service instance 907 that the block has been canceled, and closes its state record for the 908 session. 910 At the next opportunity, the enqueued cancellation-acknowledgment 911 segment is immediately transmitted to the canceling engine. 913 The canceling engine receives the cancellation-acknowledgment, turns 914 off the timer for the cancellation segment, and closes its state 915 record for the session. 917 Loss of a cancellation segment or of the responsive cancellation- 918 acknowledgment causes the cancellation segment timer to expire. When 919 this occurs, the canceling engine normally retransmits the 920 cancellation segment. 922 5. Functional Model 924 The functional model underlying the specification of LTP is one of 925 deferred, opportunistic transmission, with access to the active 926 transmission link apportioned between two (conceptual) outbound 927 traffic queues. The accuracy of LTP retransmission timers depend in 928 large part on a faithful adherence to this model. 930 5.1 Deferred Transmission 932 In concept, every outbound LTP segment is appended to one of two 933 queues -- forming a "queue set" -- of traffic bound for the LTP 934 engine that is that segment's destination. One such traffic queue is 935 the "internal operations queue" of that queue set; the other is the 936 application data queue for the queue set. The de-queuing of a 937 segment always implies delivering it to the underlying communication 938 system for immediate transmission. Whenever the internal operations 939 queue is non-empty, the oldest segment in that queue is the next 940 segment de-queued for transmission to the destination; at all other 941 times, the oldest segment in the application data queue is the next 942 segment de-queued for transmission to the destination. 944 The production and enqueuing of a segment and the subsequent actual 945 transmission of that segment are in principle wholly asynchronous. 947 In the event that (a) a transmission link to the destination is 948 currently active and (b) the queue to which a given outbound segment 949 is appended is otherwise empty and (c) either this queue is the 950 internal operations queue or else the internal operations queue is 951 empty, the segment will be transmitted immediately upon production. 952 Transmission of a newly queued segment is necessarily deferred in all 953 other circumstances. 955 Conceptually, the de-queuing of segments from traffic queues bound 956 for a given destination is initiated upon reception of a link state 957 cue indicating that the underlying communication system is now 958 transmitting to that destination, i.e., the link to that destination 959 is now active. It ceases upon reception of a link state cue 960 indicating that the underlying communication system is no longer 961 transmitting to that destination, i.e., the link to that destination 962 is no longer active. 964 5.2 Timers 966 LTP relies on accurate calculation of expected arrival times for 967 report and acknowledgment segments in order to know when proactive 968 retransmission is required. If a calculated time were even slightly 969 early, the result would be costly unnecessary retransmission. On the 970 other hand, calculated arrival times may safely be several seconds 971 late: the only penalties for late timeout and retransmission are 972 slightly delayed data delivery and slightly delayed release of 973 session resources. 975 The following discussion is the basis for LTP's expected arrival time 976 calculations. 978 The total time consumed in a single "round trip" (transmission and 979 reception of the original segment, followed by transmission and 980 reception of the acknowledging segment) has the following components: 982 Protocol processing time: The time consumed in issuing the 983 original segment, receiving the original segment, generating and 984 issuing the acknowledging segment, and receiving the acknowledging 985 segment. 987 Outbound queuing delay: The delay at the sender of the original 988 segment while that segment is in a queue waiting for transmission, 989 and delay at the sender of the acknowledging segment while that 990 segment is in a queue waiting for transmission. 992 Radiation time: The time that passes while all bits of the 993 original segment are being radiated, and the time that passes 994 while all bits of the acknowledging segment are being radiated. 995 (This is significant only at extremely low data transmission 996 rates.) 998 Round-trip light time: The signal propagation delay at the speed 999 of light, in both directions. 1001 Inbound queuing delay: delay at the receiver of the original 1002 segment while that segment is in a reception queue, and delay at 1003 the receiver of the acknowledging segment while that segment is in 1004 a reception queue. 1006 Delay in transmission of the original segment or the acknowledging 1007 segment due to loss of connectivity - that is, interruption in 1008 outbound link activity at the sender of either segment due to 1009 occultation, scheduled end of tracking pass, etc. 1011 In this context, where errors on the order of seconds or even minutes 1012 may be tolerated, protocol processing time at each end of the session 1013 is assumed to be negligible. 1015 Inbound queuing delay is also assumed to be negligible because, even 1016 on small spacecraft, LTP processing speeds are high compared to data 1017 transmission rates. 1019 Two mechanisms are used to make outbound queuing delay negligible: 1021 The expected arrival time of an acknowledging segment is not 1022 calculated until the moment the underlying communication system 1023 notifies LTP that radiation of the original segment has begun. 1024 All outbound queuing delay for the original segment has already 1025 been incurred at that point. 1027 LTP's deferred transmission model [Sec 5.1] minimizes latency in 1028 the delivery of acknowledging segments (reports and 1029 acknowledgments) to the underlying communication system; that is, 1030 acknowledging segments are (in concept) appended to the internal 1031 operations queue rather than the application data queue, so they 1032 have higher transmission priority than any other outbound 1033 segments, i.e., they should always be de-queued for transmission 1034 first. This limits outbound queuing delay for a given 1035 acknowledging segment to the time needed to de-queue and radiate 1036 all previously generated acknowledging segments that have not yet 1037 been de-queued for transmission. Since acknowledging segments are 1038 sent infrequently and are normally very small, outbound queuing 1039 delay for a given acknowledging segment is likely to be minimal. 1041 Deferring calculation of the expected arrival time of the 1042 acknowledging segment until the moment at which the original segment 1043 is radiated has the additional effect of removing from consideration 1044 any original segment transmission delay due to loss of connectivity 1045 at the original segment sender. 1047 Radiation delay at each end of the session is simply segment size 1048 divided by transmission data rate. It is insignificant except when 1049 data rate is extremely low (for example, 10 bps), in which case the 1050 use of LTP may well be inadvisable for other reasons (LTP header 1051 overhead for example, could be too much under such data rates). 1052 Therefore radiation delay is normally assumed to be negligible. 1054 We assume that one-way light time to the nearest second can always be 1055 known (for example, provided by the operating environment). 1057 So the initial expected arrival time for each acknowledging segment 1058 is typically computed as simply the current time at the moment that 1059 radiation of the original segment begins, plus twice the one-way 1060 light time, plus 2*N seconds of margin to account for processing and 1061 queuing delays and for radiation time at both ends. N is a parameter 1062 set by network management for which 2 seconds seem to be a reasonable 1063 default value. 1065 This leaves only one unknown, the additional round trip time 1066 introduced by loss of connectivity at the sender of the acknowledging 1067 segment. To account for this, we again rely on external link state 1068 cues. Whenever interruption of transmission at a remote LTP engine 1069 is signaled by a link state cue, we suspend the countdown timers for 1070 all acknowledging segments expected from that engine. Upon a signal 1071 that transmission has resumed at that engine, we resume those timers 1072 after (in effect) adding to each expected arrival time the length of 1073 the timer suspension interval. 1075 6. Tracing LTP back to CFDP 1077 LTP in effect implements most of the "core procedures" of the CCSDS 1078 File Delivery Protocol (CFDP) specification, minus flow labels and 1079 all features that are specific to operations on files and filestores 1080 (file systems). In the IPN architecture we expect that file and 1081 filestore operations will be conducted by file transfer application 1082 protocols -- notably CFDP itself -- operating on top of the DTN 1083 Bundling protocol. Bundling's QoS features serve the same purposes 1084 as CFDP's flow labels, so flow labeling is omitted from LTP. 1085 Bundling in effect implements the CFDP "extended procedures" in a 1086 more robust and scalable manner than is prescribed by the CFDP 1087 standard. 1089 The fundamental difference between LTP and CFDP is that, while CFDP 1090 delivers named files end-to-end, LTP is used to transmit arbitrary, 1091 unnamed blocks of data point-to-point. 1093 Some differences between LTP and CFDP are simply matters of 1094 terminology; the following table summarizes the correspondences in 1095 language between the two. 1097 --------------LTP------------- ------------CFDP----------- 1099 LTP engine CFDP entity 1101 Segment Protocol Data Unit (PDU) 1102 Reception Report NAK 1104 Client service request Service request 1106 Client service notice Service indication 1108 CFDP specifies four mechanisms for initiating data retransmission, 1109 called "lost segment detection modes". LTP effectively supports all 1110 four: 1112 "Deferred" mode is implemented in LTP by the Request flag in the 1113 EORP data segment, which triggers reception reporting upon receipt 1114 of the EORP. 1116 "Prompted" mode is implemented in LTP by turning on Request flags 1117 in data segments that precede the EORP; these additional 1118 checkpoints trigger interim reception reporting under the control 1119 of the source LTP engine. 1121 "Asynchronous" mode is implemented in LTP by the autonomous 1122 production, under locally specified conditions, of additional 1123 reception reports prior to arrival of the EORP. 1125 "Immediate" mode is simply a special case of asynchronous mode, 1126 where the condition that triggers autonomous reception reporting 1127 is detection of a gap in the incoming data. 1129 CFDP uses a cyclic timer to iterate reception reporting until 1130 reception is complete. Because choosing a suitable interval for such 1131 a timer is potentially quite difficult, LTP instead flags the last 1132 data segment of each retransmission as a checkpoint, sent reliably; 1133 the cascading reliable transmission of checkpoint and RS segments 1134 assures the continuous progress of the transmission session. 1136 As the following table indicates, most of the functions of CFDP PDUs 1137 are accomplished in some way by LTP segments. 1139 --------------LTP------------- -------------CFDP---------- 1141 Data segments File data and metadata PDUs 1143 Flags on data segments EOF (Complete), Prompt (NAK), 1144 Prompt (Keep Alive) 1146 Report segment ACK (EOF Complete), NAK, 1147 Keep Alive, Finished (Complete) 1149 Report-acknowledgment ACK (Finished Complete) 1150 Cancel segment EOF (Cancel, Protocol Error) 1151 Finished (Cancel, Protocol Error) 1153 Cancellation Acknowledgment ACK (EOF (Cancel, Protocol Error), 1154 Finished (Cancel, Protocol Error)) 1156 But some CFDP PDUs have no LTP equivalent because in an IPN 1157 architecture they will likely be implemented elsewhere. CFDP's EOF 1158 (Filestore error) and Finished (Filestore error) PDUs would be 1159 implemented in an IPN application-layer file transfer protocol, e.g., 1160 CFDP itself. CFDP's Finished [End System] PDU is a feature of the 1161 Extended Procedures, which would in effect be implemented by the 1162 Bundling protocol. 1164 7. Security Considerations 1166 Not relevant for this document. 1168 8. IANA Considerations 1170 Not relevant for this document. Please follow the IANA Considerations 1171 sections of the internet-drafts on the series (main protocol 1172 specification and protocol extensions). 1174 9. Acknowledgments 1176 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 1177 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for 1178 their thoughts on this protocol and its role in Delay-Tolerant 1179 Networking architecture. 1181 Part of the research described in this document was carried out at 1182 the Jet Propulsion laboratory, California Institute of Technology, 1183 under a contract with the National Aeronautics and Space 1184 Administration. This work was performed under DOD Contract DAA-B07- 1185 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; 1186 and NASA Contract NAS7-1407. 1188 Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers 1189 at Ohio University for their suggestions and advice in making various 1190 design decisions. 1192 Part of this work was carried out at Trinity College Dublin as part 1193 of the SeNDT contract funded by Enterprise Ireland's research 1194 innovation fund. 1196 10. References 1197 10.1 Normative References 1199 [B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1200 Levels", BCP 14, RFC 2119, March 1997. 1202 [LTP] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 1203 Transmission Protocol - Specification", draft-irtf-dtnrg-ltp-03.txt 1204 (Work in Progress), July 2005. 1206 [LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider 1207 Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp- 1208 extensions-01.txt (Work in Progress), July 2005. 1210 10.2 Informative References 1212 [BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification", Work 1213 in Progress, October 2003. 1215 [CCSDS] Consultative Committee for Space Data Systems web page, 1216 "http://www.ccsds.org". 1218 [CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for Space 1219 Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1, October 1220 2002. 1222 [DSN] Deep Space Mission Systems Telecommunications Link Design 1223 Handbook (810-005) web-page, 1224 "http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/" 1226 [DTN] K. Fall, "A Delay-Tolerant Network Architecture for Challenged 1227 Internets", In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, 1228 Aug 2003. 1230 [IPN] InterPlanetary Internet Special Interest Group web page, 1231 "http://www.ipnsig.org". 1233 [TFRC] M. Handley, S. Floyd, J. Padhye, and J. Widmer, "TCP Friendly 1234 Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003. 1236 [TM] Packet Telemetry Specification. Recommendation for Space Data 1237 System Standards, CCSDS 103.0-B-2 BLUE BOOK Issue 2, June 2001. 1239 [TC] Telecommand Part 2 - Data Routing Service. Recommendation for 1240 Space Data System Standards, CCSDS 202.0-B-3 BLUE BOOK Issue 3, June 1241 2001. 1243 [ECS94] D. Eastlake, S. Crocker, and J. Schiller, "Randomness 1244 Recommendations for Security", RFC 1750, December 1994. 1246 [SCTP] R. Stewart et al, "Stream Control Transmission Protocol", RFC 1247 2960, October 2000. 1249 11. Author's Addresses 1251 Scott C. Burleigh 1252 Jet Propulsion Laboratory 1253 4800 Oak Grove Drive 1254 M/S: 179-206 1255 Pasadena, CA 91109-8099 1256 Telephone +1 (818) 393-3353 1257 FAX +1 (818) 354-1075 1258 Email Scott.Burleigh@jpl.nasa.gov 1260 Manikantan Ramadas 1261 Internetworking Research Group 1262 301 Stocker Center 1263 Ohio University 1264 Athens, OH 45701 1265 Telephone +1 (740) 593-1562 1266 Email mramadas@irg.cs.ohiou.edu 1268 Stephen Farrell 1269 Distributed Systems Group 1270 Computer Science Department 1271 Trinity College Dublin 1272 Ireland 1273 Telephone +353-1-608-3070 1274 Email stephen.farrell@cs.tcd.ie 1276 Intellectual Property Statement 1278 The IETF takes no position regarding the validity or scope of any 1279 Intellectual Property Rights or other rights that might be claimed to 1280 pertain to the implementation or use of the technology described in 1281 this document or the extent to which any license under such rights 1282 might or might not be available; nor does it represent that it has 1283 made any independent effort to identify any such rights. Information 1284 on the procedures with respect to rights in RFC documents can be 1285 found in BCP 78 and BCP 79. 1287 Copies of IPR disclosures made to the IETF Secretariat and any 1288 assurances of licenses to be made available, or the result of an 1289 attempt made to obtain a general license or permission for the use of 1290 such proprietary rights by implementers or users of this 1291 specification can be obtained from the IETF on-line IPR repository at 1292 http://www.ietf.org/ipr. 1294 The IETF invites any interested party to bring to its attention any 1295 copyrights, patents or patent applications, or other proprietary 1296 rights that may cover technology that may be required to implement 1297 this standard. Please address the information to the IETF at 1298 ietf-ipr@ietf.org. 1300 Disclaimer of Validity 1302 This document and the information contained herein are provided on an 1303 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1304 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1305 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1306 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1307 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1308 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1310 Copyright Statement 1312 Copyright (C) The Internet Society (2006). This document is subject 1313 to the rights, licenses and restrictions contained in BCP 78, and 1314 except as set forth therein, the authors retain all their rights. 1316 Acknowledgment 1318 Funding for the RFC Editor function is currently provided by the 1319 Internet Society.