idnits 2.17.1 draft-irtf-dtnrg-ltp-motivation-04.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, updated by RFC 4748 on line 1292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1282. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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: Informational ---------------------------------------------------------------------------- == Unused Reference: 'B97' is defined on line 1177, but no explicit reference was found in the text == Unused Reference: 'IPN' is defined on line 1215, but no explicit reference was found in the text == Unused Reference: 'ECS94' is defined on line 1228, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-06 -- No information found for draft-irtf-dtnrg-ltp-extensions-05x - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-spec-08 -- 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: 2 errors (**), 0 flaws (~~), 6 warnings (==), 12 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 Intended Status: Informational M. Ramadas 5 Ohio University 6 April 2007 S. Farrell 7 Expires October 2007 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 October 1, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 Bundle protocol, 52 LTP is intended to serve as a reliable convergence layer over single 53 hop deep-space RF links. LTP does ARQ of data transmissions by 54 soliciting selective-acknowledgment reception reports. It is 55 stateful and has no negotiation or handshakes. 57 This document is a product of the Delay Tolerant Networking Research 58 Group and has been reviewed by that group. No objections to its 59 publication as an RFC were raised. 61 Table of Contents 63 1. Introduction ................................................. 3 64 2. Motivation ................................................... 4 65 2.1 IPN Operating Environment ................................ 4 66 2.2 Why not Standard Internet Protocols? ..................... 6 67 3. Features ..................................................... 7 68 3.1 Massive State Retention .................................. 8 69 3.1.1 Multiplicity of Protocol State Machines ............. 8 70 3.1.2 Session IDs ......................................... 9 71 3.2 Absence of Negotiation ................................... 9 72 3.3 Partial Reliability ...................................... 10 73 3.4 Laconic Acknowledgment ................................... 11 74 3.5 Adjacency ................................................ 12 75 3.6 Optimistic and Dynamic Timeout Interval Computation ...... 13 76 3.7 Deferred Transmission .................................... 14 77 4. Overall Operation ............................................ 14 78 4.1 Nominal Operation ........................................ 14 79 4.2 Retransmission ........................................... 16 80 4.3 Accelerated Retransmission ............................... 18 81 4.4 Session Cancellation ..................................... 19 82 5. Functional Model ............................................. 20 83 5.1 Deferred Transmission .................................... 20 84 5.2 Timers ................................................... 20 85 6. Security Considerations ...................................... 25 86 7. IANA Considerations .......................................... 25 87 8. Acknowledgments .............................................. 25 88 9. References ................................................... 25 89 9.1 Normative References ..................................... 25 90 9.2 Informative References ................................... 26 91 10. Author's Addresses ........................................... 26 93 1. Introduction 95 The Licklider Transmission Protocol (LTP) described in this memo is 96 designed to provide retransmission-based reliability over links 97 characterized by extremely long message round-trip times and/or 98 frequent interruptions in connectivity. Communication in 99 interplanetary space is the most prominent example of this sort of 100 environment, and LTP is principally aimed at supporting "long-haul" 101 reliable transmission over deep-space RF links. 103 Since 1982, the principal source of standards for space 104 communications has been the Consultative Committee for Space Data 105 Systems (CCSDS) [CCSDS]. Engineers of CCSDS member agencies have 106 developed communication protocols that function within the 107 constraints imposed by operations in deep space. Among the most 108 prominent of these constraints are: 110 o Extremely long signal propagation delays, on the order of 111 seconds, minutes, or hours rather than milliseconds. 113 o Frequent and lengthy interruptions in connectivity. 115 o Low levels of traffic coupled with high rates of 116 transmission error. 118 o Meager bandwidth and highly asymmetrical data rates. 120 The CCSDS File Delivery Protocol (CFDP) [CFDP], in particular, 121 automates reliable file transfer across interplanetary distances by 122 detecting data loss and initiating the requisite retransmission 123 without mission operator intervention. 125 CFDP by itself is sufficient for operating individual missions, but 126 its built-in networking capabilities are rudimentary. In order to 127 operate within the IPN environment it must rely on the routing and 128 incremental retransmission capabilities of the Bundle protocol [BP] 129 defined for Delay-Tolerant Networks [DTN]. LTP is intended to serve 130 as a reliable "convergence layer" protocol, underlying the Bundle 131 protocol, in DTN deployments where datalinks are characterized by 132 very long round-trip times. Its core design notions are directly 133 descended from the retransmission procedures defined for CFDP. 135 This document describes the motivation for LTP, its features, 136 functions, and overall design. It is part of a series of documents 137 describing LTP. Other documents in the series include the main 138 protocol specification document [LTPSPEC] and the protocol extensions 139 document [LTPEXT] respectively. 141 The protocol is named in honor of ARPA/Internet pioneer JCR 142 Licklider. 144 2. Motivation 146 2.1 IPN Operating Environment 148 There are a number of fundamental differences between the environment 149 for terrestrial communications (such as seen in the Internet) and the 150 operating environments envisioned for the Interplanetary Internet 151 (IPN). 153 The most challenging difference between communication among points on 154 Earth and communication among planets is round-trip delay, of which 155 there are two main sources, both relatively intractable: natural law 156 and economics. 158 The more obvious type of delay imposed by nature is signal 159 propagation time. Our inability to transmit data at speeds higher 160 than the speed of light means that while round-trip times in the 161 terrestrial Internet range from milliseconds to a few seconds, 162 minimum round-trip times to Mars range from 8 to 40 minutes, 163 depending on the planet's position. Round-trip times between Earth 164 and Jupiter's moon Europa run between 66 and 100 minutes. 166 Less obvious and more dynamic is the delay imposed by occultation. 167 Communication between planets must be by radiant transmission, which 168 is usually possible only when the communicating entities are in line 169 of sight of each other. An entity residing on a planetary surface 170 will be periodically taken out of sight by the planet's rotation (it 171 will be "on the other side of" the planet); an entity that orbits a 172 planet will be periodically taken out of sight by orbital motion (it 173 will again be on the other side of the planet); and planets 174 themselves lose mutual visibility when their trajectories take them 175 to opposite sides of the Sun. During the time that communication is 176 impossible, delivery is impaired and messages must wait in a queue 177 for later transmission. 179 Round-trip times and occultations can at least be readily computed 180 given the ephemerides of the communicating entities. Additional 181 delay that is less easily predictable is introduced by discontinuous 182 transmission support, which is rooted in economics. 184 Communicating over interplanetary distances requires expensive 185 special equipment: large antennas, high-performance receivers, etc. 186 For most deep-space missions, even non-NASA ones, these are currently 187 provided by NASA's Deep Space Network (DSN) [DSN]. The communication 188 resources of the DSN are currently oversubscribed and will probably 189 remain so for the foreseeable future. While studies have been done 190 as to the feasibility of upgrading or replacing the current DSN, the 191 number of deep space missions will probably continue to grow faster 192 than the terrestrial infrastructure that supports them, making over- 193 subscription a persistent problem. Radio contact via the DSN must 194 therefore be carefully scheduled and is often severely limited. 196 This over-subscription means that the round-trip times experienced by 197 packets will be affected not only by the signal propagation delay and 198 occultation, but also by the scheduling and queuing delays imposed by 199 the management of Earth-based resources: packets to be sent to a 200 given destination may have to be queued until the next scheduled 201 contact period, which may be hours, days, or even weeks away. While 202 queuing and scheduling delays are generally known well in advance 203 except when missions need emergency service (such as during landings 204 and maneuvers), the long and highly variable delays make the design 205 of timers, retransmission timers in particular, quite difficult. 207 Another significant difference between deep space and terrestrial 208 communication is bandwidth availability. The combined effects of 209 large distances (resulting in signal attenuation), the expense and 210 difficulty of deploying large antennas to distant planets, and the 211 difficulty of generating electric power in space all mean that the 212 available bandwidth for communication in the IPN will likely remain 213 modest compared to terrestrial systems. Maximum data rates on the 214 order of a few tens of megabits per second will probably be the norm 215 for the next few decades. 217 Moreover, the available bandwidths are highly asymmetrical: data are 218 typically transmitted at different rates in different directions on 219 the same link. Current missions are usually designed with a much 220 higher data "return" rate (from spacecraft to Earth) than "command" 221 rate (from Earth to spacecraft). The reason for the asymmetry is 222 simple: nobody ever wanted a high-rate command channel, and, all else 223 being equal, it was deemed better to have a more reliable command 224 channel than a faster one. This design choice has led to data rate 225 asymmetries in excess of 100:1, sometimes approaching 1000:1. A 226 strong desire for a very robust command channel will probably remain, 227 so any transport protocol designed for use in the IPN will need to 228 function with a relatively low-bandwidth outbound channel to 229 spacecraft and landers. 231 The difficulty of generating power on and around other planets will 232 also result in relatively low signal-to-noise ratios and thus high 233 bit error rates. Current deep-space missions operate with raw bit 234 error rates on the order of 10^(-1) to 10^(-3). While heavy coding 235 is used to reduce error rates, the coding overhead further reduces 236 the residual bandwidth available for data transmission. 238 Signal propagation delay is the only truly immutable characteristic 239 that distinguishes the IPN from terrestrial communications. Queuing 240 and scheduling delays, low data rates, intermittent connectivity, and 241 high bit error rates can all be mitigated or eliminated by adding 242 more infrastructure. But this additional infrastructure is likely to 243 be provided (if at all) only in the more highly developed core areas 244 of the IPN. We see the IPN growing outwards from Earth as we explore 245 more and more planets, moons, asteroids, and possibly other stars. 246 This suggests that there will always be a "fringe" to the fabric of 247 the IPN, an area without a rich communications infrastructure. The 248 delay, data rate, connectivity, and error characteristics mentioned 249 above will probably always be an issue somewhere in the IPN. 251 2.2 Why not Standard Internet Protocols? 253 These environmental characteristics - long delays, low and asymmetric 254 bandwidth, intermittent connectivity, and relatively high error rates 255 - make using unmodified TCP for end to end communications in the IPN 256 infeasible. Using the TCP throughput equation from [TFRC] we can 257 calculate the loss event rate (p) required to achieve a given steady- 258 state throughput. Assuming the minimum RTT to Mars from planet Earth 259 is 8 minutes (one-way speed of light delay to Mars at its closest 260 approach to Earth is 4 minutes), assuming a packet size of 1500 261 bytes, assuming that the receiver acknowledges every other packet, 262 and ignoring negligible higher order terms in p (i.e., ignoring the 263 second additive term in the denominator of the TCP throughput 264 equation), we obtain the following table of loss event rates required 265 to achieve various throughput values. 267 Throughput Loss event rate (p) 268 ---------- ------------------- 269 10 Mbps 4.68 * 10^(-12) 270 1 Mbps 4.68 * 10^(-10) 271 100 Kbps 4.68 * 10^(-8) 272 10 Kbps 4.68 * 10^(-6) 274 Note that although multiple losses encountered in a single RTT are 275 treated as a single loss event in the TCP throughput equation [TFRC], 276 such loss event rates are still unrealistic on deep space links. 278 The above values are upper bounds on steady-state throughput. Since 279 the number of packets in an episode of connectivity will generally be 280 under 10,000 due to the low available bandwidth, TCP performance 281 would be dominated by its behavior during slow-start. This means 282 that even when Mars is at its closest approach to Earth it would take 283 a TCP session nearly 100 minutes to ramp up to an Earth-Mars 284 transmission rate of 20kbps. 286 Note: Lab experiments using a channel emulator and standard 287 applications show that even if TCP could be pushed to work 288 efficiently at such distances, many applications either rely on 289 several rounds of handshaking or have built-in timers that render 290 them non-functional when the round-trip-time is over a couple of 291 minutes. For example, it typically takes eight round trips for FTP 292 to get to a state where data can begin flowing. Since an FTP server 293 may time out and reset the connection after 5 minutes of inactivity, 294 a conformant standard FTP server could be unusable for communicating 295 even with the closest planets. 297 The TCP characteristic of establishing a new connection between a 298 pair of peer entities for transferring every new unit of application 299 data is a further obstacle, because the initial three-way handshake 300 procedure of each connection (not to mention the connection slow- 301 start overhead) could in itself be exorbitant in a long delay 302 environment. The SCTP [SCTP] protocol can multiplex "chunks" (units 303 of application data) for multiple sessions over a single layer 304 connection (called an 'association' in SCTP terminology) as LTP does, 305 but it still requires multiple round trips prior to transmitting 306 application data for session setup and so clearly does not suit the 307 needs of the IPN operating environment. 309 3. Features 311 The design of LTP differs from that of TCP in several significant 312 ways. The common themes running through these differences are two 313 central design assumptions, both of which amount to making virtues of 314 necessity. 316 First: given the severe innate constraints on interplanetary 317 communication discussed above, we assume that the computational 318 resources available to LTP engines will always be ample compared to 319 the communication resources available on the link between them. 321 Certainly, in many cases the computational resources available to a 322 given LTP engine - such as one on board a small robotic spacecraft - 323 will not be ample by the standards of the Internet. But in those 324 cases we expect that the associated communication resources 325 (transmitter power, antenna size) will be even less ample, preserving 326 the expected disproportion between the two. 328 Second, we note that establishing a communication link across 329 interplanetary distance entails enacting several hardware 330 configuration measures based on the presumed operational state of the 331 remote communicating entity like: 333 o orienting a directional antenna correctly; 335 o tuning a transponder to pre-selected transmission and/or 336 reception frequencies; 338 o diverting precious electrical power to the transponder at the 339 last possible moment, and for the minimum necessary length of 340 time. 342 We therefore assume that the operating environment in which LTP 343 functions is able to pass information on the link status (termed 344 "link state cues" in this document) to LTP, telling it which remote 345 LTP engine(s) should currently be transmitting to the local LTP 346 engine and vice versa. The operating environment itself must have 347 this information in order to configure communication link hardware 348 correctly. 350 3.1 Massive State Retention 352 Like any reliable transport service employing ARQ (Automatic Repeat 353 reQuests), LTP is "stateful". In order to assure the reception of a 354 block of data it has sent, LTP must retain for possible 355 retransmission all portions of that block which might not have been 356 received yet. In order to do so, it must keep track of which 357 portions of the block are known to have been received so far and 358 which are not, together with any additional information needed for 359 purposes of retransmitting part or all of that block. 361 Long round-trip times mean substantial delay between the transmission 362 of a block of data and the reception of an acknowledgment from the 363 block's destination, signaling arrival of the block. If LTP 364 postponed transmission of additional blocks of data until it received 365 acknowledgment of the arrival of all prior blocks, valuable 366 opportunities to utilize what little deep space transmission 367 bandwidth is available would be forever lost. 369 For this reason, LTP is based in part on a notion of massive state 370 retention. Any number of requested transmissions may be concurrently 371 "in flight" at various displacements along the link between two LTP 372 engines, and the LTP engines must necessarily retain transmission 373 status and retransmission resources for all of them. Moreover, if 374 any of the data of a given block are lost en route, it will be 375 necessary to retain the state of that transmission during an 376 additional round trip while the lost data are retransmitted; even 377 multiple retransmission cycles may be necessary. 379 In sum, LTP transmission state information persists for a long time 380 because a long time must pass before LTP can be assured of 381 transmission success - so LTP must retain a great deal of state 382 information. Since the alternatives are non-reliability on the one 383 hand and severe under-utilization of transmission opportunities on 384 the other, we believe such massive statefulness is cost-justified 385 (though probably not for all LTP applications). 387 3.1.1 Multiplicity of Protocol State Machines 389 This design decision is reflected in a significant structural 390 difference between LTP and TCP. 392 Both TCP and LTP provide mechanisms for multiplexing access by a 393 variety of higher-layer services or applications: LTP's "client 394 service IDs" correspond to TCP's port numbers. Also, both TCP and 395 LTP implement devices for encapsulating threads of retransmission 396 protocol (protocol state machines): LTP's "sessions" functionally 397 correspond to TCP connections. At any moment each such thread of 398 retransmission protocol is engaged in conveying a single block of 399 application data from one protocol end-point to another. 401 However, a single TCP connection (local host address, local port 402 number, foreign host address, foreign port number) can accommodate at 403 most one such thread of retransmission protocol at any one time. In 404 contrast, a single LTP association (local engine ID, local client 405 service ID, foreign engine ID, foreign client service ID) can 406 accommodate multiple concurrent sessions, one for each block of data 407 in transit on the association. 409 3.1.2 Session IDs 411 In TCP, the fact that a single connection maps one-on-one to a single 412 protocol state machine enables the protocol to use host addresses and 413 port numbers to demultiplex arriving data to the appropriate protocol 414 state machine. LTP's possible multiplicity of sessions per 415 association makes it necessary for each segment of application data 416 to include an additional demultiplexing token: a "session ID", that 417 uniquely identifies the session in which the segment was issued and, 418 implicitly, the block of data being conveyed by this session. 420 3.2 Absence of Negotiation 422 In the IPN, round-trip times may be so long and communication 423 opportunities so brief that a negotiation exchange, such as an 424 adjustment of transmission rate, might not be completed before 425 connectivity is lost. Even if connectivity is uninterrupted, waiting 426 for negotiation to complete before revising data transmission 427 parameters might well result in costly under-utilization of link 428 resources. 430 For this reason, LTP communication session parameters are asserted 431 unilaterally, subject to application-level network management 432 activity that may not take effect for hours, days, or weeks. 434 3.3 Partial Reliability 436 For environments where application data is not critical, overall link 437 bandwidth utilization may be improved if the data is transmitted on a 438 "best efforts" basis, i.e., without being subject to acknowledgment 439 and retransmission. However, we believe that for many applications, 440 unreliable transmission of data is likely to be useful only if any 441 application headers/meta-data describing the actual data are received 442 reliably. For example, suppose a block transmission involves a high- 443 definition photograph (which can afford to be sent on "best 444 efforts"): the first 40 bytes of the block might be a prologue 445 containing information such as camera settings and time of exposure, 446 without which the photograph data is useless, while the actual 447 photograph data is an array of fixed-length scan lines. In this case 448 the assured delivery of the first 40 bytes of the block is critical 449 for interpreting the data, but the loss of a few individual scan 450 lines may not be important enough to justify the cost of 451 retransmission. A more typical example would be when the bundle 452 protocol [BP] is the upper-layer protocol operating over LTP: even if 453 a bundle is to be transmitted on "best efforts", it would at least be 454 expected that the bundle protocol headers be received reliably; 455 otherwise the bundle itself would be meaningless to the receiving BP 456 node. 458 The motivation for "partially reliable" transmission, as opposed to 459 an alternative unreliable mode, is therefore to provide a mechanism 460 for upper layer protocols to get their header and meta-data 461 transmitted reliably (as necessary) but have the actual data 462 transmitted unreliably. 464 LTP regards each block of data as comprising two parts: a "red-part", 465 whose delivery must be assured by acknowledgment and retransmission 466 as necessary, and a "green-part" whose delivery is attempted, but not 467 assured. The length of either part may be zero; that is, any given 468 block may be designated entirely red (retransmission continues until 469 reception of the entire block has been asserted by the receiver) or 470 entirely green (no part of the block is acknowledged or 471 retransmitted). Thus LTP can provide both TCP-like and UDP-like 472 functionality concurrently on a single session. 474 Note that in a red-green block transmission, the red-part data does 475 NOT have any urgency or higher-priority semantics relative to the 476 block's green-part data; the red-part data is merely intended as 477 imperative meta-data without which green-part data are likely to be 478 futile. 480 3.4 Laconic Acknowledgment 482 Another respect in which LTP differs from TCP is that, while TCP 483 connections are bidirectional (blocks of application data may be 484 flowing in both directions on any single connection), LTP sessions 485 are unidirectional. This design decision derives from the fact that 486 the flow of data in deep space flight missions is usually 487 unidirectional. (Long round trip times make interactive spacecraft 488 operation infeasible, so spacecraft are largely autonomous and 489 command traffic is very light.) 491 One could imagine an LTP instance, upon being asked to transmit a 492 block of data, searching through all existing sessions in hopes of 493 finding one that was established upon reception of data from the new 494 block's destination; transmission of the new block could be 495 piggybacked on the acknowledgment traffic for that session. But the 496 prevailing unidirectionality of space data communications means that 497 such a search would frequently fail and a new unidirectional session 498 would have to be established anyway. Session bidirectionality 499 therefore seemed to entail somewhat greater complexity unmitigated by 500 any clear performance advantage, so we abandoned it. Bidirectional 501 data transfer is instead accomplished by opening two individual LTP 502 sessions. 504 Since they are not piggybacked on data segments, LTP data 505 acknowledgments - "reception reports" - are carried in a separate 506 segment type. To minimize consumption of low and asymmetric 507 transmission bandwidth in the IPN, these report segments are sent 508 infrequently; each one contains a comprehensive report of all data 509 received within some specified range of offsets from the start of the 510 transmitted block. The expectation is that most data segments will 511 arrive safely, so individual acknowledgment of each one would be 512 expensive in information-theoretical terms: the real information 513 provided per byte of acknowledgment data transmitted would be very 514 small. Instead, report segments are normally sent only upon 515 encountering explicit solicitations for reception reports - 516 "checkpoints" - in the sequence of incoming data segments. 518 The aggregate nature of reception reports gives LTP transmission an 519 episodic character: 521 o "Original transmissions" are sequences of data segments issued 522 in response to transmission requests from client services. 524 o "Retransmissions" are sequences of data segments issued in 525 response to the arrival of report segments that indicate 526 incomplete reception. 528 Checkpoints are mandatory only at the end of the red-part of each 529 original transmission and at the end of each retransmission. For 530 applications that require accelerated retransmission (and can afford 531 the additional bandwidth consumption entailed), reception reporting 532 can be more aggressive. Additional checkpoints may optionally be 533 inserted at other points in the red-part of an original transmission, 534 and additional reception reports may optionally be sent on an 535 asynchronous basis during reception of the red-part of an original 536 transmission. 538 3.5 Adjacency 540 TCP reliability is "end to end": traffic between two TCP endpoints 541 may traverse any number of intermediate network nodes, and two 542 successively transmitted segments may travel by entirely different 543 routes to reach the same destination. The underlying IP network- 544 layer protocol accomplishes this routing. Although TCP always 545 delivers data segments to any single port in order and without gaps, 546 the IP datagrams delivered to TCP itself may not arrive in the order 547 in which they were transmitted. 549 In contrast, LTP is a protocol for "point to point" reliability on a 550 single link: traffic between two LTP engines is expected not to 551 traverse any intermediate relays. Point-to-point topology is innate 552 in the nature of deep space communication, which is simply the 553 exchange of radiation between two mutually visible antennae. No 554 underlying network infrastructure is presumed, so no underlying 555 network-layer protocol activity is expected; the underlying 556 communication service is assumed to be a point-to-point link-layer 557 protocol such as CCSDS Telemetry/Telecommand [TM][TC] (or, for 558 terrestrial applications, PPP). The contents of link-layer frames 559 delivered to LTP are always expected to arrive in the order in which 560 they were transmitted, though possibly with any number of gaps due to 561 data loss or corruption. 563 Note that building an interplanetary network infrastructure - the 564 DTN-based architecture of the IPN - *on top of* LTP does not conflict 565 with LTP design principles. Bundle protocol functions as an overlay 566 network protocol, and LTP bears essentially the same relationship to 567 it as a reliable link protocol (for example, the ARQ capabilities of 568 LLC) bears to IP. 570 The design of LTP relies heavily on this topological premise, in at 571 least two ways: 573 If two successively transmitted segments could travel by 574 materially different routes to reach the same destination, then 575 the assumption of rough determinism in timeout interval 576 computation discussed below would not hold. Our inability to 577 estimate timeout intervals with any accuracy would severely 578 compromise performance; while spurious timeouts cause redundant 579 retransmissions wasting precious bandwidth, overly conservative 580 timeout intervals delay loss recovery. 582 If data arrived at an LTP engine out of transmission order, then 583 the assumptions based on which the rules for reception reporting 584 are designed would no longer hold. A more complex and/or less 585 efficient retransmission mechanism would be needed. 587 3.6 Optimistic and Dynamic Timeout Interval Computation 589 TCP determines timeout intervals by measuring and recording actual 590 round trip times, then applying statistical techniques to recent RTT 591 history to compute a predicted round trip time for each transmitted 592 segment. 594 The problem is at once both simpler and more difficult for LTP: 596 Since multiple sessions can be conducted on any single 597 association, retardation of transmission on any single session 598 while awaiting a timeout need not degrade communication 599 performance on the association as a whole. Timeout intervals that 600 would be intolerably optimistic in TCP don't necessarily degrade 601 LTP's bandwidth utilization. 603 But the reciprocal half-duplex nature of LTP communication makes 604 it infeasible to use statistical analysis of round-trip history as 605 a means of predicting round-trip time. The round-trip time for 606 transmitted segment N could easily be orders of magnitude greater 607 than that for segment N-1 if there happened to be a transient loss 608 of connectivity between the segment transmissions. 610 Since statistics derived from round-trip history cannot safely be 611 used as a predictor of LTP round-trip times, we have to assume that 612 round-trip timing is at least roughly deterministic - i.e., that 613 sufficiently accurate RTT estimates can be computed individually in 614 real time from available information. 616 This computation is performed in two stages: 618 We calculate a first approximation of RTT by simply doubling the 619 known one-way light time to the destination and adding an 620 arbitrary margin for any additional anticipated latency, such as 621 queuing and processing delay at both ends of the transmission. 622 For deep space operations, the margin value is typically a small 623 number of whole seconds. Although such a margin is enormous by 624 Internet standards, it is insignificant compared to the two-way 625 light time component of round-trip time in deep space. We choose 626 to risk tardy retransmission, which will postpone delivery of one 627 block by a relatively tiny increment, in preference to premature 628 retransmission, which will unnecessarily consume precious 629 bandwidth and thereby degrade overall performance. 631 Then, to account for the additional delay imposed by interrupted 632 connectivity, we dynamically suspend timers during periods when 633 the relevant remote LTP engines are known to be unable to transmit 634 responses. This knowledge of the operational state of remote 635 entities is assumed to be provided by link state cues from the 636 operating environment. 638 3.7 Deferred Transmission 640 Link state cues also notify LTP when it is and isn't possible to 641 transmit segments. 643 Continuous duplex communication is the norm for TCP operations in the 644 Internet; when communication links are not available, TCP simply does 645 not operate. In deep space communications, however, at no moment can 646 there ever be any expectation of two-way connectivity. It is always 647 possible for LTP to be generating outbound segments - in response to 648 received segments, timeouts, or requests from client services - that 649 cannot immediately be transmitted. These segments must be queued for 650 transmission at a later time when a link has been established, as 651 signaled by a link state cue. 653 4. Overall Operation 655 4.1 Nominal Operation 657 The nominal sequence of events in an LTP transmission session is as 658 follows. 660 Operation begins when a client service instance asks an LTP engine to 661 transmit a block to a remote client service instance. The sending 662 engine opens a Sending State Record (SSR) for a new session, thereby 663 starting the session, and notifies the client service instance that 664 the session has been started. The sending engine then initiates the 665 original transmission: it queues for transmission as many data 666 segments as are necessary to transmit the entire block, within the 667 constraints on maximum segment size imposed by the underlying 668 communication service. The last segment of the red-part of the block 669 is marked as the End of Red-Part (EORP) indicating the end of red- 670 part data for the block, and as a checkpoint (identified by a unique 671 checkpoint serial number) indicating that the receiving engine must 672 issue a reception report upon receiving the segment. The last 673 segment of the block overall is marked End of Block (EOB) indicating 674 that the receiving engine can calculate the size of the block by 675 summing the offset and length of the data in the segment. 677 At the next opportunity, subject to allocation of bandwidth to the 678 queue into which the block data segments were written, the enqueued 679 segments are transmitted to the LTP engine serving the remote client 680 service instance. A timer is started for the EORP, so that it can be 681 retransmitted automatically if no response is received. 683 On reception of the first data segment for the block, the receiving 684 engine opens a Receiving State Record (RSR) for the new session and 685 notifies the local instance of the relevant client service that the 686 session has been started. In the nominal case it receives all 687 segments of the original transmission without error. Therefore on 688 reception of the EORP data segment it responds by (a) queuing for 689 transmission to the sending engine a report segment indicating 690 complete reception and (b) delivering the received red-part of the 691 block to the local instance of the client service; on reception of 692 each data segment of the green-part, it responds by immediately 693 delivering the received data to the local instance of the client 694 service. 696 At the next opportunity, the enqueued report segment is immediately 697 transmitted to the sending engine and a timer is started so that the 698 report segment can be retransmitted automatically if no response is 699 received. 701 The sending engine receives the report segment, turns off the timer 702 for the EORP, enqueues for transmission to the receiving engine a 703 report-acknowledgment segment, notifies the local client service 704 instance that the red-part of the block has been successfully 705 transmitted, and closes the SSR for the session. 707 At the next opportunity, the enqueued report-acknowledgment segment 708 is immediately transmitted to the receiving engine. 710 The receiving engine receives the report-acknowledgment segment, 711 turns off the timer for the report segment, and closes the RSR for 712 the session. 714 Closing both the SSR and RSR for a session terminates the session. 716 4.2 Retransmission 717 Loss or corruption of transmitted segments may cause the operation of 718 LTP to deviate from the nominal sequence of events described above. 720 Loss of one or more red-part data segments other than the EORP 721 segment triggers data retransmission: the receiving engine returns a 722 reception report detailing all the contiguous ranges of red-part data 723 received (assuming no discretionary checkpoints were received, which 724 are described below). The Reception Report is normally sent in a 725 single Report segment which carries a unique report serial number and 726 the scope of red-part data covered. For example, if the red-part 727 data covered block offsets [0:1000] and all but the segment in range 728 [500:600] were received, the report segment with a unique serial 729 number (say 100) and scope [0:1000] would carry two report entries: 730 (0:500) and (600:1000). The maximum size of a report segment, like 731 all LTP segments, is constrained by the datalink MTU; if many non- 732 contiguous segments were lost in a large block transmission and/or 733 the datalink MTU was relatively small, multiple report segments need 734 to be generated. In this case, LTP generates as many report segments 735 as are necessary and splits the scope of red-part data covered across 736 multiple report segments so that each of them may stand on their own. 737 For example, if three report segments are to be generated as part of 738 a reception report covering red-part data in range [0:1,000,000], 739 they could look like this: RS 19, scope [0:300,000], RS 20, scope 740 [300,000:950,000], and RS 21, scope [950,000:1,000,000]. In all 741 cases, a timer is started upon transmission of each report segment of 742 the reception report. 744 On reception of each report segment the sending engine responds as 745 follows: 747 It turns off the timer for the checkpoint referenced by the report 748 segment, if any. 750 It enqueues a reception-acknowledgment segment acknowledging the 751 report segment (to turn off the report retransmission timer at the 752 receiving engine). This segment is sent immediately at the next 753 transmission opportunity. 755 If the reception claims in the report segment indicate that not 756 all data within the scope have been received, it normally 757 initiates a retransmission by enqueuing all data segments not yet 758 received. The last such segment is marked as a checkpoint and 759 contains the report serial number of the report segment to which 760 the retransmission is a response. These segments are likewise 761 sent at the next transmission opportunity, but only after all data 762 segments previously queued for transmission to the receiving 763 engine have been sent. A timer is started for the checkpoint, so 764 that it can be retransmitted automatically if no responsive report 765 segment is received. 767 On the other hand, if the reception claims in the report segment 768 indicate that all data within the scope of the report segment have 769 been received, and the union of all reception claims received so 770 far in this session indicates that all data in the red-part of the 771 block have been received, then the sending engine notifies the 772 local client service instance that the red-part of the block has 773 been successfully transmitted and closes the SSR for the session. 775 On reception of a report-acknowledgment segment, the receiver turns 776 off the timer for the referenced report segment. On reception of a 777 checkpoint segment with a non-zero report serial number, the 778 receiving engine responds as follows : 780 It returns a reception report comprising as many report segments 781 as are needed in order to report in detail on all data reception 782 within the scope of the referenced report segment, and a timer is 783 started for each report segment. 785 If at this point all data in the red-part of the block have been 786 received, the receiving engine delivers the received block's red- 787 part to the local instance of the client service and, upon 788 reception of reception-acknowledgment segments acknowledging all 789 report segments, closes the RSR for the session. Otherwise the 790 data retransmission cycle continues. 792 Loss of a checkpoint segment or the report segment generated in 793 response causes timer expiry; when this occurs, the sending engine 794 normally retransmits the checkpoint segment. Similarly, the loss of 795 a report segment or the corresponding report-acknowledgment segment 796 causes the report segment's timer to expire; when this occurs, the 797 receiving engine normally retransmits the report segment. 799 Note that the redundant reception of a report segment (i.e., one that 800 was already received and processed by the sender), retransmitted due 801 to loss of the corresponding report-acknowledgment segment for 802 example, causes another report-acknowledgment segment to be 803 transmitted in response but is otherwise ignored; if any of the data 804 segments retransmitted in response to the original reception of the 805 report segment were lost, further retransmission of those data 806 segments will be requested by the reception report generated in 807 response to the last retransmitted data segment marked as a 808 checkpoint. Thus unnecessary retransmission is suppressed. 810 Note also that the responsibility for responding to segment loss in 811 LTP is shared between the sender and receiver of a block: the sender 812 retransmits checkpoint segments in response to checkpoint timeouts, 813 and retransmits missing data in response to reception reports 814 indicating incomplete reception, while the receiver retransmits 815 report segments in response to timeouts. An alternative design would 816 have been to make the sender responsible for all retransmission, in 817 which case the receiver would not expect report-acknowledgment 818 segments and would not retransmit report segments. There are two 819 disadvantages to this approach: 821 First, because of constraints on segment size that might be 822 imposed by the underlying communication service, it is at least 823 remotely possible that the response to any single checkpoint might 824 be multiple report segments. An additional sender-side mechanism 825 for detecting and appropriately responding to the loss of some 826 proper subset of those reception reports would be needed. We 827 believe that the current design is simpler. 829 Second, an engine that receives a block needs a way to determine 830 when the session can be closed. In the absence of explicit final 831 report acknowledgment (which entails retransmission of the report 832 in case of the loss of the report acknowledgment), the 833 alternatives are (a) to close the session immediately on 834 transmission of the report segment that signifies complete 835 reception and (b) to close the session on receipt of an explicit 836 authorization from the sender. In case (a), loss of the final 837 report segment would cause retransmission of a checkpoint by the 838 sender, but the session would no longer exist at the time the 839 retransmitted checkpoint arrived; the checkpoint could reasonably 840 be interpreted as the first data segment of a new block, most of 841 which was lost in transit, and the result would be redundant 842 retransmission of the entire block. In case (b), the explicit 843 session termination segment and the responsive acknowledgment by 844 the receiver (needed in order to turn off the timer for the 845 termination segment, which in turn would be needed in case of in- 846 transit loss or corruption of the termination segment) would 847 somewhat complicate the protocol, increase bandwidth consumption, 848 and retard the release of session state resources at the sender. 849 Here again we believe that the current design is simpler and more 850 efficient. 852 4.3 Accelerated Retransmission 854 Data segment retransmission occurs only on receipt of a report 855 segment indicating incomplete reception; report segments are normally 856 transmitted only at the end of original transmission of the red-part 857 of a block or at the end of a retransmission. For some applications 858 it may be desirable to trigger data segment retransmission 859 incrementally during the course of red-part original transmission so 860 that the missing segments are recovered sooner. This can be 861 accomplished in two ways: 863 Any red-part data segment prior to the EORP can additionally be 864 flagged as a checkpoint. Reception of each such "discretionary" 865 checkpoint causes the receiving engine to issue a reception 866 report. 868 At any time during the original transmission of a block's red-part 869 (that is, prior to reception of any data segment of the block's 870 green-part), the receiving engine can unilaterally issue 871 additional asynchronous reception reports. Note that the CFDP 872 protocol's "Immediate" mode is an example of this sort of 873 asynchronous reception reporting. The reception reports generated 874 for accelerated retransmission are processed in exactly the same 875 way as the standard reception reports. 877 4.4 Session Cancellation 879 A transmission session may be canceled by either the sending or the 880 receiving engine in response either to a request from the local 881 client service instance or to an LTP operational failure as noted 882 earlier. Session cancellation is accomplished as follows. 884 The canceling engine deletes all currently queued segments for the 885 session and notifies the local instance of the affected client 886 service that the session is canceled. If no segments for this 887 session have yet been sent to or received from the corresponding LTP 888 engine, then at this point the canceling engine simply closes its 889 state record for the session and cancellation is complete. 891 Otherwise, a session cancellation segment is queued for transmission. 892 At the next opportunity, the enqueued cancellation segment is 893 immediately transmitted to the LTP engine serving the remote client 894 service instance. A timer is started for the segment, so that it can 895 be retransmitted automatically if no response is received. 897 The corresponding engine receives the cancellation segment, enqueues 898 for transmission to the canceling engine a cancellation- 899 acknowledgment segment, deletes all other currently queued segments 900 for the indicated session, notifies the local client service instance 901 that the block has been canceled, and closes its state record for the 902 session. 904 At the next opportunity, the enqueued cancellation-acknowledgment 905 segment is immediately transmitted to the canceling engine. 907 The canceling engine receives the cancellation-acknowledgment, turns 908 off the timer for the cancellation segment, and closes its state 909 record for the session. 911 Loss of a cancellation segment or of the responsive cancellation- 912 acknowledgment causes the cancellation segment timer to expire. When 913 this occurs, the canceling engine normally retransmits the 914 cancellation segment. 916 5. Functional Model 918 The functional model underlying the specification of LTP is one of 919 deferred, opportunistic transmission, with access to the active 920 transmission link apportioned between two (conceptual) outbound 921 traffic queues. The accuracy of LTP retransmission timers depend in 922 large part on a faithful adherence to this model. 924 5.1 Deferred Transmission 926 In concept, every outbound LTP segment is appended to one of two 927 queues -- forming a queue-set -- of traffic bound for the LTP engine 928 that is that segment's destination. One such traffic queue is the 929 "internal operations queue" of that queue set; the other is the 930 application data queue for the queue set. The de-queuing of a 931 segment always implies delivering it to the underlying communication 932 system for immediate transmission. Whenever the internal operations 933 queue is non-empty, the oldest segment in that queue is the next 934 segment de-queued for transmission to the destination; at all other 935 times, the oldest segment in the application data queue is the next 936 segment de-queued for transmission to the destination. 938 The production and enqueuing of a segment and the subsequent actual 939 transmission of that segment are in principle wholly asynchronous. 941 In the event that (a) a transmission link to the destination is 942 currently active and (b) the queue to which a given outbound segment 943 is appended is otherwise empty and (c) either this queue is the 944 internal operations queue or else the internal operations queue is 945 empty, the segment will be transmitted immediately upon production. 946 Transmission of a newly queued segment is necessarily deferred in all 947 other circumstances. 949 Conceptually, the de-queuing of segments from traffic queues bound 950 for a given destination is initiated upon reception of a link state 951 cue indicating that the underlying communication system is now 952 transmitting to that destination, i.e., the link to that destination 953 is now active. It ceases upon reception of a link state cue 954 indicating that the underlying communication system is no longer 955 transmitting to that destination, i.e., the link to that destination 956 is no longer active. 958 5.2 Timers 960 LTP relies on accurate calculation of expected arrival times for 961 report and acknowledgment segments in order to know when proactive 962 retransmission is required. If a calculated time were even slightly 963 early, the result would be costly unnecessary retransmission. On the 964 other hand, calculated arrival times may safely be several seconds 965 late: the only penalties for late timeout and retransmission are 966 slightly delayed data delivery and slightly delayed release of 967 session resources. 969 The following discussion is the basis for LTP's expected arrival time 970 calculations. 972 The total time consumed in a single "round trip" (transmission and 973 reception of the original segment, followed by transmission and 974 reception of the acknowledging segment) has the following components: 976 Protocol processing time: The time consumed in issuing the 977 original segment, receiving the original segment, generating and 978 issuing the acknowledging segment, and receiving the acknowledging 979 segment. 981 Outbound queuing delay: The delay at the sender of the original 982 segment while that segment is in a queue waiting for transmission, 983 and delay at the sender of the acknowledging segment while that 984 segment is in a queue waiting for transmission. 986 Radiation time: The time that passes while all bits of the 987 original segment are being radiated, and the time that passes 988 while all bits of the acknowledging segment are being radiated. 989 (This is significant only at extremely low data transmission 990 rates.) 992 Round-trip light time: The signal propagation delay at the speed 993 of light, in both directions. 995 Inbound queuing delay: delay at the receiver of the original 996 segment while that segment is in a reception queue, and delay at 997 the receiver of the acknowledging segment while that segment is in 998 a reception queue. 1000 Delay in transmission of the original segment or the acknowledging 1001 segment due to loss of connectivity - that is, interruption in 1002 outbound link activity at the sender of either segment due to 1003 occultation, scheduled end of tracking pass, etc. 1005 In this context, where errors on the order of seconds or even minutes 1006 may be tolerated, protocol processing time at each end of the session 1007 is assumed to be negligible. 1009 Inbound queuing delay is also assumed to be negligible because, even 1010 on small spacecraft, LTP processing speeds are high compared to data 1011 transmission rates. 1013 Two mechanisms are used to make outbound queuing delay negligible: 1015 The expected arrival time of an acknowledging segment is not 1016 calculated until the moment the underlying communication system 1017 notifies LTP that radiation of the original segment has begun. 1018 All outbound queuing delay for the original segment has already 1019 been incurred at that point. 1021 LTP's deferred transmission model [Sec 5.1] minimizes latency in 1022 the delivery of acknowledging segments (reports and 1023 acknowledgments) to the underlying communication system; that is, 1024 acknowledging segments are (in concept) appended to the internal 1025 operations queue rather than the application data queue, so they 1026 have higher transmission priority than any other outbound 1027 segments, i.e., they should always be de-queued for transmission 1028 first. This limits outbound queuing delay for a given 1029 acknowledging segment to the time needed to de-queue and radiate 1030 all previously generated acknowledging segments that have not yet 1031 been de-queued for transmission. Since acknowledging segments are 1032 sent infrequently and are normally very small, outbound queuing 1033 delay for a given acknowledging segment is likely to be minimal. 1035 Deferring calculation of the expected arrival time of the 1036 acknowledging segment until the moment at which the original segment 1037 is radiated has the additional effect of removing from consideration 1038 any original segment transmission delay due to loss of connectivity 1039 at the original segment sender. 1041 Radiation delay at each end of the session is simply segment size 1042 divided by transmission data rate. It is insignificant except when 1043 data rate is extremely low (for example, 10 bps), in which case the 1044 use of LTP may well be inadvisable for other reasons (LTP header 1045 overhead for example, could be too much under such data rates). 1046 Therefore radiation delay is normally assumed to be negligible. 1048 We assume that one-way light time to the nearest second can always be 1049 known (for example, provided by the operating environment). 1051 So the initial expected arrival time for each acknowledging segment 1052 is typically computed as simply the current time at the moment that 1053 radiation of the original segment begins, plus twice the one-way 1054 light time, plus 2*N seconds of margin to account for processing and 1055 queuing delays and for radiation time at both ends. N is a parameter 1056 set by network management for which 2 seconds seem to be a reasonable 1057 default value. 1059 This leaves only one unknown, the additional round trip time 1060 introduced by loss of connectivity at the sender of the acknowledging 1061 segment. To account for this, we again rely on external link state 1062 cues. Whenever interruption of transmission at a remote LTP engine 1063 is signaled by a link state cue, we suspend the countdown timers for 1064 all acknowledging segments expected from that engine. Upon a signal 1065 that transmission has resumed at that engine, we resume those timers 1066 after (in effect) adding to each expected arrival time the length of 1067 the timer suspension interval. 1069 6. Security Considerations 1071 There is a clear risk that unintended receivers can listen in on LTP 1072 transmissions over satellite and other radio broadcast datalinks. 1073 Such unintended recipients of LTP transmissions may also be able to 1074 manipulate LTP segments at will. 1076 Hence there is a potential requirement for confidentiality, integrity 1077 and anti-DoS (Denial of Service) security services and mechanisms. 1079 In particular, DoS problems are more severe for LTP compared to 1080 typical internet protocols because LTP inherently retains state for 1081 long periods and has very high time-out values. Further, it could be 1082 difficult to reset LTP nodes to recover from an attack. Thus any 1083 adversary who can actively attack an LTP transmission has the 1084 potential to create severe DoS conditions for the LTP receiver. 1086 To give a terrestrial example: were LTP to be used in a sparse sensor 1087 network, DoS attacks could be mounted resulting in nodes missing 1088 critical information, such as communications schedule updates. In 1089 such cases, a single successful DoS attack could take a node entirely 1090 off the network until the node was physically visited and reset. 1092 Even for deep space applications of LTP we need to consider certain 1093 terrestrial attacks, in particular those involving insertion of 1094 messages into an on-going session (usually without having seen the 1095 exact bytes of the previous messages in the session). Such attacks 1096 are likely in the presence of firewall failures at various nodes in 1097 the network, or due to Trojan software running on an authorized host. 1098 Many message insertion attacks will depend on the attacker correctly 1099 "guessing" something about the state of the LTP peers, but experience 1100 shows that successful guesses are easier than might be thought [DDJ]. 1102 We now consider the appropriate layer(s) at which security mechanisms 1103 can be deployed to increase the security properties of LTP, and the 1104 trade-offs entailed in doing so. 1106 The Application layer (above-LTP) 1108 Higher layer security mechanisms clearly protect LTP payload, but 1109 leave LTP headers open. Such mechanisms provide little or no 1110 protection against DoS type attacks against LTP, but may well 1111 provide sufficient data integrity and ought to be able to provide 1112 data confidentiality. 1114 The LTP layer 1116 An authentication header (similar to IPSEC [AH]) can help protect 1117 against replay attacks and other bogus packets. However, an 1118 adversary may still see the LTP header of segments passing by in 1119 the ether. This approach also requires some key management 1120 infrastructure to be in place in order to provide strong 1121 authentication, which may not always be an acceptable overhead. 1122 Such an authentication header could mitigate many DoS attacks. 1124 Similarly, a confidentiality service could be defined for LTP 1125 payload and (some) header fields. However, this seems less 1126 attractive since (a) confidentiality is arguably better provided 1127 either above or below the LTP layer, (b) key management for such a 1128 service is harder (in a high-delay context) than for an integrity 1129 service, and (c) forcing LTP engines to attempt decryption of 1130 incoming segments can in itself provide a DoS opportunity. 1132 Further, within the LTP layer we can make various design decisions 1133 to reduce the probability of successful DoS attacks. In 1134 particular, we can mandate that values for certain fields in the 1135 header (session numbers, for example) be chosen randomly. 1137 The Datalink layer (below-LTP) 1139 The lower layers can clearly provide confidentiality and integrity 1140 services, although such security may result in unnecessary 1141 overhead (if a service provided is not required for all LTP 1142 sessions, for example) and loss of flexibility. However, the lower 1143 layers may well be the optimal place to do compression and 1144 encryption. 1146 7. IANA Considerations 1148 Not relevant for this document. Please follow the IANA Considerations 1149 sections of the internet-drafts on the series [LTPSPEC, LTPEXT]. 1151 8. Acknowledgments 1153 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 1154 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for 1155 their thoughts on this protocol and its role in Delay-Tolerant 1156 Networking architecture. 1158 Part of the research described in this document was carried out at 1159 the Jet Propulsion laboratory, California Institute of Technology, 1160 under a contract with the National Aeronautics and Space 1161 Administration. This work was performed under DOD Contract DAA-B07- 1162 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; 1163 and NASA Contract NAS7-1407. 1165 Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers 1166 at Ohio University for their suggestions and advice in making various 1167 design decisions. 1169 Part of this work was carried out at Trinity College Dublin as part 1170 of the SeNDT contract funded by Enterprise Ireland's research 1171 innovation fund. 1173 9. References 1175 9.1 Normative References 1177 [B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1178 Levels", BCP 14, RFC 2119, March 1997. 1180 [LTPSPEC] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 1181 Transmission Protocol - Specification", draft-irtf-dtnrg-ltp-06.txt 1182 (Work in Progress), April 2007. 1184 [LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider 1185 Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp- 1186 extensions-05x.txt (Work in Progress), April 2007. 1188 9.2 Informative References 1190 [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, 1191 November 1998. 1193 [BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification", 1194 draft-irtf-dtnrg-bundle-spec-08.txt (Work in Progress), December 1195 2006. 1197 [CCSDS] Consultative Committee for Space Data Systems web page, 1198 "http://www.ccsds.org". 1200 [CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for Space 1201 Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1, October 1202 2002. 1204 [DDJ] I. Goldberg and E. Wagner, "Randomness and the Netscape 1205 Browser", Dr. Dobb's Journal, 1996, (pages 66-70). 1207 [DSN] Deep Space Mission Systems Telecommunications Link Design 1208 Handbook (810-005) web-page, 1209 "http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/" 1211 [DTN] K. Fall, "A Delay-Tolerant Network Architecture for Challenged 1212 Internets", In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, 1213 Aug 2003. 1215 [IPN] InterPlanetary Internet Special Interest Group web page, 1216 "http://www.ipnsig.org". 1218 [TFRC] M. Handley, S. Floyd, J. Padhye, and J. Widmer, "TCP Friendly 1219 Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003. 1221 [TM] Packet Telemetry Specification. Recommendation for Space Data 1222 System Standards, CCSDS 103.0-B-2 BLUE BOOK Issue 2, June 2001. 1224 [TC] Telecommand Part 2 - Data Routing Service. Recommendation for 1225 Space Data System Standards, CCSDS 202.0-B-3 BLUE BOOK Issue 3, June 1226 2001. 1228 [ECS94] D. Eastlake, S. Crocker, and J. Schiller, "Randomness 1229 Recommendations for Security", RFC 1750, December 1994. 1231 [SCTP] R. Stewart et al, "Stream Control Transmission Protocol", RFC 1232 2960, October 2000. 1234 10. Author's Addresses 1236 Scott C. Burleigh 1237 Jet Propulsion Laboratory 1238 4800 Oak Grove Drive 1239 M/S: 301-485B 1240 Pasadena, CA 91109-8099 1241 Telephone +1 (818) 393-3353 1242 FAX +1 (818) 354-1075 1243 Email Scott.Burleigh@jpl.nasa.gov 1244 Manikantan Ramadas 1245 Internetworking Research Group 1246 301 Stocker Center 1247 Ohio University 1248 Athens, OH 45701 1249 Telephone +1 (740) 593-1562 1250 Email mramadas@irg.cs.ohiou.edu 1252 Stephen Farrell 1253 Distributed Systems Group 1254 Computer Science Department 1255 Trinity College Dublin 1256 Ireland 1257 Telephone +353-1-896-1761 1258 Email stephen.farrell@cs.tcd.ie 1260 Intellectual Property Statement 1262 The IETF takes no position regarding the validity or scope of any 1263 Intellectual Property Rights or other rights that might be claimed to 1264 pertain to the implementation or use of the technology described in 1265 this document or the extent to which any license under such rights 1266 might or might not be available; nor does it represent that it has 1267 made any independent effort to identify any such rights. Information 1268 on the procedures with respect to rights in RFC documents can be 1269 found in BCP 78 and BCP 79. 1271 Copies of IPR disclosures made to the IETF Secretariat and any 1272 assurances of licenses to be made available, or the result of an 1273 attempt made to obtain a general license or permission for the use of 1274 such proprietary rights by implementers or users of this 1275 specification can be obtained from the IETF on-line IPR repository at 1276 http://www.ietf.org/ipr. 1278 The IETF invites any interested party to bring to its attention any 1279 copyrights, patents or patent applications, or other proprietary 1280 rights that may cover technology that may be required to implement 1281 this standard. Please address the information to the IETF at 1282 ietf-ipr@ietf.org. 1284 Disclaimer of Validity 1286 This document and the information contained herein are provided on an 1287 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1288 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1289 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1290 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1291 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1292 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1294 Copyright Statement 1296 Copyright (C) The IETF Trust (2007). This document is subject 1297 to the rights, licenses and restrictions contained in BCP 78, and 1298 except as set forth therein, the authors retain all their rights. 1300 Acknowledgment 1302 Funding for the RFC Editor function is currently provided by the 1303 Internet Society.