idnits 2.17.00 (12 Aug 2021) /tmp/idnits64942/draft-irtf-dtnrg-ltp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 57 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: 'SDNV-8' is mentioned on line 1721, but not defined == Missing Reference: 'SDNV-16' is mentioned on line 1675, but not defined == Missing Reference: 'AH' is mentioned on line 2432, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IPN' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCSDS' -- Possible downref: Non-RFC (?) normative reference: ref. 'CFDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'BP' -- Possible downref: Non-RFC (?) normative reference: ref. 'DTNRG' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSM97' -- Possible downref: Non-RFC (?) normative reference: ref. 'P97' -- Possible downref: Non-RFC (?) normative reference: ref. 'TM' -- Possible downref: Non-RFC (?) normative reference: ref. 'TC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 1750 (ref. 'ECS94') (Obsoleted by RFC 4086) Summary: 3 errors (**), 0 flaws (~~), 5 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 M. Ramadas 5 May 2004 Ohio University 6 Expires November 2004 S. Farrell 7 Trinity College Dublin 9 Licklider Transmission Protocol 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Discussions on this internet-draft are being made in the Delay 33 Tolerant Networking Research Group (DTNRG) mailing list. More 34 information can be found in the DTNRG web-site at 35 http://www.dtnrg.org 37 Abstract 39 This document describes the Licklider Transmission Protocol (LTP) 40 designed to provide retransmission-based reliability over links 41 characterized by extremely long message round-trip times (RTTs). 42 These long round-trip times may result from the use of half-duplex 43 channels or from data propagation delays that are so lengthy as to 44 simulate half-duplex transmission. Such environments are not well 45 served by TCP, which depends on relatively short round-trip times for 46 retransmission buffer management, timely flow control, and 47 negotiation of other connection parameters. 49 Communication across interplanetary space is the most prominent 50 example of this sort of environment, and LTP is in fact adapted from 51 existing communication technologies designed to support deep space 52 flight missions. It is principally aimed at supporting "long-haul" 53 reliable transmission in the interplanetary space but might have 54 applications in other long-RTT environments as well. 56 Table of Contents 57 1. Introduction ................................................. 3 58 2. Motivation ................................................... 5 59 2.1 IPN Operating Environment ................................ 5 60 2.2 Why not TCP? ............................................. 7 61 3. Features ..................................................... 7 62 3.1 Massively Parallel State Retention ....................... 8 63 3.1.1 Out-of-order Delivery ............................... 9 64 3.1.2 Session IDs ......................................... 10 65 3.1.3 Use of Non-volatile Storage ......................... 11 66 3.2 Absence of Negotiation ................................... 11 67 3.3 Laconic Acknowledgment ................................... 12 68 3.4 Adjacency ................................................ 13 69 3.5 Optimistic and Dynamic Timeout Interval Computation ...... 14 70 3.6 Deferred Transmission .................................... 15 71 4. Terminology .................................................. 15 72 5. Overall Operation ............................................ 19 73 5.1 Nominal Operation ........................................ 19 74 5.2 Retransmission ........................................... 20 75 5.2.1 Reception Reporting Rules ........................... 22 76 5.2.2 Design Rationale .................................... 22 77 5.3 Accelerated Delivery ..................................... 24 78 5.4 Accelerated Retransmission ............................... 24 79 5.5 Session Cancellation ..................................... 25 80 5.6 Unreliable Transmission .................................. 26 81 6. Functional Model ............................................. 26 82 6.1 Deferred Transmission .................................... 27 83 6.2 Bandwidth Management ..................................... 27 84 6.3 Timers ................................................... 28 85 7. Segment Structure ............................................ 30 86 7.1 Segment Header ........................................... 30 87 7.1.1 Segment Type Flags .................................. 31 88 7.1.2 Segment Type Codes .................................. 32 89 7.1.3 Segment Class Masks ................................. 32 90 7.2 Segment Content .......................................... 33 91 7.2.1 Data Segment ........................................ 33 92 7.2.2 Report Segment ...................................... 34 93 7.2.3 Report Acknowledgment Segment ....................... 36 94 7.2.4 Session Management Segments ......................... 36 95 8. Requests from Client Service ................................. 37 96 8.1 Transmission Request ..................................... 37 97 8.2 Cancellation Request ..................................... 38 98 9. Internal Procedures .......................................... 39 99 9.1 Start Transmission ....................................... 39 100 9.2 Start Checkpoint Timer ................................... 40 101 9.3 Start RS Timer ........................................... 40 102 9.4 Stop Transmission ........................................ 40 103 9.5 Suspend Timers ........................................... 40 104 9.6 Resume Timers ............................................ 41 105 9.7 Retransmit Checkpoint .................................... 42 106 9.8 Retransmit RS ............................................ 42 107 9.9 Signify Segment Arrival .................................. 42 108 9.10 Signify Block Reception ................................. 43 109 9.11 Send Reception Report ................................... 43 110 9.12 Signify Transmission Completion ......................... 44 111 9.13 Retransmit Data ......................................... 44 112 9.14 Stop RS Timer ........................................... 45 113 9.15 Start Cancel Timer ...................................... 45 114 9.16 Retransmit Cancellation Segment ......................... 45 115 9.17 Acknowledge Cancellation ................................ 46 116 9.18 Stop Cancellation Timer ................................. 46 117 9.19 Cancel Session .......................................... 47 118 9.20 Close Session ........................................... 47 119 10. Notices to Client Service ................................... 47 120 10.1 Session Start ............................................ 47 121 10.2 Data Segment Arrival ..................................... 47 122 10.3 Block Reception .......................................... 48 123 10.4 Transmission Completion .................................. 48 124 10.5 Transmission Cancellation ................................ 48 125 10.6 Reception Cancellation ................................... 49 126 11. Requirements from the Operating Environment .................. 49 127 12. Security Considerations ...................................... 49 128 12.1 Mechanisms and Layering Considerations ................... 51 129 12.2 Denial of Service Considerations ......................... 52 130 12.3 Authentication header .................................... 53 131 12.4 Implementation Considerations ............................ 53 132 12.5 Miscellaneous ............................................ 54 133 13. Tracing LTP back to CFDP ..................................... 54 134 14. IANA Considerations .......................................... 56 135 15. Acknowledgments .............................................. 56 136 16. References ................................................... 57 137 17. Author's Addresses ........................................... 57 139 1. Introduction 141 The Licklider Transmission Protocol (LTP) described in this memo is 142 designed to provide retransmission-based reliability over links 143 characterized by extremely long message round-trip times. These long 144 round-trip times may result from the use of half-duplex channels or 145 from data propagation delays that are so lengthy as to simulate half- 146 duplex transmission. Such environments are not well served by TCP, 147 which depends on relatively short round-trip times for retransmission 148 buffer management, timely flow control, and negotiation of other 149 connection parameters. 151 As communication across interplanetary space is the most prominent 152 example of this sort of environment, LTP is principally aimed at 153 supporting "long-haul" reliable transmission in the Interplanetary 154 Internet (IPN) [IPN]. 156 Since 1982 the principal source of standards for space communications 157 has been the Consultative Committee for Space Data Systems 158 (CCSDS)[CCSDS]. Engineers of CCSDS member agencies have developed 159 communication protocols that function within the constraints imposed 160 by operations in deep space. These constraints differ sharply from 161 those within which the Internet typically functions: 163 o Extremely long signal propagation delays, on the order of 164 seconds, minutes, or hours rather than milliseconds. 166 o Frequent and lengthy interruptions in connectivity. 168 o Low levels of communication traffic coupled with high rates of 169 transmission error. 171 o Meager bandwidth and highly asymmetrical data rates. 173 The CCSDS File Delivery Protocol (CFDP) [CFDP], in particular, 174 automates reliable file transfer across interplanetary distances by 175 detecting data loss and initiating the requisite retransmission 176 without mission operator intervention. 178 CFDP by itself is sufficient for operating individual missions, but 179 its built-in networking capabilities are rudimentary. In order to 180 operate within the IPN environment it must rely on the routing and 181 incremental retransmission capabilities of the Bundling protocol 182 defined for Delay-Tolerant Networking [BP][DTNRG]. LTP is intended 183 to serve as a reliable "convergence layer" protocol underlying 184 Bundling in DTN regions whose links are characterized by very long 185 round-trip times. Its design notions are directly descended from the 186 retransmission procedures defined for CFDP. 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [B97]. 192 2. Motivation 194 2.1 IPN Operating Environment 196 There are a number of fundamental differences between the environment 197 for terrestrial communications and the operating environments 198 envisioned for the IPN. 200 The most challenging difference between communication among points on 201 Earth and communication among planets is round-trip delay, of which 202 there are two main sources, both relatively intractable: natural law 203 and economics. 205 The more obvious type of delay imposed by nature is signal 206 propagation time. Our inability to transmit data at speeds higher 207 than the speed of light means that, while round-trip times in the 208 terrestrial Internet range from milliseconds to a few seconds, 209 minimum round-trip times to Mars range from 8 to 40 minutes, 210 depending on the planet's position. Round-trip times between Earth 211 and Jupiter's moon Europa run between 66 and 100 minutes. 213 Less obvious and more dynamic is the delay imposed by occultation. 214 Communication between planets must be by radiant transmission, which 215 is usually possible only when the communicating entities are in line 216 of sight of each other. An entity residing on a planetary surface 217 will be periodically taken out of sight by the planet's rotation (it 218 will be "on the other side of" the planet); an entity that orbits a 219 planet will be periodically taken out of sight by orbital motion (it 220 will be "behind" the planet); and planets themselves lose mutual 221 visibility when their trajectories take them to opposite sides of the 222 sun. During the time that communication is impossible, messages must 223 wait in a queue for later transmission. Delivery is necessarily 224 retarded. 226 Round-trip times and occultations can at least be readily computed 227 given the ephemerides of the communicating entities. Additional 228 delay that is less easily predictable is introduced by discontinuous 229 transmission support, which is rooted in economics. 231 Communicating over interplanetary distances requires expensive 232 special equipment: large antennas, high-performance receivers, etc. 233 For most deep-space missions, even non-NASA ones, these are currently 234 provided by NASA's Deep Space Network (DSN). The communication 235 resources of the DSN are currently oversubscribed and will probably 236 remain so for the foreseeable future. While studies have been done 237 as to the feasibility of upgrading or replacing the current DSN, the 238 number of deep space missions will probably continue to grow faster 239 than the terrestrial infrastructure that supports them, making over- 240 subscription a persistent problem. Radio contact via the DSN must 241 therefore be carefully scheduled and is often severely limited. 243 This over-subscription means that the round-trip times experienced by 244 packets will be affected not only by propagation delay and 245 occultation, but also by the scheduling and queuing delays imposed by 246 management of Earth-based resources: packets to be sent to a given 247 destination may have to be queued until the next scheduled contact 248 period, which may be hours, days, or even weeks away. While queuing 249 and scheduling delays are generally known well in advance except when 250 missions need emergency service (such as during landings and 251 maneuvers), the long and highly variable delays make the design of 252 timers, and retransmission timers in particular, quite difficult. 254 Another significant difference between deep space and terrestrial 255 communication is bandwidth availability. The combined effects of 256 large distances (resulting in signal attenuation), the expense and 257 difficulty of deploying large antennas to distant planets, and the 258 difficulty of generating electric power in space all mean that the 259 available bandwidth for communication in the IPN will likely remain 260 modest compared to terrestrial systems. Maximum data rates on the 261 order of a few tens of megabits per second will probably be the norm 262 for the next few decades. 264 Moreover, the available bandwidths are highly asymmetrical: data are 265 typically transmitted at different rates in different directions on 266 the same link. Current missions are usually designed with a much 267 higher data "return" rate (from spacecraft to Earth) than "command" 268 rate (from Earth to spacecraft). The reason for the asymmetry is 269 simple: nobody ever wanted a high-rate command channel, and, all else 270 being equal, it was deemed better to have a more reliable command 271 channel than a faster one. This design choice has led to data rate 272 asymmetries in excess of 100:1, sometimes approaching 1000:1. A 273 strong desire for a very robust command channel will probably remain, 274 so any transport protocol designed for use in the IPN will need to 275 function with a relatively low-bandwidth outbound channel to 276 spacecraft and landers. 278 The difficulty of generating power on and around other planets will 279 also result in relatively low signal-to-noise ratios and thus high 280 bit error rates. Current deep-space missions operate with raw bit 281 error rates on the order of 10^-1, or one error in ten bits; heavy 282 coding is used to reduce these rates, and of course this coding 283 further reduces the residual bandwidth available for data 284 transmission. 286 Propagation delay is the only truly immutable characteristic that 287 distinguishes the IPN from terrestrial communications (unless and 288 until we find a way to transmit information faster than the speed of 289 light). Queuing and scheduling delays, low data rates, intermittent 290 connectivity, and high bit error rates can all be mitigated or 291 eliminated by adding more infrastructure. But this additional 292 infrastructure is likely to be provided (if at all) only in the more 293 highly developed core areas of the IPN. We see the IPN growing 294 outwards from Earth as we explore more and more planets, moons, 295 asteroids, and possibly other stars. This suggests that there will 296 always be a "fringe" to the fabric of the IPN, an area without a rich 297 communications infrastructure. The delay, data rate, connectivity, 298 and error characteristics mentioned above will probably always be an 299 issue somewhere in the IPN. 301 2.2 Why not TCP? 303 These environmental characteristics - long delays, low and asymmetric 304 bandwidth, intermittent connectivity, and relatively high error rate 305 - make using unmodified TCP for end to end communications in the IPN 306 infeasible. Using the equations from Mathis, et al., [MSM97], we can 307 calculate an upper bound on the sustainable throughput of a TCP 308 connection, taking into account TCP's congestion avoidance 309 mechanisms. Even if only 1 in 100 million packets are lost, a TCP 310 connection to Mars is limited to just under 250kbps. If we assume 311 that 1 in 5000 packets is lost (this figure was reported by Paxson as 312 the packet corruption rate in the Internet [P97] then that number 313 falls to around 1,600bps. 315 These values are upper bounds on steady-state throughput. Since the 316 number of packets in an episode of connectivity will generally be 317 under 10,000 due to the low available bandwidth, TCP performance 318 would be dominated by its behavior during slow-start. This means 319 that even when Mars is at its closest approach to Earth it would take 320 a TCP nearly 100 minutes to ramp up to an Earth-Mars transmission 321 rate of 20kbps. 323 Note: lab experiments using a channel emulator and standard 324 applications show that even if TCP could be pushed to work 325 efficiently at such distances, many applications either rely on 326 several rounds of handshaking or have built-in timers that render 327 them non-functional when the round-trip-time is over a couple of 328 minutes. For example, it typically takes eight round trips for FTP 329 to get to a state where data can begin flowing. Since an FTP server 330 may time out and reset the connection after 5 minutes of inactivity, 331 a conformant standard FTP server could be unusable for communicating 332 even with the closest planets. 334 3. Features 335 The design of LTP differs from that of TCP in several significant 336 ways. The common themes running through these differences are two 337 central design assumptions, both of which amount to making virtues of 338 necessity. 340 First: given the severe innate constraints on interplanetary 341 communication discussed above, we assume that the computational 342 resources available to LTP engines will always be ample compared to 343 the communication resources available on the link between them. 345 Certainly in many cases the computational resources available to a 346 given LTP engine - such as one on board a small robotic spacecraft 347 will not be ample by the standards of the Internet. But in those 348 cases we expect that the associated communication resources 349 (transmitter power, antenna size) will be even less ample, preserving 350 the expected disproportion between the two. 352 Second, we note that establishing a communication link across 353 interplanetary distance entails enacting several hardware 354 configuration measures based on the presumed operational state of the 355 remote communicating entity: 357 o orienting a directional antenna correctly; 359 o tuning a transponder to pre-selected transmission and/or 360 reception frequencies; 362 o diverting precious electrical power to the transponder at the 363 last possible moment, and for the minimum necessary length of 364 time. 366 We therefore assume that the operating environment in which LTP 367 functions is able to pass "link state cues" to LTP, telling it which 368 remote LTP engine(s) should currently be transmitting to the local 369 LTP engine and vice versa. The operating environment itself must 370 have this information in order to configure communication link 371 hardware correctly. 373 3.1 Massively Parallel State Retention 375 Like any reliable transport service, LTP is "stateful". In order to 376 assure the reception of a block of data it has sent, LTP must retain 377 for possible retransmission all portions of that block which might 378 not yet have been received. In order to do so, it must keep track of 379 which portions of the block are known to have been received so far, 380 and which are not, together with any additional information needed 381 for purposes of retransmitting part or all of that block. 383 Long round-trip times mean substantial delay between the transmission 384 of a block of data and the reception of an acknowledgment from the 385 block's destination, signaling arrival of the block. If LTP 386 postponed transmission of additional blocks of data until it received 387 acknowledgment of the arrival of all prior blocks, valuable 388 opportunities to utilize what little deep space transmission 389 bandwidth is available would be forever lost. 391 For this reason, LTP is based in part on a notion of massively 392 parallel transmission. 394 Any number of requested transmissions may be concurrently "in flight" 395 at various displacements along the link between two LTP engines, and 396 the LTP engines must necessarily retain transmission status and 397 retransmission resources for all of them. Moreover, if any of the 398 data of a given block are lost en route, it will be necessary to 399 retain the state of that transmission during an additional round trip 400 while the lost data are retransmitted; even multiple retransmission 401 cycles may be necessary. 403 In sum, LTP transmission state information persists for a long time 404 because a long time must pass before LTP can be assured of 405 transmission success - so LTP must retain a great deal of state 406 information. 408 Since the alternatives are non-reliability on the one hand and severe 409 under-utilization of transmission opportunities on the other, we 410 believe such massive statefulness is cost-justified (though probably 411 not in all applications). 413 3.1.1 Out-of-order Delivery 415 This design decision is reflected in a significant structural 416 difference between LTP and TCP. 418 Both TCP and LTP provide mechanisms for multiplexing access by a 419 variety of higher-layer services or applications: LTP's "client 420 service IDs" correspond to TCP's port numbers. Also, both TCP and 421 LTP implement devices for encapsulating threads of retransmission 422 protocol: LTP's "sessions" functionally correspond to TCP 423 connections. At any moment each such thread of retransmission 424 protocol is engaged in conveying some single block of data from one 425 protocol end point to another. 427 But while TCP permits only a single connection on a given port at any 428 time, LTP permits an unlimited number of concurrent sessions for each 429 client service. And just as in TCP the vagaries of retransmission 430 may cause data transmitted on one connection (on one port) to be 431 delivered after data that were subsequently transmitted on another 432 connection (another port), so too in LTP is it possible for data 433 transmitted in one session (for one client service) to be delivered 434 after data that were subsequently transmitted in another session (for 435 another - or possibly the same - client service). 437 In short, while TCP always delivers data in transmission order on a 438 single port, LTP may well deliver data out of transmission order to a 439 single client service. The contrasts may be summarized as follows: 441 ------TCP------ -------LTP------- 443 number of "ports" 65,535 unlimited; normally 1 445 "connections" per "port" 1 unlimited 447 maximum number of 65,535 unlimited 448 concurrent connection 449 state machines 451 blocks transmitted per unlimited 1 452 "connection" (one at a time) 454 Out-of-transmission-order delivery of transmitted blocks to client 455 services averts two serious problems that could be raised by a single 456 "bit hit" - the unrecoverable corruption of a single segment of one 457 block - followed by the successful reception of some number of 458 subsequently transmitted blocks while retransmission of the lost 459 segment is requested and accomplished. 461 First, it ensures that delivery of the successfully received data is 462 not unnecessarily postponed. LTP leaves up to the client service all 463 decisions on what can and cannot be done with this data pending 464 delivery of the undelivered block. [Note that this places on the 465 client services all responsibility for establishing sequence 466 relationships among transmitted blocks, e.g., embedding timestamps 467 and/or sequence numbers within the blocks.] 469 Second, it enables LTP to release resources allocated to the 470 completed sessions' state information as rapidly as possible. This 471 somewhat mitigates the burden of statefulness at the receiving 472 engine. 474 3.1.2 Session IDs 476 In TCP, the delivery of data in transmission order on any single 477 port, without gaps, enables the application that is receiving data on 478 that port to use delivery order as the basis for reconstituting the 479 originally transmitted data items. LTP client services count on LTP 480 to accomplish this reconstitution at the block level, but LTP itself 481 cannot rely on data delivery order being similarly useful for this 482 purpose. LTP instead attaches to each segment of application data 483 the "session ID" that uniquely identifies the original transmission 484 in which the data were issued. Session ID and block offset enable 485 LTP to reassemble the originally transmitted data block from segments 486 of data received out of offset order. 488 Note that, even so, the order of delivery of completed blocks may 489 differ from the order in which the blocks were originally 490 transmitted. Again, attaching the appropriate service-specific 491 semantic significance to each delivered block is a client service 492 responsibility. 494 3.1.3 Use of Non-volatile Storage 496 Another important implication of massive statefulness is that 497 implementations of LTP should consider retaining transmission state 498 information in non-volatile storage of some kind, such as magnetic 499 disk or flash memory. Transport protocols such as TCP typically 500 retain transmission state in dynamic RAM; if the computer on which 501 the software resides is rebooted or powered down, then all 502 transmissions currently in progress are aborted but the resulting 503 degree of communication disruption is limited, because the number of 504 concurrent transmissions is limited. Rebooting or power-cycling a 505 computer on which an LTP engine resides could abort a much larger 506 number of transmission sessions in various stages of completion, at a 507 much larger total cost. 509 3.2 Absence of Negotiation 511 Implicit in the design of TCP is the assumption that the parameters 512 of communication over a given connection can be bilaterally 513 negotiated and renegotiated in a timely manner. Adjustment of 514 transmission rate in particular is accomplished by the exchange of 515 information in real time. 517 In the IPN, however, round-trip times may be so long and 518 communication opportunities so brief that a negotiation exchange 519 might not be completed before connectivity was lost. Even if 520 connectivity were uninterrupted, waiting for negotiation to complete 521 before revising data transmission parameters might well result in 522 costly under-utilization of link resources. 524 For this reason, all LTP communication session parameters are 525 established unilaterally, subject to application-level network 526 management activity that may not take effect for hours, days, or 527 weeks. 529 3.3 Laconic Acknowledgment 531 Another respect in which LTP differs from TCP is that, while TCP 532 connections are bidirectional (blocks of application data may be 533 flowing in both directions on any single connection), LTP sessions 534 are unidirectional. This design decision derives from the possible 535 multiplicity of parallel sessions for any single client service, 536 together with the fact that the flow of data in deep space flight 537 missions is usually unidirectional. (Long round trip times make 538 interactive spacecraft operation infeasible, so spacecraft are 539 largely autonomous and command traffic is very light.) 541 One could imagine an LTP instance, upon being asked to transmit a 542 block of data, searching through all existing sessions in hopes of 543 finding one that was established upon reception of data from the new 544 block's destination; transmission of the new block could be 545 piggybacked on the acknowledgment traffic for that session. But the 546 prevailing unidirectionality of space data communications means that 547 such a search would frequently fail, and a new unidirectional session 548 would have to be established anyway. Session bidirectionality 549 therefore seemed to entail somewhat greater complexity unmitigated by 550 any clear performance advantage, so we abandoned it. Bidirectional 551 data transfer is supported, but it requires opening two individual 552 LTP sessions. 554 Because they are not piggybacked on data segments, LTP data 555 acknowledgments - "reception reports" - are carried in a separate 556 segment type. To minimize consumption of low and asymmetric 557 transmission bandwidth in the IPN, these report segments are sent 558 infrequently; each one contains a comprehensive report of all data 559 received within some specified range of offsets from the start of the 560 transmitted block. The expectation is that most data segments will 561 arrive safely, so individual acknowledgment of each one would be 562 expensive in information-theoretical terms: the real information 563 provided per byte of acknowledgment data transmitted would be very 564 small. Instead, report segments are normally sent only upon 565 encountering explicit solicitations for reception reports - 566 "checkpoints" - in the sequence of incoming data segments. 568 The aggregate nature of reception reports gives LTP transmission an 569 episodic character: 571 o "Original transmissions" are sequences of data segments issued 572 in response to transmission requests from client services. 574 o "Retransmissions" are sequences of data segments issued in 575 response to the arrival of report segments that indicate 576 incomplete reception. 578 Checkpoints are mandatory only at the end of each original 579 transmission or retransmission. For applications that require 580 accelerated retransmission (and can afford the additional bandwidth 581 consumption entailed), reception reporting can be more aggressive. 582 Additional checkpoints may optionally be inserted at other points in 583 an original transmission, and additional reception reports may 584 optionally be sent on an asynchronous basis. 586 3.4 Adjacency 588 TCP reliability is "end to end": traffic between two TCP endpoints 589 may traverse any number of intermediate network nodes, and two 590 successively transmitted segments may travel by entirely different 591 routes to reach the same destination. The underlying IP network- 592 layer protocol accomplishes this routing. Although TCP always 593 delivers data segments to any single port in order and without gaps, 594 the IP datagrams delivered to TCP itself may not arrive in the order 595 in which they were transmitted. 597 In contrast, LTP reliability is "point to point": traffic between two 598 LTP engines is expected not to traverse any intermediate relays. 599 Point-to-point topology is innate in the nature of deep space 600 communication, which is simply the exchange of radiation between two 601 mutually visible antennae. No underlying network infrastructure is 602 presumed, so no underlying network-layer protocol activity is 603 expected; the underlying communication service is assumed to be a 604 point-to-point link-layer protocol such as CCSDS 605 Telemetry/Telecommand [TM][TC] (or, for terrestrial applications, 606 PPP). The contents of link-layer frames delivered to LTP are always 607 expected to arrive in the order in which they were transmitted, 608 though possibly with any number of gaps due to data loss or 609 corruption. 611 Note that building an interplanetary network infrastructure - the 612 DTN-based architecture of the IPN - *on top of* LTP does not conflict 613 with LTP design principles. The Bundling protocol functions at a new 614 hyper-network level, and LTP bears essentially the same relationship 615 to Bundling that a reliable link protocol would bear to IP. The 616 design of LTP relies heavily on this topological premise, in at least 617 two ways: 619 If two successively transmitted segments could travel by materially 620 different routes to reach the same destination, then the assumption 621 of rough determinism in timeout interval computation discussed below 622 would not hold. Our inability to estimate timeout intervals with any 623 accuracy would severely compromise performance. 625 If data arrived at an LTP engine out of transmission order, then the 626 assumptions on which the rules for reception reporting are based 627 would no longer hold. A more complex and/or less efficient 628 retransmission mechanism would be needed. 630 3.5 Optimistic and Dynamic Timeout Interval Computation 632 TCP determines timeout intervals by measuring and recording actual 633 round trip times, then applying statistical techniques to recent RTT 634 history to compute a predicted round trip time for each transmitted 635 segment. 637 The problem is at once both simpler and more difficult for LTP: 639 o The massively parallel nature of LTP changes the granularity at 640 which timer accuracy is required. Confirmation of the reception 641 of one block, or one segment, does not retard transmission of 642 the next, so timeout values that would be intolerably optimistic 643 in TCP don't constrain LTP's bandwidth utilization. 645 o But the reciprocal half-duplex nature of LTP communication makes 646 it infeasible to use statistical analysis of round-trip history 647 as a means of predicting round-trip time. The round-trip time 648 for transmitted segment N could easily be orders of magnitude 649 greater than that for segment N-1. 651 Since statistics derived from round-trip history cannot safely be 652 used as a predictor of LTP round-trip times, we have to assume that 653 round-trip timing is at least roughly deterministic - i.e., that 654 sufficiently accurate RTT estimates can be computed individually in 655 real time from available information. 657 This computation is performed in two stages. 659 We calculate a first approximation of RTT by simply doubling the 660 known one-way light time to the destination and adding an arbitrary 661 margin for possible processing delay at both ends of the 662 transmission. The margin value is typically a small number of whole 663 seconds. Although such a margin is enormous by Internet standards, 664 it is insignificant compared to the two-way light time component of 665 round-trip time in deep space. We choose to risk tardy 666 retransmission, which will postpone delivery of one block by a 667 relatively tiny increment, in preference to premature retransmission, 668 which will unnecessarily consume precious bandwidth and thereby 669 degrade overall performance. 671 Then, to account for the additional delay imposed by interrupted 672 connectivity, we dynamically suspend timers during periods when the 673 relevant remote LTP engines are known to be unable to transmit 674 responses. This knowledge of the operational state of remote 675 entities is assumed to be provided by link state cues from the 676 operating environment, as discussed earlier. 678 3.6 Deferred Transmission 680 Link state cues also notify LTP when it is and isn't possible to 681 transmit segments by passing them to the underlying communication 682 service. 684 Continuous duplex communication is the norm for TCP operations in the 685 Internet; when communication links are not available, TCP simply does 686 not operate. In deep space communications, however, at no moment can 687 there ever be any expectation of two-way connectivity. It is always 688 possible for LTP to be generating outbound segments - in response to 689 received segments, timeouts, or requests from client services - that 690 cannot immediately be transmitted. These segments must be queued for 691 transmission at a later time when a link has been established, as 692 signaled by a link state cue. 694 4. Terminology 696 (1) Engine ID 698 A number that uniquely identifies a given LTP engine, within some 699 closed set of communicating LTP engines. Note that, when LTP is 700 operating underneath the DTN Bundling protocol, the convergence layer 701 adapter mediating between the two will be responsible for translating 702 between DTN endpoint IDs and LTP engine IDs in an implementation- 703 specific manner. 705 (2) Block 707 An array of contiguous octets of application data handed down by the 708 upper layer (typically the bundling layer) to be transmitted via LTP 709 from one client service instance to another. 711 (3) Block Prefix 713 Any subset of a block that begins at the start of the block. 715 (4) Session 717 A thread of LTP protocol activity conducted for the purpose of 718 transmitting a block. 720 (5) Segment 722 The unit of LTP data transmission activity. It is the data structure 723 transmitted from one LTP engine to another in the course of a 724 session. An LTP segment is either a data segment, a report segment, a 725 report-acknowledgment segment, a cancel segment, or a cancel- 726 acknowledgment segment. 728 (6) Scope 730 A subset of a block. Scope comprises two numbers, upper bound and 731 lower bound. 733 For a data segment, lower bound is the offset of the segment's client 734 service data from the start of the block, while upper bound is the 735 sum of the offset and length of the segment's client service data. 736 For example, a segment with block offset 1000 and length 500 would 737 have a lower bound 1000 and upper bound 1500. 739 For a report segment, upper bound is the end of the block prefix to 740 which the reception claims in the report apply, while lower bound is 741 the end of the (smaller) interior block prefix to which the reception 742 claims in the report do *not* apply. That is, data at any offset 743 equal to or greater than the report's lower bound but less than its 744 upper bound, and not designated as "received" by any of the report's 745 reception claims, must be assumed not yet received and therefore 746 eligible for retransmission. For example, if a report segment carried 747 a lower bound of 1000 and an upper bound of 5000, and the reception 748 claims indicated reception of data within offsets 1000-1999 and 749 3000-4999, data within the block offsets 2000-2999 can be considered 750 eligible for retransmission. 752 Reception reports (which may comprise multiple report segments) also 753 have scope, as defined in Section 5.2.1 below. 755 (7) End of Block (EOB) 757 The last data segment transmitted as part of the original 758 transmission of a block. This data segment also indicates that the 759 segment's upper bound is the total length of the block. 761 (8) Checkpoint 763 A data segment soliciting a reception report from the receiving LTP 764 engine. All checkpoints other than the EOB segment that are NOT 765 themselves issued in response to a reception report, are 766 discretionary checkpoints, sent unreliably. The EOB segment and all 767 checkpoints issued in response to reception reports are mandatory 768 checkpoints, sent reliably. 770 (9) Reception Report 772 A sequence of one or more report segments reporting on all block data 773 reception (within some scope) since the start of the block's 774 transmission session. 776 (10) Synchronous Reception Report 778 A reception report that is issued in response to a checkpoint. 780 (11) Asynchronous Reception Report 782 A reception report that is issued in response to some implementation 783 defined event other than the arrival of a checkpoint. 785 (12) Primary Reception Report 787 A reception report that is issued in response to some event other 788 than the arrival of a checkpoint segment that was itself issued in 789 response to a reception report. Primary reception reports include 790 all asynchronous reception reports and all synchronous reception 791 reports that are sent in response to discretionary checkpoints or to 792 the EOB for a session. 794 (13) Secondary Reception Report 796 A reception report that is issued in response to the arrival of a 797 checkpoint segment that was itself issued in response to a reception 798 report. 800 (14) Self-Delimiting Numeric Value (SDNV) 802 The design of LTP attempts to reconcile minimal consumption of 803 transmission bandwidth with 805 (a) extensibility to satisfy requirements not yet identified and 806 (b) scalability across a very wide range of network sizes and 807 transmission payload sizes. 809 A key strategic element in the design is the use of self-delimiting 810 numeric values (SDNVs) that are similar in design to the Abstract 811 Syntax Notation One [ASN1] encoding. An SDNV can be used to encode a 812 variable length number from 1 to 128 bytes long, and is of two basic 813 types, SDNV-8 and SDNV-16. 815 The first octet of an SDNV - the "discriminant" - fully characterizes 816 the SDNV's value. 818 SDNV-8 820 If the first bit of the discriminant is zero, the length of the 821 SDNV-8 is 1 octet and the contents of the remaining 7 bits of the 822 discriminant viewed as an unsigned integer is the value encoded. 823 An integer in the range of 0 to 127 can be encoded this way. 825 Otherwise (if the first bit of the discriminant is 1), the 826 remaining 7 bits encode the length of the encoded number. If the 827 content of the remaining 7 bits viewed as an unsigned integer has 828 the value N, the encoded number is N+1 octets long and has the 829 value found by concatenating octets 2 through N+2 of the SDNV-8, 830 viewed as an unsigned integer. For example, if N were 0, the 831 following single octet would have the value of the SDNV-8; if N 832 were 127, the following 128 octets would have the encoded unsigned 833 number. 835 SDNV-16 837 If the first bit of the discriminant is zero, then the length of 838 the SDNV-16 is 2 octets and the contents of the remaining 7 bits 839 of the discriminant concatenated with the following octet, viewed 840 as a 15-bit unsigned integer, is the value encoded. An integer in 841 the range of 0 to 32767 can be encoded this way. 843 Otherwise (if the first bit of the discriminant is 1), the 844 encoding is similar to SDNV-8. If the content of the remaining 7 845 bits viewed as an unsigned integer has the value N, the encoded 846 number is N+1 octets long, and has the value found by 847 concatenating octets 2 through N+2 of the SDNV-16, viewed as an 848 unsigned integer. 850 An SDNV can therefore be used to represent both very large and very 851 small integer values. For example, the maximum size of an SDNV - a 852 1024-bit number - is large enough to contain a fairly safe encryption 853 key, while any whole-degree Celsius temperature in the range that 854 humans tolerate can be represented in a single-octet SDNV-8. 856 In the LTP header specification that follows, various fields in the 857 header are defined to be of types SDNV-8 or SDNV-16 depending on the 858 typical range of values expected for the field. If a field in the 859 header carries a number that typically requires 16 bits to encode, 860 but under certain infrequent conditions may grow longer and require, 861 say 32 bits to encode, it might be optimal to specify it as an 862 SDNV-16 instead of specifying the field as a fixed 32 bit integer. 864 However, SDNV is clearly not the best way to represent every numeric 865 value. When the maximum possible value of a number is known without 866 question, the cost of an additional 8 bits of discriminant may not be 867 justified. For example, an SDNV-8 is a poor way to represent an 868 integer whose value typically falls in the range 128 to 255. 870 In general, though, we believe that SDNV representation of selected 871 numeric values in LTP segments yields the smallest segment sizes 872 without sacrificing scalability. 874 5. Overall Operation 876 5.1 Nominal Operation 878 The nominal sequence of events in an LTP transmission session is as 879 follows. 881 Operation begins when a client service instance asks an LTP engine to 882 transmit a block to a remote client service instance. The sending 883 engine opens a Sending State Record (SSR) for a new session, thereby 884 starting the session, and it notifies the client service instance 885 that the session has been started. The sending engine then initiates 886 an original transmission: it queues for transmission as many data 887 segments as are necessary to transmit the entire block, within the 888 constraints on maximum segment size imposed by the underlying 889 communication service. The last such segment is marked both as a 890 checkpoint indicating that the receiving engine must issue a 891 reception report upon receving the segment, and as an EOB indicating 892 that the receiving engine can calculate the size of the block by 893 summing the offset and length of the data in the segment. 895 At the next opportunity, subject to allocation of bandwidth to the 896 queue into which the block data segments were written, the enqueued 897 segments are transmitted to the LTP engine serving the remote client 898 service instance. A timer is started for the EOB, so that it can 899 automatically be retransmitted if no response is received. 901 On reception of the first data segment for the block, the receiving 902 engine opens a Receiving State Record (RSR) for the new session, and 903 it notifies the local instance of the relevant client service that 904 the session has been started. In the nominal case it receives all 905 segments of the original transmission without error. Therefore on 906 reception of the EOB data segment it responds by (a) queuing for 907 transmission to the sending engine a report segment indicating 908 complete reception and (b) delivering the received block to the local 909 instance of the client service. 911 At the next opportunity, the enqueued report segment is immediately 912 transmitted to the sending engine and a timer is started so that the 913 report segment can be retransmitted automatically if no response is 914 received. 916 The sending engine receives the report segment, turns off the timer 917 for the EOB, enqueues for transmission to the receiving engine a 918 report-acknowledgment segment, notifies the local client service 919 instance that the block has been successfully transmitted, and closes 920 the SSR for the session. 922 At the next opportunity, the enqueued report-acknowledgment segment 923 is immediately transmitted to the receiving engine. 925 The receiving engine receives the report-acknowledgment segment, 926 turns off the timer for the report segment, and closes the RSR for 927 the session. 929 Closing both the SSR and RSR for a session terminates the session. 931 5.2 Retransmission 933 Loss or corruption of transmitted segments causes the operation of 934 LTP to deviate from the nominal sequence of events described above. 936 Loss of one or more data segments other than the EOB triggers data 937 retransmission: 939 Rather than returning a single reception report indicating complete 940 reception, the receiving engine returns a reception report comprising 941 as many report segments as are needed in order to report in detail on 942 all data reception for this session (other than data reception that 943 was previously reported in response to any discretionary 944 checkpoints), within the constraints on maximum segment size imposed 945 by the underlying communication service. [Still, only one report 946 segment is normally returned; multiple report segments are needed 947 only when a large number of segments comprising non-contiguous 948 intervals of block data are lost.] A timer is started for *each* 949 report segment. 951 On reception of each report segment the sending engine responds as 952 follows: 954 It turns off the timer for the checkpoint referenced by the report 955 segment, if any. 957 It enqueues a reception-acknowledgment segment acknowledging the 958 report segment (to turn off the report retransmission timer at the 959 receiving engine). This segment is sent immediately at the next 960 transmission opportunity. 962 If the reception claims in the report segment indicate that not 963 all data within the scope have been received, it normally 964 initiates a retransmission by re-enqueuing all data segments not 965 yet received. The last such segment is marked a checkpoint and 966 contains the report serial number of the report segment to which 967 the retransmission is a response. These segments are likewise 968 sent at the next transmission opportunity, but subject to 969 allocation of bandwidth to the queue into which the retransmission 970 data segments were written. A timer is started for the 971 checkpoint, so that it can automatically be retransmitted if no 972 responsive report segment is received. 974 However, if the number of checkpoints issued for this session 975 has reached a predefined limit (established by network 976 management), then the receiving engine instead cancels the 977 session as described later. 979 If, on the other hand, the reception claims in the RS indicate 980 that all data within the scope of the RS have been received, and 981 moreover the union of all reception claims received so far in this 982 session indicate that all data in the block have been received, 983 then the sending engine notifies the local client service instance 984 that the block has been successfully transmitted and closes the 985 SSR for the session. 987 On reception of a checkpoint segment with a non-zero report serial 988 number, the receiving engine first turns off the timer for the 989 referenced report segment. Then it returns a reception report 990 comprising as many report segments as are needed in order to report 991 in detail on all data reception within the scope of the referenced 992 report segment, within the constraints on maximum segment size 993 imposed by the underlying communication service; a timer is started 994 for each report segment. If at this point all data in the block have 995 been received, the receiving engine delivers the received block to 996 the local instance of the client service and closes the RSR for the 997 session; otherwise the data retransmission cycle continues. 999 However, if the number of reception reports issued for this 1000 session has reached a predefined limit (established by network 1001 management), then the receiving engine instead cancels the session 1002 as described later. 1004 The detailed rules under which reception reports are produced are 1005 defined in Section 5.2.1 below. 1007 Loss of an EOB or other checkpoint segment, or of the responsive 1008 report segment causes the checkpoint timer to expire. When this 1009 occurs, the sending engine normally retransmits the checkpoint 1010 segment. However, if the number of times this checkpoint has been 1011 retransmitted has reached a predefined limit (established by network 1012 management), then the sending agent instead cancels the session. 1014 Similarly, loss of a report segment or of the responsive report- 1015 acknowledgment segment causes the report segment's timer to expire. 1016 When this occurs, the receiving engine normally retransmits the 1017 report segment. However, if the number of times this report segment 1018 has been retransmitted has reached a predefined limit (established by 1019 network management), then the receiving agent instead cancels the 1020 session. 1022 Reception of a previously received report segment that was 1023 retransmitted due to loss of an report-acknowledgment segment causes 1024 another responsive report-acknowledgment segment to be transmitted, 1025 but is otherwise ignored; if any of the data retransmitted in 1026 response to the previously received report segment were lost, further 1027 retransmission of those data will be requested by one or more new 1028 report segments issued in response to that earlier retransmission's 1029 checkpoint. Thus unnecessary retransmission is suppressed. 1031 5.2.1 Reception Reporting Rules 1033 The upper bound of a synchronous reception report is the upper bound 1034 of the checkpoint segment to which it responds. 1036 The upper bound of an asynchronous reception report is the maximum 1037 upper bound value among all data segments received so far in the 1038 affected session. 1040 The lower bound of a primary reception report is the upper bound of 1041 the previously issued primary reception report for the same session, 1042 if any; otherwise it is zero. 1044 The lower bound of a secondary reception report is the lower bound of 1045 the report segment to which the triggering checkpoint was itself a 1046 response. 1048 Asynchronous reception reports are never issued after the arrival of 1049 the EOB segment for a session. 1051 A reception report comprises as many reception segments as are 1052 necessary to report on all data reception in the scope of the 1053 reception report, within the constraints on maximum segment size 1054 imposed by the underlying communication service. [Again, a reception 1055 report normally comprises only a single reception segment; multiple 1056 report segments are needed only when a large number of segments for 1057 non-contiguous intervals of block data are lost.] The lower bound of 1058 the first report segment of a reception report is the reception 1059 report's lower bound; the upper bound of the last report segment of a 1060 reception report is the reception report's upper bound. 1062 5.2.2 Design Rationale 1064 Note that the responsibility for responding to segment loss in LTP is 1065 shared between the sender and receiver of a block: the sender 1066 retransmits checkpoint segments in response to checkpoint timeouts, 1067 and it retransmits non-checkpoint data segments in response to 1068 reception reports indicating incomplete reception, while the receiver 1069 additionally retransmits report segments in response to timeouts. An 1070 alternative design would have been to make the sender responsible for 1071 all retransmission, in which case the receiver would not expect 1072 report-acknowledgment segments and would not retransmit report 1073 segments. There are two disadvantages to this approach: 1075 First, because of constraints on segment size that might be imposed 1076 by the underlying communication service, it is at least remotely 1077 possible that the response to any single checkpoint might be multiple 1078 report segments. An additional sender-side mechanism for detecting 1079 and appropriately responding to the loss of some proper subset of 1080 those reception reports would be needed. We believe the current 1081 design is simpler. 1083 Second, an engine that receives a block needs a way to determine when 1084 the session can be closed. In the absence of explicit final report 1085 acknowledgment (which entails retransmission of the report in case of 1086 the loss of the report acknowledgment), the alternatives are (a) to 1087 close the session immediately on transmission of the report segment 1088 that signifies complete reception and (b) to close the session on 1089 receipt of an explicit authorization from the sender. In case (a), 1090 loss of the final report segment would cause retransmission of a 1091 checkpoint by the sender, but the session would no longer exist at 1092 the time the retransmitted checkpoint arrived; the checkpoint could 1093 reasonably be interpreted as the first data segment of a new block, 1094 most of which was lost in transit, and the result would be redundant 1095 retransmission of the entire block. In case (b), the explicit 1096 session termination segment and the responsive acknowledgment by the 1097 receiver (needed in order to turn off the timer for the termination 1098 segment, which in turn would be needed in case of in- transit loss or 1099 corruption of that segment) would somewhat complicate the protocol, 1100 increase bandwidth consumption, and retard the release of session 1101 state resources at the sender. Again we believe the current design 1102 is simpler and more efficient. 1104 5.3 Accelerated Delivery 1106 The receiving engine normally delivers block data content to the 1107 client service only at the moment when reception of the block is 1108 completed - that is, on reception of the last not-yet-received 1109 segment of the block. For some applications, however, it may be 1110 desirable to deliver block data content incrementally, upon arrival, 1111 because portions of the block may be individually useful to the 1112 client service. 1114 When the client service requests accelerated delivery of a block, the 1115 arrival of each new data segment causes the receiving engine to 1116 deliver to the client service the data content of the segment 1117 together with the segment's offset within the block. The client 1118 service assumes all responsibility for reassembling the block; upon 1119 completion of reception, the receiving engine just delivers the final 1120 data segment's content and offset to the client service as usual but 1121 additionally indicates that reception is now complete. 1123 5.4 Accelerated Retransmission 1125 Data segment retransmission occurs only on receipt of a report 1126 segment indicating incomplete reception; report segments in turn, are 1127 normally transmitted only at the end of an original transmission or 1128 retransmission. For some applications it may be desirable to trigger 1129 data segment retransmission incrementally during the course of an 1130 original transmission so that the retransmitted segments arrive 1131 sooner. This can be accomplished in two ways: 1133 Any data segment prior to the last one in the transmission can 1134 additionally be flagged as a checkpoint. Reception of each 1135 checkpoint causes the receiving engine to issue a reception 1136 report. 1138 At any time during the original transmission of a session (that 1139 is, prior to reception of the EOB), the receiving engine can 1140 unilaterally issue additional "asynchronous" reception reports. 1141 [Note that the CFDP protocol's "Immediate" mode is an example of 1142 this sort of asynchronous reception reporting; see Section 12.] 1143 The reception reports generated for accelerated retransmission are 1144 processed in exactly the same way as the standard reception 1145 reports. 1147 5.5 Session Cancellation 1149 A transmission session may be canceled by either the sending or the 1150 receiving engine, in response either to a request from the local 1151 client service instance or to an LTP operational failure as noted 1152 earlier. Session cancellation is accomplished as follows. 1154 The canceling engine deletes all currently queued segments for the 1155 session and notifies the local instance of the affected client 1156 service that the session is canceled. If no segments for this 1157 session have yet been sent to or received from the corresponding LTP 1158 engine, then at this point the canceling engine simply closes its 1159 state record for the session and cancellation is complete. 1160 Otherwise, the canceling engine queues for transmission to the 1161 corresponding engine a session cancellation segment. 1163 At the next opportunity, subject to allocation of bandwidth to the 1164 queue into which the cancellation segment was written, the enqueued 1165 cancellation segment is transmitted to the LTP engine serving the 1166 remote client service instance. A timer is started for the segment, 1167 so that it can automatically be retransmitted if no response is 1168 received. 1170 The corresponding engine receives the cancellation segment, enqueues 1171 for transmission to the canceling engine a cancellation- 1172 acknowledgment segment, deletes all other currently queued segments 1173 for the indicated session, notifies the local client service instance 1174 that the block has been canceled, and closes its state record for the 1175 session. 1177 At the next opportunity, the enqueued cancellation-acknowledgment 1178 segment is immediately transmitted to the canceling engine. 1180 The canceling engine receives the cancellation-acknowledgment, turns 1181 off the timer for the cancellation segment, and closes its state 1182 record for the session. 1184 Loss of a cancellation segment or of the responsive cancellation- 1185 acknowledgment causes the cancellation segment timer to expire. When 1186 this occurs, the canceling engine normally retransmits the 1187 cancellation segment. However, if the number of times this 1188 cancellation segment has been retransmitted has reached a predefined 1189 limit (established by network management), then the canceling agent 1190 instead simply closes its state record for the session. 1192 5.6 Unreliable Transmission 1194 For operational conditions in which the massive statefulness of LTP 1195 reliability is unsupportable or unnecessary, LTP can perform 1196 unreliable transmission. In unreliable mode all retransmission and 1197 session cancellation capabilities are disabled, but LTP's block 1198 segmentation, bandwidth management, interface to the underlying 1199 communication service, and incremental data delivery may still make 1200 it useful to client services. 1202 The nominal sequence of events in an unreliable transmission session 1203 is much simplified. 1205 Operation begins when a client service instance asks an LTP engine to 1206 transmit a block unreliably to a remote client service instance. The 1207 sending engine queues for transmission as many data segments as are 1208 necessary to transmit the entire block, within the constraints on 1209 maximum segment size imposed by the underlying communication service. 1210 The last such segment is marked an EOB signifying that the receiving 1211 engine can calculate the size of the block by summing the offset and 1212 length of the data in this segment. Note that this segment is an EOB 1213 but not a checkpoint. 1215 At the next opportunity, subject to allocation of bandwidth to the 1216 queue into which the block data segments were written, the enqueued 1217 segments are transmitted to the LTP engine serving the remote client 1218 service instance. 1220 The arrival of each data segment causes the receiving engine to 1221 deliver to the client service the data content of the segment 1222 together with the segment's offset within the block. The client 1223 service assumes all responsibility for reassembling the block. 1225 Upon arrival of the EOB segment, the receiving engine just delivers 1226 that final data segment's content and offset to the client service as 1227 usual but additionally indicates that reception of the block is now 1228 complete. 1230 Loss or corruption of transmitted data segments is not recoverable in 1231 this mode. Loss of the EOB is particularly troublesome: the 1232 receiving client service instance cannot readily distinguish between 1233 actual data loss and very severe queuing delay in this case, and the 1234 total size of the block can never be known. But for some 1235 applications (e.g., continuous telemetry streaming), or in deployment 1236 over a reliable link-layer protocol, this deficiency may be 1237 unimportant. 1239 6. Functional Model 1241 The functional model underlying the specification of LTP is one of 1242 deferred, opportunistic transmission, with access to the active 1243 transmission link apportioned among multiple outbound traffic queues. 1244 The accuracy of LTP retransmission timers depends in large part on a 1245 faithful adherence to this model. 1247 6.1 Deferred Transmission 1248 Every outbound LTP segment is appended to one of several (conceptual) 1249 queues of traffic bound for that segment's destination. Production 1250 of a segment and the subsequent actual transmission of that segment 1251 are in principle wholly asynchronous. 1253 In the event that (a) a transmission link to the destination is 1254 currently active and (b) the queue to which a given outbound segment 1255 is appended is otherwise empty and (c) this queue is determined to 1256 have the highest transmission priority among all outbound traffic 1257 queues associated with that destination, the segment will be 1258 transmitted immediately upon production. Transmission of a newly 1259 appended segment is necessarily deferred in all other circumstances. 1261 Conceptually, the de-queuing of segments from traffic queues bound 1262 for a given destination is initiated upon reception of a link state 1263 cue indicating that the underlying communication system is now 1264 transmitting to that destination, i.e., the link to that destination 1265 is now active. It ceases upon reception of a link state cue 1266 indicating that the underlying communication system is no longer 1267 transmitting to that destination, i.e., the link to that destination 1268 is no longer active. 1270 Note: in the following discussion, the de-queuing of a segment always 1271 implies delivering it to the underlying communication system for 1272 immediate transmission. 1274 6.2 Bandwidth Management 1276 We believe it is necessary for LTP to provide a mechanism for 1277 apportioning access to the active transmission link, possibly 1278 unevenly, among multiple classes of client service data traffic, and 1279 at the same time to provide a minimum-latency control channel for 1280 acknowledgment traffic. To accomplish these ends, the LTP functional 1281 model is based on the use of N outbound traffic queues, N > 1, for 1282 each destination with which the LTP engine can communicate. 1284 One such queue is strictly reserved for LTP internal operations: it 1285 contains only report and acknowledgment segments (collectively, 1286 "acknowledging segments"), which must be transmitted promptly to 1287 protect timer accuracy. A second queue is reserved for segments 1288 produced in sessions designated as "priority" sessions. Any other 1289 queues supported by a given LTP engine are for segments produced in 1290 non-priority sessions, typically of varying levels of urgency. The 1291 client service specifies the queue to be used for transmitting a 1292 given block - either the priority session queue or one of the non- 1293 priority session queues - at the time transmission of the block is 1294 requested. 1296 While the link to a given destination is active, continuous iteration 1297 of the following algorithm governs the de-queuing of segments from 1298 the N traffic queues bound for that destination: 1300 If any segments are currently in the internal operations queue, then 1301 de-queue the oldest such segment. 1303 Otherwise, if any segments are currently in the priority session 1304 queue, then de-queue the oldest such segment. 1306 Otherwise, if there are any other non-empty queues, invoke an 1307 implementation-specific algorithm to select the next queue to 1308 transmit from and then de-queue the oldest segment in that queue. 1310 6.3 Timers 1312 LTP relies on accurate calculation of expected arrival times for 1313 report and acknowledgment segments in order to know when proactive 1314 retransmission is required. If a calculated time were even slightly 1315 early, the result would be costly unnecessary retransmission. On the 1316 other hand, calculated arrival times may safely be several seconds 1317 late: the only penalties for late timeout and retransmission are 1318 slightly delayed data delivery and slightly delayed release of 1319 session resources. 1321 The following discussion is the basis for LTP's expected arrival time 1322 calculations. 1324 The total time consumed in a single "round trip" (transmission and 1325 reception of the original segment, followed by transmission and 1326 reception of the acknowledging segment) has the following components: 1328 Protocol processing time consumed in issuing the original segment, 1329 receiving the original segment, generating and issuing the 1330 acknowledging segment, and receiving the acknowledging segment. 1332 Outbound queuing delay: delay at the sender of the original segment 1333 while that segment is in a queue waiting for transmission, and delay 1334 at the sender of the acknowledging segment while that segment is in a 1335 queue waiting for transmission. 1337 Radiation time: the time that passes while all bits of the original 1338 segment are being radiated, and the time that passes while all bits 1339 of the acknowledging segment are being radiated. (This is 1340 significant only at extremely low data transmission rates.) 1342 Round-trip light time: propagation delay at the speed of light, in 1343 both directions. 1345 Inbound queuing delay: delay at the receiver of the original segment 1346 while that segment is in a reception queue, and delay at the receiver 1347 of the acknowledging segment while that segment is in a reception 1348 queue. 1350 Delay in transmission of the acknowledging segment due to loss of 1351 connectivity - that is, interruption in outbound link activity at the 1352 sender of the acknowledging segment due to occultation, scheduled end 1353 of tracking pass, etc. 1355 In this context, where errors on the order of seconds or even minutes 1356 may be tolerated, processing time at each end of the session is 1357 assumed to be negligible. 1359 Inbound queuing delay is also assumed to be negligible because, even 1360 on small spacecraft, LTP processing speeds are high compared to data 1361 transmission rates. 1363 Two mechanisms are used to make outbound queuing delay negligible: 1365 The expected arrival time of an acknowledging segment is not 1366 calculated until the moment the underlying communication system 1367 notifies LTP that radiation of the original segment has begun. All 1368 outbound queuing delay for the original segment has already been 1369 incurred at that point. 1371 Acknowledging segments (reports and acknowledgments) are always 1372 appended to the internal operations queue. This limits outbound 1373 queuing delay for an acknowledging segment to the time needed to de- 1374 queue and radiate all other acknowledging segments that are currently 1375 in that queue. Since acknowledging segments are sent infrequently 1376 and are normally very small, outbound queuing delay for a given 1377 acknowledging segment is likely to be minimal. 1379 Radiation delay at each end of the session is simply segment size 1380 divided by transmission data rate. It is insignificant except when 1381 data rate is extremely low (e.g., 10 bps), in which case the use of 1382 LTP may well be inadvisable for other reasons. Therefore radiation 1383 delay is normally assumed to be negligible. 1385 And we assume that one-way light time to the nearest second can 1386 always be known (e.g., provided by the operating environment). 1388 So the initial expected arrival time for each acknowledging segment 1389 is computed as simply the current time at the moment that radiation 1390 of the original segment begins, plus twice the one-way light time, 1391 plus 2*N seconds of margin to account for processing and queuing 1392 delays and for radiation time at both ends. N is a parameter set by 1393 network management for which 2 seconds seem to be a reasonable 1394 default value. 1396 This leaves only one unknown, the additional round trip time 1397 introduced by loss of connectivity. To account for this, we again 1398 rely on external link state cues. Whenever interruption of 1399 transmission at a remote LTP engine is signaled by a link state cue, 1400 we suspend the countdown timers for all acknowledging segments 1401 expected from that engine. Upon a signal that transmission has 1402 resumed at that engine, we resume those timers after (in effect) 1403 adding to each expected arrival time the length of the timer 1404 suspension interval. 1406 7. Segment Structure 1408 Each LTP segment comprises (a) a "header" in a standard format and 1409 (b) zero or more octets of "content". LTP segments are of four 1410 general types, depending on the nature of the content carried. 1412 Data segments carry client service (application) data, together 1413 with metadata enabling the receiving client service instance to 1414 receive and make use of that data. 1416 Report segments carry data reception claims together with the 1417 upper and lower bounds of the data block scope to which the claims 1418 pertain. 1420 Report acknowledgment segments carry only the serial number of the 1421 report being acknowledged. 1423 Session management segments are of two general subtypes: 1424 Cancellation and Cancellation acknowledgment. The Cancellation 1425 segments carry a single byte reason-code to indicate the reason 1426 for the cancellation. Cancellation acknowledgment segments have no 1427 content. 1429 7.1 Segment Header 1431 << Recommendations of SDNV-8 / SDNV-16 for fields in the segment 1432 header as recommended in this section, are under discussion. Future 1433 versions of the draft may recommend fields to be of one SDNV type 1434 instead of the other (SDNV-8 in place of SDNV-16, for example), if 1435 found to be more appropriate. >> 1437 An LTP segment header comprises three data items: a single-octet 1438 control byte, a session ID, and an expansion zone. 1440 Control byte comprises the following: 1442 Version number (4 bits): MUST be set to the binary value 0000 for 1443 this version of the protocol. 1445 Segment type flags (4 bits): described below. 1447 Session ID uniquely identifies, among all transmissions between the 1448 segment's sender and receiver, the session of which the segment is 1449 one token. It comprises the following: 1451 Session originator: the engine ID of the LTP engine that initiated 1452 the session, in SDNV-8 representation. 1454 Session number: a number in SDNV-16 representation, typically a 1455 timestamp, generated by the LTP engine identified as the session 1456 originator. 1458 The format and resolution of session number are matters that are 1459 private to the session-originating engine; the only requirement 1460 imposed by LTP is that every session initiated by an LTP engine 1461 MUST be uniquely identified by the session ID. For example, if 1462 timestamp resolution is not sufficient, an LTP implementation may 1463 choose to append an 8 or 16 bit sequence number to the timestamp 1464 to guard against the possibility of multiple sessions starting at 1465 the same system time. 1467 Expansion zone is a numeric value in SDNV-8 representation intended 1468 for future expansion of LTP capabilities. In the absence of any 1469 expansion features, it MUST be a single octet whose binary value is 1470 zero. 1472 7.1.1 Segment Type Flags 1474 The last four bits of the control byte in the segment header are 1475 flags that indicate the nature of the segment. In order (most 1476 significant bit first), these flags are as follows. 1478 Control flag (CTRL) 1480 A value of 0 indicates that the segment carries data and is a data 1481 segment, while a value of 1 indicates that the segment carries 1482 control information for the protocol (and not data). 1484 Exception flag (EXC) 1486 A value of 1 in a data segment indicates that the segment is being 1487 transmitted unreliably. In a control segment (CTRL flag set), this 1488 indicates that the segment pertains to session cancellation 1489 activity. 1491 Request flag (REQ) 1493 If set, this flag signifies a request for some specific response 1494 from the receiver. The nature of that response depends on the 1495 values of the other flags as described below. 1497 Closure flag (CLOS) 1499 When set, this flag signifies the termination of some element of 1500 protocol activity. The nature of the activity being terminated 1501 again depends on the values of the other flags as described below. 1503 7.1.2 Segment Type Codes 1505 Combinations of the settings of the segment type flags CTRL, EXC, 1506 REQ and CLOS constitute segment type codes which serve as concise 1507 representations of detailed segment nature. 1509 CTRL EXC REQ CLOS Code Nature of segment 1510 ---- ---- ---- ---- ---- --------------------------------------- 1511 0 0 0 0 0 Data, NOT a Checkpoint, NOT EOB 1512 0 0 0 1 1 Undefined 1513 0 0 1 0 2 Data, Checkpoint, NOT EOB 1514 0 0 1 1 3 Data, Checkpoint, EOB 1516 0 1 0 0 4 Data [unreliable transmission], not EOB 1517 0 1 0 1 5 Data [unreliable transmission], EOB 1518 0 1 1 0 6 Undefined 1519 0 1 1 1 7 Undefined 1521 1 0 0 0 8 Report segment 1522 1 0 0 1 9 Report acknowledgment 1523 1 0 1 0 10 Undefined 1524 1 0 1 1 11 Undefined 1526 1 1 0 0 12 Cancel segment 1527 1 1 0 1 13 Cancel acknowledgment 1528 1 1 1 0 14 Undefined 1529 1 1 1 1 15 Undefined 1531 7.1.3 Segment Class Masks 1533 For the purposes of this specification, some bit patterns in the 1534 segment type flags field correspond to "segment classes" that are 1535 designated by mnemonics. The mnemonics are intended to evoke the 1536 characteristics shared by all types of segments characterized by 1537 these flag bit patterns. 1539 CTRL EXC REQ CLOS Mnemonic Description 1540 ---- ---- ---- ---- -------- --------------------------- 1541 0 0 1 - CP Checkpoint 1543 0 0 1 1 EOB End of block; 1544 0 1 0 1 block size = offset + length 1546 1 0 0 0 R Report segment; 1547 carries reception claims 1549 1 0 0 1 RA Report acknowledgment 1551 1 1 0 0 C Cancellation 1553 1 1 0 1 CA Cancellation acknowledgment 1555 7.2 Segment Content 1557 7.2.1 Data Segment 1559 The content of a data segment includes client service data and 1560 metadata enabling the receiving client service instance to receive 1561 and make use of that data. 1563 If the data segment is a checkpoint, the segment MUST additionally 1564 include the following two serial numbers (Checkpoint serial number, 1565 Report serial number) to support efficient retransmission. All non- 1566 checkpoint data segments MUST NOT have these two fields and MUST 1567 begin with the Client service ID field defined below as the first 1568 element of the data segment. 1570 Checkpoint serial number [SDNV-8] 1572 The checkpoint serial number uniquely identifies the checkpoint 1573 among all checkpoints issued by the block sender in a session. 1574 The first checkpoint issued by the sender MUST have this serial 1575 number chosen randomly for security reasons, and it is RECOMMENDED 1576 that the sender use the guidelines in [ECS94] for this. Any 1577 subsequent checkpoints issued by the sender MUST have the serial 1578 number value one more than the last checkpoint serial number 1579 issued. Any retransmission of the checkpoint segment MUST have the 1580 same serial number as the original transmission. 1582 Report serial number [SDNV-8] 1584 If the checkpoint was queued for transmission in response to the 1585 reception of an R segment [Sec 9.13], then its value MUST be the 1586 report serial number value of the R segment that caused the data 1587 segment to be queued for transmission. 1589 Otherwise, the value of report serial number MUST be zero. 1591 Client service ID [SDNV-8] 1593 The client service ID number identifies the upper-level service to 1594 which the segment is to be delivered by the destination LTP 1595 engine. It is functionally analogous to a well-known TCP port 1596 number. If multiple instances of the client service are present 1597 at the destination, multiplexing must be done by the client 1598 service itself on the basis of information encoded within the 1599 transmitted block. 1601 At this time the only LTP client service we envision in the IPN is 1602 the DTN Bundling protocol. The client service ID value assigned to 1603 this client service is the number 1. 1605 Offset [SDNV-16] 1607 Offset indicates the location of the segment's client service data 1608 within the session's transmitted block. It is the number of bytes 1609 in the block prior to the byte from which the first octet of the 1610 segment's client service data was copied. 1612 Length [SDNV-16] 1614 The length of the following client service data, in octets. 1616 Client service data [array of octets] 1618 The client service data carried in the segment is a copy of a 1619 subset of the bytes in the original client service data block, 1620 starting at the indicated offset. 1622 7.2.2 Report Segment 1624 The content of an R segment comprises one or more data reception 1625 claims, together with the upper and lower bounds of the scope within 1626 the data block to which the claims pertain. It also includes two 1627 serial numbers to support efficient retransmission. 1629 Report serial number [SDNV-8] 1631 The report serial number uniquely identifies the report among all 1632 reports issued by the block receiver in a session. The first 1633 report issued by the receiver MUST have this serial number chosen 1634 randomly for security reasons, and it is RECOMMENDED that the 1635 receiver use the guidelines in [ECS94] for this. Any subsequent 1636 reports issued by the receiver MUST have the serial number value 1637 one more than the last report serial number issued. Any 1638 retransmission of the R segment MUST have the same serial number 1639 as the original transmission. 1641 Checkpoint serial number [SDNV-8] 1643 The value of checkpoint serial number MUST be zero if the report 1644 segment is NOT a response to reception of a checkpoint, i.e., the 1645 reception report is asynchronous; otherwise it is the checkpoint 1646 serial number of the checkpoint that caused the R segment to be 1647 issued. 1649 Upper bound [SDNV-16] 1651 The upper bound of a report segment is the size of the block 1652 prefix to which the segment's reception claims pertain. 1654 Lower bound [SDNV-16] 1656 The lower bound of a report segment is the size of the (interior) 1657 block prefix to which the segment's reception claims do NOT 1658 pertain. 1660 Reception claim count [SDNV-8] 1662 The number of data reception claims in this report segment. 1664 Data reception claims 1666 Each reception claim comprises two elements: offset and length. 1668 Offset [SDNV-16] 1670 The offset indicates the successful reception of data beginning 1671 at the indicated offset from the lower bound of the report. The 1672 offset within the entire block can be calculated by summing 1673 this offset with the lower bound of the report. 1675 Length [SDNV-16] 1677 The length of a reception claim indicates the number of 1678 contiguous octets of block data starting at the indicated 1679 offset (within the scope of the report) that have been 1680 successfully received so far. 1682 Reception claims MUST conform to the following rules: 1684 A reception claim's offset shall never be less than zero and 1685 its length shall never be less than 1. 1687 The offset of a reception claim shall always be greater than 1688 the sum of the offset and length of the prior claim, if any. 1690 The sum of a reception claim's offset and length shall never 1691 exceed the difference between the upper and lower bounds of the 1692 report segment. 1694 Implied requests for retransmission of client service data can be 1695 inferred from an R segment's data reception claims. However, 1696 *nothing* can be inferred regarding reception of block data at any 1697 offset equal to or greater than the segment's upper bound or at any 1698 offset less than the segment's lower bound. 1700 For example, if the scope of a report segment has lower bound 0 and 1701 upper bound 6000, and the report contains a single data reception 1702 claim with offset 0 and length 6000, then the report signifies 1703 successful reception of the first 6000 bytes of the block. If the 1704 total length of the block is 6000, then the report additionally 1705 signifies successful reception of the entire block. 1707 If on the other hand, the scope of a report segment has lower bound 1708 1000 and upper bound 6000, and the report contains two data reception 1709 claims, one with offset 0 and length 2000 and the other with offset 1710 3000 and length 500, then the report signifies successful reception 1711 only of bytes 1000-2999 and 4000-4499 of the block. From this we 1712 can infer that bytes 3000-3999 and 4500-5999 of the block need to be 1713 retransmitted, but we cannot infer anything about reception of the 1714 first 1000 bytes. 1716 7.2.3 Report Acknowledgment Segment 1718 The content of an RA segment is simply the report serial number of 1719 the R segment in response to which the segment was generated. 1721 Report serial number [SDNV-8] 1723 This field returns the report serial number of the R segment being 1724 acknowledged. 1726 7.2.4 Session Management Segments 1728 The C segment carries a single byte reason-code with the following 1729 semantics. 1731 Reason-Code Semantics 1732 ----------- -------------------------------- 1733 00 Client Service canceled session 1734 01 Unreachable Client Service 1735 02 Retransmission limit exceeded 1736 03-FF Undefined 1738 The CA segments have no content. 1740 8. Requests from Client Service 1742 In all cases the representation of request parameters is a local 1743 implementation matter, as are validation of parameter values and 1744 notification of the client service in the event that a request is 1745 found to be invalid. 1747 8.1 Transmission Request 1749 In order to request transmission of a block of client service data, 1750 the client service MUST provide the following parameters to LTP: 1752 Client service ID 1754 Destination LTP engine ID 1756 Data to send, as an array of bytes. 1758 Length of the data to be sent. 1760 Quality of service required: reliable or unreliable transmission. 1762 Flow-label, used to choose the queue within the queue-set for the 1763 LTP destination. 1765 On reception of a valid transmission request from a client service, 1766 LTP proceeds as follows. 1768 First the array of data to be sent is subdivided as necessary, with 1769 each subdivision serving as the client service data of a single new 1770 LTP data segment. The algorithm used for subdividing the data is a 1771 local implementation matter; it is expected that data size 1772 constraints imposed by the underlying communication service, if any, 1773 will be accommodated in this algorithm. 1775 The last (and only the last) of the resulting data segments MUST be 1776 marked as an EOB, with appropriate EOB segment flag bits set 1777 depending on reliable / unreliable transmission [Sec 7.1.2]. 1779 If the requested quality of service is reliable transmission, then 1780 all data segments resulting from subdivision of the data MUST have 1781 the EXC flag cleared. Moreover, at least the EOB segment MUST also 1782 be marked a checkpoint by having the REQ flag set; zero or more other 1783 data segments (selected according to an algorithm that is a local 1784 implementation matter) MAY additionally have the REQ flag set to act 1785 as checkpoints. 1787 On the other hand if the requested quality of service is unreliable 1788 transmission, then all data segments resulting from subdivision of 1789 the data MUST have the EXC flag set and REQ flag cleared. 1791 All data segments are appended to the appropriate (conceptual) 1792 transmission queue as specified in the transmission request. 1794 Finally, a session start notice [Sec 10.1] is sent back to the client 1795 service that requested the transmission. 1797 8.2 Cancellation Request 1799 In order to request cancellation of a session, either as sender or as 1800 receiver of the associated data block, the client service must 1801 provide to LTP the session ID of the session to be cancelled. 1803 On reception of a valid cancellation request from a client service, 1804 LTP proceeds as follows. 1806 First the internal "Cancel session" procedure [Sec 9.19] is invoked. 1808 Next, if the session is being canceled by the block sender, i.e., the 1809 session originator part of the session ID supplied in the 1810 cancellation request is the local LTP engine ID: 1812 If none of the data segments previously queued for transmission as 1813 part of this session have yet been de-queued and radiated, i.e., 1814 if the destination engine cannot possibly be aware of this session 1815 - then the session is simply closed; the "Close session" procedure 1816 [Sec 9.20] is invoked. 1818 Otherwise, a C segment with reason-code value 00 [Sec 7.2.4] MUST 1819 be appended to the internal operations queue of the queue-set 1820 bound for the destination LTP engine specified in the transmission 1821 request that started this session. 1823 Otherwise, (i.e., the session is being canceled by the block 1824 receiver): 1826 If there is no transmission queue-set bound for the block sender 1827 (possibly because the local LTP engine is running on a receive- 1828 only device), then the session is simply closed; the "Close 1829 session" procedure [Sec 9.20] is invoked. 1831 Otherwise, a C segment with reason-code value 00 [Sec 7.2.4] MUST 1832 be appended to the internal operations queue of the queue-set 1833 bound for the block sender. 1835 9. Internal Procedures 1837 This section describes the internal procedures that are triggered by 1838 the occurrence of various events during the life-time of the LTP 1839 session. 1841 Whenever the content of any of the fields of the header of any 1842 received LTP segment does not conform to this specification document, 1843 the segment is assumed to be corrupt and MUST be discarded 1844 immediately and processed no further. This procedure supersedes all 1845 other procedures described below. 1847 The data segments transmitted in the course of any single LTP session 1848 MUST either all have segment type code less than 4 (reliable 1849 transmission) or else all have segment type code greater than 3 1850 (unreliable transmission). 1852 All internal procedures described below that are triggered by the 1853 arrival of a data segment are superseded by the following procedure 1854 in the event that the client service identified by the data segment 1855 does not exist at the local LTP engine: 1857 If there is no transmission queue-set bound for the block sender 1858 (possibly because the local LTP engine is running on a receive-only 1859 device), then the data segment is simply discarded. Otherwise, if 1860 the data segment was transmitted reliably (segment type code less 1861 than 4), a C segment with reason-code value 01 [Sec 7.2.4] MUST be 1862 added to the internal operations queue of the queue-set bound for the 1863 block sender; a C segment with reason-code value 01 SHOULD be 1864 similarly added to the internal operations queue bound for the data 1865 sender if the data segment was transmitted unreliably (segment type 1866 code greater than 3) [For example, in the case where the block 1867 receiver knows that the sender is functioning in a "beacon" 1868 (transmit-only) fashion, a C segment need not be sent]. In either 1869 case the received data segment is discarded. 1871 9.1 Start Transmission 1873 This procedure is triggered by arrival of a link state cue indicating 1874 the start of transmission to a specified remote LTP engine. 1876 Response: the de-queuing and delivery to the underlying communication 1877 system of segments from traffic queues bound for the LTP engine 1878 specified in the link state cue begins. 1880 9.2 Start Checkpoint Timer 1882 This procedure is triggered by arrival of a link state cue indicating 1883 the de-queuing for transmission of a CP segment, provided that it is 1884 also the EOB for a session or if it was issued in response to an R 1885 segment i.e., the segment's report serial number is non-zero. 1887 Response: the expected arrival time of the R segment that will be 1888 produced on reception of this CP segment is computed, and a countdown 1889 timer for this arrival time is started. However, if it is known that 1890 the remote LTP engine has ceased transmission [Sec 9.5], then this 1891 timer is immediately suspended, because the computed expected arrival 1892 time may require an adjustment that cannot yet be computed. 1894 9.3 Start RS Timer 1896 This procedure is triggered by arrival of a link state cue indicating 1897 the de-queuing (for transmission) of an R segment. 1899 Response: the expected arrival time of the RA segment that will be 1900 produced on reception of this R segment is computed, and a countdown 1901 timer for this arrival time is started. However, if it is known that 1902 the remote LTP engine has ceased transmission [Sec 9.5], then this 1903 timer is immediately suspended, because the computed expected arrival 1904 time may require an adjustment that cannot yet be computed. 1906 9.4 Stop Transmission 1908 This procedure is triggered by arrival of a link state cue indicating 1909 the cessation of transmission to a specified remote LTP engine. 1911 Response: the de-queuing and delivery to the underlying communication 1912 system of segments from traffic queues bound for the LTP engine 1913 specified in the link state cue ceases. 1915 9.5 Suspend Timers 1917 This procedure is triggered by arrival of a link state cue indicating 1918 the cessation of transmission from a specified remote LTP engine to 1919 the local LTP engine. Normally, this event is inferred from advance 1920 knowledge of the remote engine's planned transmission schedule. 1922 Response: countdown timers for the acknowledging segments that the 1923 remote engine is expected to return are suspended as necessary based 1924 on the following procedure: 1926 The nominal acknowledge transmission time is computed as the sum of 1927 the transmission time of the original segment (to which the 1928 acknowledging segment will respond) and the one-way light time to the 1929 remote engine, plus N seconds of margin to account for processing and 1930 queuing delay at the remote engine; N should be a network management 1931 parameter, for which 2 seconds seems to be a reasonable default 1932 value. 1934 If the nominal acknowledge transmission time is greater than or equal 1935 to the current time (i.e., the acknowledging segment may be presented 1936 for transmission during the time that transmission at the remote 1937 engine is suspended), then the countdown timer for this acknowledging 1938 segment is suspended. 1940 9.6 Resume Timers 1942 This procedure is triggered by arrival of a link state cue indicating 1943 the start of transmission from a specified remote LTP engine to the 1944 local LTP engine. Normally, this event is inferred from advance 1945 knowledge of the remote engine's planned transmission schedule. 1947 Response: expected arrival time is adjusted for every acknowledging 1948 segment that the remote engine is expected to return, for which the 1949 countdown timer has been suspended. In each case, expected arrival 1950 time is increased by a transmission delay interval that is calculated 1951 as follows: 1953 The nominal acknowledge transmission time is computed as the sum 1954 of the transmission time of the original segment (to which the 1955 acknowledging segment will respond) and the one-way light time to 1956 the remote engine, plus N seconds of margin to account for 1957 processing and queuing delay at the remote engine; again, N should 1958 be a network management parameter, for which 2 seconds seems to be 1959 a reasonable default value. 1961 If the nominal acknowledge transmission time is greater than the 1962 current time i.e., the remote engine resumed transmission prior to 1963 presentation of the acknowledging segment for transmission, then 1964 the transmission delay interval is zero. 1966 Otherwise, the transmission delay interval is computed as the 1967 current time less the nominal acknowledge transmission time. 1969 After adjustment of expected arrival time, each of the suspended 1970 countdown timers is resumed. 1972 9.7 Retransmit Checkpoint 1974 This procedure is triggered by the expiration of a countdown timer 1975 associated with a CP segment. 1977 Response: if the number of times this CP segment has been queued for 1978 transmission exceeds the checkpoint retransmission limit established 1979 for the local LTP engine by network management, then the session of 1980 which the segment is one token is canceled: the "Cancel session" 1981 procedure [Sec 9.19] is invoked, a C segment with reason-code value 1982 02 [Sec 7.2.4] is appended to the transmission queue specified in the 1983 transmission request that started this session, and a transmission 1984 cancellation notice [Sec 10.5] is sent back to the client service 1985 that requested the transmission. 1987 Otherwise, a new copy of the CP segment is appended to the 1988 transmission queue specified in the transmission request that started 1989 this session. 1991 9.8 Retransmit RS 1993 This procedure is triggered by either (a) expiration of a countdown 1994 timer associated with an R segment or (b) reception of a CP segment 1995 whose checkpoint serial number is equal to that of one or more 1996 previously issued R segments for the same session -- an unnecessarily 1997 retransmitted checkpoint. 1999 Response: if the number of times any affected R segment has been 2000 queued for transmission exceeds the report retransmission limit 2001 established for the local LTP engine by network management, then the 2002 session of which the segment is one token is canceled: the "Cancel 2003 session" procedure [Sec 9.19] is invoked, a C segment with reason- 2004 code value 02 [Sec 7.2.4] is appended to the queue of internal 2005 operations traffic bound for the LTP engine that originated the 2006 session, and a reception cancellation notice [Sec 10.6] is sent to 2007 the client service identified in each of the data segments received 2008 in this session. 2010 Otherwise, a new copy of each affected R segment is appended to the 2011 queue of internal operations traffic bound for the LTP engine that 2012 originated the session. 2014 9.9 Signify Segment Arrival 2016 This procedure is triggered by the arrival of a data segment, but 2017 only when either (a) the data segment is being transmitted unreliably 2018 or (b) segment arrival notification has been authorized for the local 2019 LTP engine by client service or network management. 2021 Response: a segment arrival notice [Sec 10.2] is sent to the 2022 specified client service. 2024 9.10 Signify Block Reception 2026 This procedure is triggered by the arrival of a data segment, but 2027 only when either (a) the segment is also the EOB segment for a block 2028 being transmitted unreliably or (b) the segment is also a CP segment 2029 for a reliably transmitted block, and the EOB for this session has 2030 been received (including the case where this segment itself is the 2031 EOB segment) and the data block's size is known, and all data in the 2032 block being transmitted in this session have been received. 2034 Response: a block reception notice [Sec 10.3] is sent to the 2035 specified client service. 2037 9.11 Send Reception Report 2039 This procedure is triggered by either (a) reception of a CP segment 2040 whose checkpoint serial number is not equal to that of any previously 2041 issued R segment or (b) an implementation-specific circumstance 2042 pertaining to a particular block reception session for which no EOB 2043 has yet been received ("asynchronous" reception reporting). The 2044 response in either case is the same. 2046 Response: if the number of reception reports issued for this session 2047 exceeds the limit established for the local LTP engine by network 2048 management, then the affected session is canceled: the "Cancel 2049 session" procedure [Sec 9.19] is invoked, a C segment with reason- 2050 code value 02 [Sec 7.2.4] is appended to the queue of internal 2051 operations traffic bound for the LTP engine that originated the 2052 session, and a reception cancellation notice [Sec 10.6] is sent to 2053 the client service identified in each of the data segments received 2054 in this session. Otherwise, a reception report is issued as follows. 2056 As many R segments are produced as are needed in order to report on 2057 all data reception within the scope of the report, given whatever 2058 data size constraints are imposed by the underlying communication 2059 service. They are appended to the queue of internal operations 2060 traffic bound for the LTP engine that originated the indicated 2061 session. If production of the reception report was triggered by 2062 reception of a checkpoint: 2064 The upper bound of the report is the upper bound (the sum of the 2065 offset and length) of the checkpoint data segment. 2067 If the checkpoint was itself issued in response to a report 2068 segment, then this report is a "secondary" reception report and 2069 the lower bound of the report is that earlier report segment's 2070 lower bound. Otherwise, this report is a "primary" reception 2071 report and the lower bound of the report is the upper bound of the 2072 prior primary reception report issued for this session. 2074 Otherwise, i.e., the reception report is asynchronous: 2076 The upper bound of the report is the maximum upper bound among all 2077 data segments received so far for this session. 2079 The lower bound of the report is the upper bound of the prior 2080 primary reception report issued for this session. 2082 9.12 Signify Transmission Completion 2084 This procedure is triggered by either (a) reception of an R segment 2085 whose reception claims taken together with the reception claims of 2086 all other report segments previously received in the course of this 2087 session indicate complete reception of an entire data block, or (b) 2088 arrival of a link state cue indicating the de-queuing (for 2089 transmission) of an EOB segment for a block transmitted unreliably. 2091 Response: a transmission completion notice [Sec 10.4] is sent to the 2092 client service that requested the transmission identified in the 2093 segment header and the session is closed: the "Close session" 2094 procedure [Sec 9.20] is invoked. 2096 9.13 Retransmit Data 2098 This procedure is triggered by reception of an R segment. 2100 Response: first, an RA segment with the same report serial number as 2101 the R segment is appended to the queue of internal operations traffic 2102 bound for the LTP engine that originated the indicated session. If 2103 the R segment is redundant i.e., either the indicated session is 2104 unknown (if for example, the R segment is received after the session 2105 has been completed or canceled), or the R segment's report serial 2106 number is equal to that of a previously received report segment for 2107 this session -- then no further action is taken. Otherwise the 2108 procedure below is followed. 2110 If the report's checkpoint serial number is not zero, then the 2111 countdown timer associated with the indicated checkpoint segment is 2112 deleted. 2114 All retransmission buffer space occupied by data whose reception is 2115 claimed in the report segment can be released. 2117 If the segment's reception claims indicate incomplete data reception 2118 within the scope of the report segment: 2120 If the number of CP segments issued for this session exceeds the 2121 limit established for the local LTP engine by network management, 2122 then the session of which the segment is one token is canceled: 2123 the "Cancel session" procedure [Sec 9.19] is invoked, a C segment 2124 with reason-code value 02 [Sec 7.2.4] is appended to the 2125 transmission queue specified in the transmission request that 2126 started this session, and a transmission cancellation notice [Sec 2127 10.5] is sent back to the client service that requested the 2128 transmission. 2130 Otherwise, new data segments encapsulating all block data whose 2131 non-reception is implied by the reception claims are appended to 2132 the transmission queue specified in the transmission request that 2133 started this session. The last - and only the last - such segment 2134 must me marked as a CP segment and must contain the report serial 2135 number of the received R segment. 2137 9.14 Stop RS Timer 2139 This procedure is triggered by reception of an RA segment. 2141 Response: the countdown timer associated with the original R 2142 segment (identified by the report serial number of the RA segment) 2143 is deleted. If no other countdown timers associated with R 2144 segments existed for this session, then the session is closed: the 2145 "Close session" procedure [Sec 9.20] is invoked. 2147 9.15 Start Cancel Timer 2149 This procedure is triggered by arrival of a link state cue 2150 indicating the de-queuing (for transmission) of a C segment. 2152 Response: the expected arrival time of the CA segment that will be 2153 produced on reception of this C segment is computed and a 2154 countdown timer for this arrival time is started. However, if it 2155 is known that the remote LTP engine has ceased transmission [Sec 2156 9.5] then this timer is immediately suspended, because the 2157 computed expected arrival time may require an adjustment that 2158 cannot yet be computed. 2160 9.16 Retransmit Cancellation Segment 2162 This procedure is triggered by the expiration of a countdown timer 2163 associated with a C segment. 2165 Response: if the number of times this C segment has been queued 2166 for transmission exceeds the cancellation retransmission limit 2167 established for the local LTP engine by network management, then 2168 the session of which the segment is one token is simply closed: 2169 the "Close session" procedure [Sec 9.20] is invoked. 2171 Otherwise, a new copy of the C segment (retaining the same reason- 2172 code value) is appended to the appropriate transmission queue. If 2173 the segment is being sent by the block sender, then the 2174 appropriate transmission queue is the one specified in the 2175 transmission request that started this session; otherwise, the 2176 appropriate transmission queue is the queue of internal operations 2177 traffic bound for the LTP engine that originated the session. 2179 9.17 Acknowledge Cancellation 2181 This procedure is triggered by the reception of a C segment. 2183 Response: if the local segment is not the block sender for the 2184 block identified in the C segment and there is no transmission 2185 queue-set bound for the block sender (possibly because the local 2186 LTP engine is running on a receive-only device), then no action is 2187 taken. Otherwise, a CA segment is appended to the queue of 2188 internal operations traffic bound for the LTP engine that sent the 2189 C segment. 2191 It is possible that the C segment is being retransmitted because a 2192 previous CA was lost, in which case there will no longer be any 2193 record of the session of which the segment is one token. If so, no 2194 further action is taken. 2196 Otherwise that session is locally canceled: the "Cancel session" 2197 procedure [Sec 9.19] is invoked and a reception cancellation 2198 notice [Sec 10.6] is sent to the client service identified in each 2199 of the data segments received in this session. Finally, the 2200 session is closed: the "Close session" procedure [Sec 9.20] is 2201 invoked. 2203 9.18 Stop Cancellation Timer 2205 This procedure is triggered by reception of a CA segment. 2207 Response: the session of which the segment is one token is closed, 2208 i.e., the "Close session" procedure [Sec 9.20] is invoked. 2210 9.19 Cancel Session 2212 This procedure is triggered internally by one of the other 2213 procedures described above. 2215 Response: all segments of the affected session that are currently 2216 queued for transmission can be deleted from the outbound traffic 2217 queues. If the local LTP engine is the originator of the session, 2218 then all remaining data retransmission buffer space allocated to 2219 the session can be released. All countdown timers currently 2220 associated with the session are deleted. 2222 9.20 Close Session 2224 This procedure is triggered internally by one of the other 2225 procedures described above. 2227 Response: any remaining countdown timers associated with the 2228 session (such as the timer associated with a C segment) are 2229 deleted. All other state information regarding the session is 2230 deleted; existence of the session is no longer recognized. 2232 10. Notices to Client Service 2234 In all cases the representation of notice parameters is a local 2235 implementation matter. 2237 10.1 Session Start 2239 The LTP engine returns the Session ID of the new transmission 2240 session when a session start notice is delivered. 2242 A session start notice informs the client service of the 2243 initiation of a transmission session in response to a transmission 2244 request from that client service. On receiving this notice the 2245 client service may, for example, release resources of its own that 2246 are allocated to the block being transmitted, or remember the 2247 Session ID so that the session can be canceled in the future. 2249 10.2 Data Segment Arrival 2251 The parameters provided by the LTP engine when a data segment 2252 arrival notice is delivered are: 2254 Session ID of the transmission session 2256 Array of client service data bytes contained in the data 2257 segment 2259 Offset of the data segment's content from the start of the 2260 block 2261 Length of the data segment's content 2263 Source LTP engine ID 2265 Data segment arrival notices deliver block data incrementally, as 2266 it is received. This enables the receiving client service 2267 instance to make use of partial data immediately, rather than 2268 potentially waiting hours or days for the retransmission of 2269 missing segments and the ultimate delivery of the completed block. 2270 Incremental block data delivery is mandatory for unreliable 2271 transmission, because there's never any guarantee that the EOB 2272 segment- which is required in order to deliver a complete block - 2273 will ever be received at all. Incremental delivery also enables 2274 the client service to cancel reception of a block, if necessary. 2276 10.3 Block Reception 2278 The parameters provided by the LTP engine when a block reception 2279 notice is delivered are: 2281 Session ID of the transmission session. 2283 Array of client service data bytes that constitutes the block 2285 Length of the block. 2287 Source LTP engine ID. 2289 A block reception notice delivers a complete data block to the 2290 client service. 2292 10.4 Transmission Completion 2294 The sole parameter provided by the LTP engine when a transmission 2295 completion notice is delivered is the Session ID of the 2296 transmission session. 2298 A transmission completion notice informs the client service that 2299 the indicated session has successfully completed; the destination 2300 LTP engine has received the entire data block. 2302 10.5 Transmission Cancellation 2304 The sole parameter provided by the LTP engine when a transmission 2305 cancellation notice is delivered is the Session ID of the 2306 transmission session. 2308 A transmission cancellation notice informs the client service that 2309 the indicated session was terminated, either by decision of the 2310 destination client service instance or due to violation of a 2311 retransmission limit in the local LTP engine. There is no 2312 assurance that the destination client service instance received 2313 the data block. 2315 10.6 Reception Cancellation 2317 The sole parameter provided by the LTP engine when a reception 2318 cancellation notice is delivered is the Session ID of the 2319 transmission session. 2321 A reception cancellation notice informs the client service that 2322 the indicated session was terminated, either by decision of the 2323 source client service instance or due to violation of a 2324 retransmission limit in the local LTP engine. The complete data 2325 block will not be delivered. 2327 11. Requirements from the Operating Environment 2329 LTP requires support from its operating environment (which 2330 includes network management activities) and link-state cues from 2331 the data-link layer for its operations. 2333 The local data-link layer needs to inform LTP whenever the link to 2334 a specific LTP destination is brought up or torn down. Similarly, 2335 the operating environment needs to inform the local LTP engine 2336 whenever it is known that a remote LTP engine is set to begin 2337 communication with the local engine from the operating schedules. 2338 LTP also needs to be able to query the current speed-of-light to 2339 its peer engine from the operating environment to calculate its 2340 timers. 2342 A MIB (Management Information Base) with the above parameters 2343 filled in by the local data-link layer and the operating 2344 environment periodically, should be made available for the LTP 2345 engine for its operations. The exact details of the MIB are beyond 2346 the scope of this document. 2348 LTP also requires the underlying data-link layer to perform data 2349 integrity check of the segments received. Specifically, the data- 2350 link layer is expected to detect any segments received corrupted, 2351 and to silently discard them. 2353 12. Security Considerations 2355 <> 2359 LTP is designed as a hyper-datalink layer to primarily do ARQ of 2360 data transmissions over a point-to-point link exhibiting some or 2361 all of the following characteristics: high delays, high BERs and 2362 intermittent, possibly strictly scheduled connectivity. 2364 However, how "point-to-point" the link is physically, depends on 2365 the underlying datalink. For a deep-space link using radio 2366 datalink, say we are talking from a Deep-Space-Network giant dish 2367 antenna to an orbiter on Mars, the signal could be received and 2368 processed by any other orbiter passing at the same time in the 2369 Mars orbiter's reception area, which could potentially cover 2370 hundreds or thousands of square miles. Similarly a link 2371 transmitting data from an orbiter to a ground-rover could have a 2372 reception-coverage area of tens of square miles. So there is an 2373 inherent risk that of unintended receivers listening in on LTP 2374 transmissions over such datalinks. 2376 Such promiscuous recipients of our LTP transmissions could 2377 potentially replay the transmissions sent, twiddle with control 2378 bits in the LTP header before they do so (more dangerous is the 2379 case when they make the bits claim the LTP segment to be a Cancel 2380 segment closing the session). Such problems are more severe for 2381 LTP compared to other terrestrial Internet protocols because LTP 2382 inherently does a lot of state retention (to handle the high 2383 delays and intermittent connectivity of its links), has very high 2384 time-out values and LTP nodes may be quite difficult to reset. In 2385 other words, by design, there is a long delay before LTP gives up 2386 on a session. Thus any such adversary listening in on the LTP 2387 transmissions has the potential to create severe DoS conditions 2388 for an LTP receiver. 2390 To give a terrestrial example - were LTP to be used in a sparse 2391 sensor network, then denial of service attacks could be mounted 2392 which would result in nodes missing critical information, e.g. 2393 communications schedule updates. In such cases, a single DoS 2394 attack success could take a node entirely off the network until 2395 the node is physically visited and reset. 2397 Even in the deep space cases, we do need to consider some 2398 terrestrial based attacks, in particular those involving insertion 2399 of a message into an on-going session (usually without having seen 2400 the exact bytes of the previous messages in the session). This 2401 could arise due to firewall failures at various points or due to 2402 Trojan software running on an authorized host. 2404 Such attacks may depend on the attacker correctly "guessing" about 2405 the state of LTP nodes, but it is worth noting that patterns of 2406 deep space communication may well be considered guessable from the 2407 Earth (e.g. a session to a Mars rover is only going to happen 2408 while that rover is visible from the Earthstation -- all public 2409 information) and the delay-tolerance inherent in LTP may decrease 2410 the required accuracy of such guesses. Most of the attacks 2411 concerned here are DoS attacks. 2413 12.1 Mechanisms and Layering Considerations 2415 There is thus a real need to consider security of LTP 2416 transmissions, so we need to consider (to the extent possible) the 2417 appropriate layer(s) at which security mechanisms can best be 2418 deployed. 2420 The Application layer (above-LTP) 2422 This seems like a reasonable approach to protect LTP data, but 2423 would leave the LTP headers open. The headers carry information 2424 on where the transmission is coming from, which could be 2425 valuable in itself. Further, this approach provides little or 2426 no protection against DoS type attacks against LTP. 2428 The LTP layer 2430 Security at this layer offers nice authentication 2431 possibilities. For example, an authentication header (like 2432 that in IPSEC [AH]) can help to protect against replay attacks 2433 and bogus packets. However, an adversary can still see the LTP 2434 header of segments passing by in the ether. This approach also 2435 requires some key management infrastructure be in place in 2436 order to provide strong authentication. 2438 The Datalink layer (below-LTP) 2440 Providing encryption/authentication in the layer(s) below LTP 2441 has some nice properties, like being able to do encryption on- 2442 chip in hardware, making it fast. However, depending on the 2443 datalink we may be forced to use encryption / authentication on 2444 all LTP sessions which may not be required. A more flexible 2445 scheme might enable us to do encryption / authentication on 2446 only critical information sessions. For example we might want 2447 it only for commands that ask a rover to reinstall a new OS 2448 image and reboot; and may be not so much when we are 2449 transmitting a picture (though this can be hard to achieve 2450 without layering violations). Security provided by the 2451 datalink may result in unnecessary overhead and lessens 2452 flexibility, but may well be the optimal place to include 2453 compression and encryption. 2455 12.2 Denial of Service Considerations 2457 Potential DoS attack points 2459 Implementers SHOULD consider the following DoS attacks : 2461 A fake C segment could be inserted thus bringing down a 2462 session. 2464 Various ACK messages may be deleted causing timers to expire 2465 which could deny service if done with knowledge of the 2466 communications schedule. One possible way to achieve this would 2467 be to mount a denial of service attack on a lower layer device 2468 in order to prevent it sending an ACK, or perhaps to simply jam 2469 the transmission (all of which are more likely for terrestrial 2470 applications of LTP). An attacker might also flip some bits, 2471 which is (hopefully!) tantamount to deleting that message. 2473 An attacker may flood a node with "internal" messages (using 2474 the terminology of section 6.2) which require processing, thus 2475 preventing "real" data segments from being transmitted. 2477 An attacker could attempt to fill up the storage in some node 2478 by sending many large messages to it. In terrestrial LTP 2479 applications this may be much more serious since spotting the 2480 additional traffic may not be possible from any network 2481 management point. 2483 - <> 2485 Anti-DoS measures 2487 <> 2521 12.3 Authentication header 2523 An LTP Authentication Header (LTP-AH) MAY be used to provide 2524 cryptographic authentication of the segment. 2526 Implementations MAY support this header. If they do not support 2527 this header then they MUST ignore it. <> 2530 The LTP-AH uses the LTP expansion field <> and 2531 contains the following fields <> 2534 - Ciphersuite: an eight bit integer value <> 2536 - KeyID: An SDNV <> 2538 - AuthVal: An SDNV-16 value containing the authentication 2539 value <> 2542 <> 2544 12.4 Implementation Considerations 2546 SDNV 2548 Implementations SHOULD make sanity checks on SDNV length fields 2549 and SHOULD check that no SDNV field is too long when compared 2550 with overall segment length. 2552 Implementations SHOULD check that SDNV values are within 2553 suitable ranges where possible, e.g. <> 2555 Byte ranges 2557 Various report and other segments contain offset and length 2558 fields. Implementations MUST ensure that these are consistent 2559 and sane. 2561 Randomness 2563 Various fields in LTP (e.g. serial numbers) should be 2564 initialised using random values. Good sources of randomness 2565 which are not easily guessable SHOULD be used [ECS94]. 2567 <> 2569 12.5 Miscellaneous 2571 An attacker could modify a message or insert a new message with 2572 the aim of making a session which should use reliable transport 2573 into one which uses unreliable transport and could also switch 2574 from normal to accelerated delivery. The end result could be 2575 that real data arrives out of order. Higher layer processing 2576 SHOULD take this into account if the LTP or lower layers do not 2577 preclude such attacks. 2579 <> 2581 13. Tracing LTP back to CFDP 2583 LTP in effect implements most of the "core procedures" of the 2584 CCSDS File Delivery Protocol (CFDP) specification, minus all 2585 features that are specific to operations on files and filestores 2586 (file systems); in the IPN architecture we expect that file and 2587 filestore operations will be conducted by file transfer 2588 application protocols -- notably CFDP itself -- operating on top 2589 of the DTN Bundling protocol. (Bundling in effect implements the 2590 CFDP "extended procedures" in a more robust and scalable manner 2591 than is prescribed by the CFDP standard.) The fundamental 2592 difference is that, while CFDP delivers named files end-to-end, 2593 LTP is used to transmit arbitrary, unnamed blocks of data point- 2594 to-point. 2596 Some differences between LTP and CFDP are simply matters of 2597 terminology; the following table summarizes the correspondences in 2598 language between the two. 2600 --------------LTP------------- ------------CFDP------------- 2602 LTP engine CFDP entity 2604 Segment Protocol Data Unit (PDU) 2606 Reception Report NAK 2608 Client service request Service request 2610 Client service notice Service indication 2612 CFDP specifies four mechanisms for initiating data retransmission, 2613 called "lost segment detection modes". LTP effectively supports 2614 all four: 2616 "Deferred" mode is implemented in LTP by the Request flag in 2617 the EOB data segment, which triggers reception reporting upon 2618 receipt of the EOB. 2620 "Prompted" mode is implemented in LTP by turning on Request 2621 flags in data segments that precede the EOB; these additional 2622 checkpoints trigger interim reception reporting under the 2623 control of the source LTP engine. 2625 "Asynchronous" mode is implemented in LTP by the autonomous 2626 production, under locally specified conditions, of additional 2627 reception reports prior to arrival of the EOB. 2629 "Immediate" mode is simply a special case of asynchronous mode, 2630 where the condition that triggers autonomous reception 2631 reporting is detection of a gap in the incoming data. 2633 CFDP uses a cyclic timer to iterate reception reporting until 2634 reception is complete. Because choosing a suitable interval for 2635 such a timer is potentially quite difficult, LTP instead flags the 2636 last data segment of each retransmission as a checkpoint, sent 2637 reliably; the cascading reliable transmission of checkpoint and RS 2638 segments assures the continuous progress of the transmission 2639 session. 2641 CFDP's Suspend and Resume PDUs are functionally displaced in LTP 2642 by deferred transmission and automated bandwidth management. 2644 As the following table indicates, most of the functions of CFDP 2645 PDUs are accomplished in some way by LTP segments. 2647 --------------LTP------------- -------------CFDP------------ 2649 Data segments File data and metadata PDUs 2651 Closure flag on data segment EOF (Complete) 2653 Request flag on data segment EOF (Complete), Prompt (NAK), 2654 Prompt (Keep Alive) 2656 Report segment ACK (EOF Complete), NAK, 2657 Keep Alive, Finished (Complete) 2659 Report acknowledgment ACK (Finished Complete) 2661 Cancel segment EOF (Cancel, Protocol Error) 2662 Finished (Cancel, Protocol Error) 2664 Cancellation Acknowledgment ACK (EOF (Cancel, Protocol Error), 2665 Finished (Cancel, Protocol Error)) 2667 But some CFDP PDUs have no LTP equivalent because in an IPN 2668 architecture they will likely be implemented elsewhere. CFDP's 2669 EOF (Filestore error) and Finished (Filestore error) PDUs would be 2670 implemented in an IPN application-layer file transfer protocol, 2671 e.g., CFDP itself. CFDP's Finished [End System] PDU is a feature 2672 of the Extended Procedures, which would in effect be implemented 2673 by the Bundling protocol. 2675 14. IANA Considerations 2677 At present there are none known. However if someone wanted to run 2678 LTP over IP (or even TCP or UDP), then we would want to allocate a 2679 port number. <> 2681 15. Acknowledgments 2683 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 2684 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss 2685 for their thoughts on this protocol and its role in Delay-Tolerant 2686 Networking architecture. 2688 Part of the research described in this document was carried out at 2689 the Jet Propulsion laboratory, California Institute of Technology, 2690 under a contract with the National Aeronautics and Space 2691 Administration. This work was performed under DOD Contract DAA- 2692 B07- 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO 2693 H870; and NASA Contract NAS7-1407. This work was performed under 2694 DOD Contract DAA-B07-00-CC201, DARPA AO H912; JPL Task Plan No. 2695 80-5045, DARPA AO H870; and NASA Contract NAS7-1407. 2697 Part of this work was carried out at Trinity College Dublin as 2698 part of the SeNDT contract funded by Enterprise Ireland's research 2699 innovation fund. 2701 16. References 2703 [IPN] InterPlanetary Internet Special Interest Group web page, 2704 "http://www.ipnsig.org". 2706 [CCSDS] Consultative Committee for Space Data Systems web page, 2707 "http://www.ccsds.org". 2709 [CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for 2710 Space Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1, 2711 October 2002. 2713 [BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification", 2714 Work in Progress, October 2003. 2716 [DTNRG] Delay Tolerant Networking Research Group web page, 2717 "http://www.dtnrg.org". 2719 [MSM97] M. Mathis, J. Semke, and J. Mahdavi, "The Macroscopic 2720 Behavior of the TCP Congestion Avoidance Algorithm", Computer 2721 Communications Review Vol.27(3), 1997. 2723 [P97] V. Paxson, "Measurements and Analysis of End-to-End Internet 2724 Dynamics", Ph.D. Thesis., Computer Science Divisions, University 2725 of California, Berkeley, 1997. 2727 [TM] Packet Telemetry Specification. Recommendation for Space Data 2728 System Standards, CCSDS 103.0-B-2 BLUE BOOK Issue 2, June 2001. 2730 [TC] Telecommand Part 2 - Data Routing Service. Recommendation for 2731 Space Data System Standards, CCSDS 202.0-B-3 BLUE BOOK Issue 3, 2732 June 2001. 2734 [ASN1] Abstract Syntax Notation One (ASN.1). Specification of 2735 Basic Notation. ITU-T Rec. X.680 (2002) | ISO/IEC 8824-1:2002. 2737 [B97] S. Bradner, "Key words for use in RFCs to Indicate 2738 Requirement Levels", BCP 14, RFC 2119, March 1997. 2740 [ECS94] D. Eastlake, S. Crocker, and J. Schiller, "Randomness 2741 Recommendations for Security", RFC 1750, December 1994. 2743 17. Author's Addresses 2745 Scott C. Burleigh 2746 Jet Propulsion Laboratory 2747 4800 Oak Grove Drive 2748 M/S: 179-206 2749 Pasadena, CA 91109-8099 2750 Telephone +1 (818) 393-3353 2751 FAX +1 (818) 354-1075 2752 Email Scott.Burleigh@jpl.nasa.gov 2754 Manikantan Ramadas 2755 Internetworking Research Group 2756 301 Stocker Center 2757 Ohio University 2758 Athens, OH 45701 2759 Telephone +1 (740) 593-1562 2760 Email mramadas@irg.cs.ohiou.edu 2762 Stephen Farrell 2763 Distributed Systems Group 2764 Computer Science Department 2765 Trinity College Dublin 2766 Ireland 2767 Telephone +353-1-608-3070 2768 Email stephen.farrell@cs.tcd.ie