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