doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc5325.txt b/doc/rfc/rfc5325.txt
new file mode 100644
index 0000000..cc3ab29
--- /dev/null
+++ b/doc/rfc/rfc5325.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                        S. Burleigh
+Request for Comments: 5325                NASA/Jet Propulsion Laboratory
+Category: Informational                                       M. Ramadas
+                                                            ISTRAC, ISRO
+                                                              S. Farrell
+                                                  Trinity College Dublin
+                                                          September 2008
+
+
+              Licklider Transmission Protocol - Motivation
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+IESG Note
+
+   This RFC is not a candidate for any level of Internet Standard.  It
+   represents the consensus of the Delay Tolerant Networking (DTN)
+   Research Group of the Internet Research Task Force (IRTF).  See RFC
+   3932 for more information.
+
+Abstract
+
+   This document describes the motivation for the development of the
+   Licklider Transmission Protocol (LTP) designed to provide
+   retransmission-based reliability over links characterized by
+   extremely long message round-trip times (RTTs) and/or frequent
+   interruptions in connectivity.  Since communication across
+   interplanetary space is the most prominent example of this sort of
+   environment, LTP is principally aimed at supporting "long-haul"
+   reliable transmission in interplanetary space, but it has
+   applications in other environments as well.
+
+   In an Interplanetary Internet setting deploying the Bundle protocol,
+   LTP is intended to serve as a reliable convergence layer over
+   single-hop deep-space radio frequency (RF) links.  LTP does Automatic
+   Repeat reQuest (ARQ) of data transmissions by soliciting selective-
+   acknowledgment reception reports.  It is stateful and has no
+   negotiation or handshakes.
+
+   This document is a product of the Delay Tolerant Networking Research
+   Group and has been reviewed by that group.  No objections to its
+   publication as an RFC were raised.
+
+
+
+
+Burleigh, et al.              Experimental                      [Page 1]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Problem .........................................................3
+      2.1. IPN Operating Environment ..................................3
+      2.2. Why Not TCP or SCTP? .......................................5
+   3. Protocol Overview ...............................................6
+      3.1. Nominal Operation ..........................................6
+           3.1.1. Link State Cues .....................................9
+           3.1.2. Deferred Transmission ...............................9
+           3.1.3. Timers .............................................10
+      3.2. Retransmission ............................................13
+      3.3. Accelerated Retransmission ................................16
+      3.4. Session Cancellation ......................................17
+   4. Security Considerations ........................................17
+   5. IANA Considerations ............................................20
+   6. Acknowledgments ................................................20
+   7. References .....................................................20
+      7.1. Informative References ....................................20
+
+1.  Introduction
+
+   The Licklider Transmission Protocol (LTP) is designed to provide
+   retransmission-based reliability over links characterized by
+   extremely long message round-trip times and/or frequent interruptions
+   in connectivity.  Communication in interplanetary space is the most
+   prominent example of this sort of environment, and LTP is principally
+   aimed at supporting "long-haul" reliable transmission over deep-space
+   RF links.  Specifically, LTP is intended to serve as a reliable
+   "convergence layer" protocol, underlying the Delay-Tolerant
+   Networking (DTN) [DTN] Bundle protocol [BP], in DTN deployments where
+   data links are characterized by very long round-trip times.
+
+   This document describes the motivation for LTP, its features,
+   functions, and overall design.  It is part of a series of documents
+   describing LTP.  Other documents in the series include the main
+   protocol specification document [LTPSPEC] and the protocol extensions
+   document [LTPEXT].
+
+   The protocol is named in honor of ARPA/Internet pioneer JCR
+   Licklider.
+
+
+
+
+
+
+
+
+
+
+Burleigh, et al.              Experimental                      [Page 2]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+2.  Problem
+
+2.1.  IPN Operating Environment
+
+   There are a number of fundamental differences between the environment
+   for terrestrial communications (such as seen in the Internet) and the
+   operating environments envisioned for the Interplanetary Internet
+   (IPN) [IPN].
+
+   The most challenging difference between communication among points on
+   Earth and communication among planets is round-trip delay, of which
+   there are two main sources, both relatively intractable: physics and
+   economics.
+
+   The more obvious type of delay imposed by nature is signal
+   propagation time.  Round-trip times between Earth and Jupiter's moon
+   Europa, for example, run between 66 and 100 minutes.
+
+   Less obvious and more dynamic is the delay imposed by occultation.
+   Communication between planets must be by radiant transmission, which
+   is usually possible only when the communicating entities are in line
+   of sight of each other.  During the time that communication is
+   impossible, delivery is impaired and messages must wait in a queue
+   for later transmission.
+
+   Round-trip times and occultations can at least be readily computed
+   given the ephemerides of the communicating entities.  Additional
+   delay that is less easily predictable is introduced by discontinuous
+   transmission support, which is rooted in economics.
+
+   Communicating over interplanetary distances requires expensive
+   special equipment: large antennas, high-performance receivers, etc.
+
+   For most deep-space missions, even non-NASA ones, these are currently
+   provided by NASA's Deep Space Network (DSN) [DSN].  The communication
+   resources of the DSN are currently oversubscribed and will probably
+   remain so for the foreseeable future.  Radio contact via the DSN must
+   therefore be carefully scheduled and is often severely limited.
+
+   This over-subscription means that the round-trip times experienced by
+   packets will be affected not only by the signal propagation delay and
+   occultation, but also by the scheduling and queuing delays imposed by
+   the management of Earth-based resources: packets to be sent to a
+   given destination may have to be queued until the next scheduled
+   contact period, which may be hours, days, or even weeks away.
+
+
+
+
+
+
+Burleigh, et al.              Experimental                      [Page 3]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   These operating conditions imply a number of additional constraints
+   on any protocol designed to ensure reliable communication over deep-
+   space links.
+
+   - Long round-trip times mean substantial delay between the
+     transmission of a block of data and the reception of an
+     acknowledgment from the block's destination, signaling arrival of
+     the block.  If LTP postponed transmission of additional blocks of
+     data until it received acknowledgment of the arrival of all prior
+     blocks, valuable opportunities to utilize what little deep-space
+     transmission bandwidth is available would be forever lost.
+     Multiple parallel data block transmission "sessions" must be in
+     progress concurrently in order to avoid under-utilization of the
+     links.
+
+   - Like any reliable transport service employing ARQ, LTP is
+     "stateful".  In order to ensure the reception of a block of data it
+     has sent, LTP must retain for possible retransmission all portions
+     of that block that might not have been received yet.  In order to
+     do so, it must keep track of which portions of the block are known
+     to have been received so far and which are not, together with any
+     additional information needed for purposes of retransmitting part
+     or all of that block.
+
+   - In the IPN, round-trip times may be so long and communication
+     opportunities so brief that a negotiation exchange, such as an
+     adjustment of transmission rate, might not be completed before
+     connectivity is lost.  Even if connectivity is uninterrupted,
+     waiting for negotiation to complete before revising data
+     transmission parameters might well result in costly under-
+     utilization of link resources.
+
+   - Another respect in which LTP differs from TCP is that, while TCP
+     connections are bidirectional (blocks of application data may be
+     flowing in both directions on any single connection), LTP sessions
+     are unidirectional.  This design decision derives from the fact
+     that the flow of data in deep-space flight missions is usually
+     unidirectional.  (Long round-trip times make interactive spacecraft
+     operation infeasible, so spacecraft are largely autonomous and
+     command traffic is very light.)  Bidirectional data flow, where
+     possible, is performed using two unidirectional links in opposite
+     directions and at different data rates.
+
+
+
+
+
+
+
+
+
+Burleigh, et al.              Experimental                      [Page 4]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   - Finally, the problem of timeout interval computation in the
+     environment for which LTP is mainly intended is different from the
+     analogous problem in the Internet.  Since multiple sessions can be
+     conducted in parallel, retardation of transmission on any single
+     session while awaiting a timeout need not degrade communication
+     performance on the association as a whole.  Timeout intervals that
+     would be intolerably optimistic in TCP don't necessarily degrade
+     LTP's bandwidth utilization.
+
+     But the reciprocal half-duplex nature of LTP communication makes it
+     infeasible to use statistical analysis of round-trip history as a
+     means of predicting round-trip time.  The round-trip time for
+     transmitted segment N could easily be orders of magnitude greater
+     than that for segment N-1 if there happened to be a transient loss
+     of connectivity between the segment transmissions.  A different
+     mechanism for timeout interval computation is needed.
+
+2.2.  Why Not TCP or SCTP?
+
+   These environmental characteristics -- long and highly variable
+   delays, intermittent connectivity, and relatively high error rates --
+   make using unmodified TCP for end-to-end communications in the IPN
+   infeasible.  Using the TCP throughput equation from [TFRC] we can
+   calculate the loss event rate (p) required to achieve a given steady-
+   state throughput.  Assuming the minimum RTT to Mars from planet Earth
+   is 8 minutes (one-way speed of light delay to Mars at its closest
+   approach to Earth is 4 minutes), assuming a packet size of 1500
+   bytes, assuming that the receiver acknowledges every other packet,
+   and ignoring negligible higher-order terms in p (i.e., ignoring the
+   second additive term in the denominator of the TCP throughput
+   equation), we obtain the following table of loss event rates required
+   to achieve various throughput values.
+
+      Throughput              Loss event rate (p)
+      ----------              -------------------
+        10 Mbps                  4.68 * 10^(-12)
+         1 Mbps                  4.68 * 10^(-10)
+       100 Kbps                  4.68 * 10^(-8)
+        10 Kbps                  4.68 * 10^(-6)
+
+   Note that although multiple losses encountered in a single RTT are
+   treated as a single loss event in the TCP throughput equation [TFRC],
+   such loss event rates are still unrealistic on deep-space links.
+
+   For the purposes of this discussion, we are not considering the more
+   aggressive TCP throughput equation that characterizes HighSpeed TCP
+   [HSTCP].
+
+
+
+
+Burleigh, et al.              Experimental                      [Page 5]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   The TCP characteristic of an initial three-way handshake for each new
+   connection, followed by slow-start, is a further obstacle, because
+   the delay of the three-way handshake and the additional delay of
+   slow-start could be exorbitant in a long-delay environment.
+
+   The Stream Control Transmission Protocol (SCTP) [SCTP] can multiplex
+   "chunks" (units of application data) for multiple sessions over a
+   single-layer connection (called an 'association' in SCTP terminology)
+   as LTP does, but it still requires multiple round trips prior to
+   transmitting application data for session setup and so clearly does
+   not suit the needs of the IPN operating environment.
+
+3. Protocol Overview
+
+3.1.  Nominal Operation
+
+   The nominal sequence of events in an LTP transmission session is as
+   follows.
+
+   Operation begins when a client service instance asks an LTP engine to
+   transmit a block of data to a remote client service instance.
+
+   LTP regards each block of data as comprising two parts: a "red-part",
+   whose delivery must be assured by acknowledgment and retransmission
+   as necessary, followed by a "green-part" whose delivery is attempted,
+   but not assured.  The length of either part may be zero; that is, any
+   given block may be designated entirely red (retransmission continues
+   until reception of the entire block has been asserted by the
+   receiver) or entirely green (no part of the block is acknowledged or
+   retransmitted).  Thus, LTP can provide both TCP-like and UDP-like
+   functionality concurrently on a single session.
+
+   Note that in a red-green block transmission, the red-part data does
+   NOT have any urgency or higher-priority semantics relative to the
+   block's green-part data.  The red-part data is merely data for which
+   the user has requested reliable transmission, possibly (though not
+   necessarily) data without which the green-part data may be useless,
+   such as an application-layer header or other metadata.
+
+   The client service instance uses the LTP implementation's application
+   programming interface to specify to LTP the identity of the remote
+   client service instance to which the data must be transmitted, the
+   location of the data to be transmitted, the total length of data to
+   be transmitted, and the number of leading data bytes that are to be
+   transmitted reliably as "red" data.  The sending engine starts a
+   transmission session for this block and notifies the client service
+   instance that the session has been started.  Note that
+
+
+
+
+Burleigh, et al.              Experimental                      [Page 6]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   LTP communication session parameters are not negotiated but are
+   instead asserted unilaterally, subject to application-level network
+   management activity; the sending engine does not negotiate the start
+   of the session with the remote client service instance's engine.
+
+   The sending engine then initiates the original transmission: it
+   queues for transmission as many data segments as are necessary to
+   transmit the entire block, within the constraints on maximum segment
+   size imposed by the underlying communication service.  The last
+   segment of the red-part of the block is marked as the end of red-part
+   (EORP) indicating the end of red-part data for the block, and as a
+   checkpoint (identified by a unique checkpoint serial number)
+   indicating that the receiving engine must issue a reception report
+   upon receiving the segment.  The last segment of the block overall is
+   marked end of block (EOB) indicating that the receiving engine can
+   calculate the size of the block by summing the offset and length of
+   the data in the segment.
+
+   LTP is designed to run directly over a data-link layer protocol, but
+   it may instead be deployed directly over UDP in some cases (i.e., for
+   software development or in private local area networks).  In either
+   case, the protocol layer immediately underlying LTP is here referred
+   to as the "local data-link layer".
+
+   At the next opportunity, subject to allocation of bandwidth to the
+   queue into which the block data segments were written, the enqueued
+   segments and their lengths are passed to the local data-link layer
+   protocol (which might be UDP/IP) via the API supported by that
+   protocol, for transmission to the LTP engine serving the remote
+   client service instance.
+
+   A timer is started for the EORP, so that it can be retransmitted
+   automatically if no response is received.
+
+   The content of each local data-link layer protocol data unit (link-
+   layer frame or UDP datagram) is required to be an integral number of
+   LTP segments, and the local data-link layer protocol is required
+   never to deliver incomplete LTP segments to the receiving LTP engine.
+   When the local data-link layer protocol is UDP, the LTP
+   authentication [LTPEXT] extension should be used to ensure data
+   integrity unless the end-to-end path is one in which either the
+   likelihood of datagram content corruption is negligible (as in some
+   private local area networks) or the consequences of receiving and
+   processing corrupt LTP segments are insignificant (as perhaps during
+   software development).  When the LTP authentication extension is not
+
+
+
+
+
+
+Burleigh, et al.              Experimental                      [Page 7]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   used, LTP requires the local data-link layer protocol to perform
+   integrity checking of all segments received; specifically, the local
+   data-link layer protocol is required to detect any corrupted segments
+   that are received and to discard them silently.
+
+   Received segments that are not discarded are passed up to the
+   receiving LTP engine via the API supported by the local data-link
+   layer protocol.
+
+   On reception of the first data segment for the block, the receiving
+   engine starts a reception session for this block and notifies the
+   local instance of the relevant client service that the session has
+   been started.  In the nominal case, it receives all segments of the
+   original transmission without error.  Therefore, on reception of the
+   EORP data segment, it responds by (a) queuing for transmission to the
+   sending engine a report segment indicating complete reception and (b)
+   delivering the received red-part of the block to the local instance
+   of the client service: on reception of each data segment of the
+   green-part, it responds by immediately delivering the received data
+   to the local instance of the client service.
+
+   All delivery of data and protocol event notices to the local client
+   service instance is performed using the LTP implementation's
+   application programming interface.
+
+   Note that since LTP data flows are unidirectional, LTP's data
+   acknowledgments -- "reception reports" -- can't be piggybacked on
+   data segments as in TCP.  They are instead carried in a separate
+   segment type.
+
+   At the next opportunity, the enqueued report segment is immediately
+   transmitted to the sending engine and a timer is started so that the
+   report segment can be retransmitted automatically if no response is
+   received.
+
+   The sending engine receives the report segment, turns off the timer
+   for the EORP, enqueues for transmission to the receiving engine a
+   report-acknowledgment segment, and notifies the local client service
+   instance that the red-part of the block has been successfully
+   transmitted.  The session's red-part transmission has now ended.
+
+   At the next opportunity, the enqueued report-acknowledgment segment
+   is immediately transmitted to the receiving engine.
+
+   The receiving engine receives the report-acknowledgment segment and
+   turns off the timer for the report segment.  The session's red-part
+   reception has now ended and transmission of the block is complete.
+
+
+
+
+Burleigh, et al.              Experimental                      [Page 8]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+3.1.1.  Link State Cues
+
+   Establishing a communication link across interplanetary distances may
+   entail hardware configuration changes based on the presumed
+   operational state of the remote communicating entity, for example:
+
+      o orienting a directional antenna correctly;
+
+      o tuning a transponder to pre-selected transmission and/or
+        reception frequencies; and
+
+      o diverting precious electrical power to the transponder at the
+        last possible moment, and for the minimum necessary length of
+        time.
+
+   We therefore assume that the operating environment in which LTP
+   functions is able to pass information on the link status (termed
+   "link state cues" in this document) to LTP, telling it which remote
+   LTP engine(s) should currently be transmitting to the local LTP
+   engine and vice versa.  The operating environment itself must have
+   this information in order to configure communication link hardware
+   correctly.
+
+3.1.2.  Deferred Transmission
+
+   Link state cues also notify LTP when it is and isn't possible to
+   transmit segments.  In deep-space communications, at no moment can
+   there ever be any expectation of two-way connectivity.  It is always
+   possible for LTP to be generating outbound segments -- in response to
+   received segments, timeouts, or requests from client services -- that
+   cannot immediately be transmitted.  These segments must be queued for
+   transmission at a later time when a link has been established, as
+   signaled by a link state cue.
+
+   In concept, every outbound LTP segment is appended to one of two
+   queues -- forming a queue-set -- of traffic bound for the LTP engine
+   that is that segment's destination.  One such traffic queue is the
+   "internal operations queue" of that queue set; the other is the
+   application data queue for the queue set.  The de-queuing of a
+   segment always implies delivering it to the underlying communication
+   system for immediate transmission.  Whenever the internal operations
+   queue is non-empty, the oldest segment in that queue is the next
+   segment de-queued for transmission to the destination; at all other
+   times, the oldest segment in the application data queue is the next
+   segment de-queued for transmission to the destination.
+
+   The production and enqueuing of a segment and the subsequent actual
+   transmission of that segment are in principle wholly asynchronous.
+
+
+
+Burleigh, et al.              Experimental                      [Page 9]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   In the event that (a) a transmission link to the destination is
+   currently active and (b) the queue to which a given outbound segment
+   is appended is otherwise empty and (c) either this queue is the
+   internal operations queue or else the internal operations queue is
+   empty, the segment will be transmitted immediately upon production.
+   Transmission of a newly queued segment is necessarily deferred in all
+   other circumstances.
+
+   Conceptually, the de-queuing of segments from traffic queues bound
+   for a given destination is initiated upon reception of a link state
+   cue indicating that the underlying communication system is now
+   transmitting to that destination; i.e., the link to that destination
+   is now active.  It ceases upon reception of a link state cue
+   indicating that the underlying communication system is no longer
+   transmitting to that destination; i.e., the link to that destination
+   is no longer active.
+
+3.1.3.  Timers
+
+   LTP relies on accurate calculation of expected arrival times for
+   report and acknowledgment segments in order to know when proactive
+   retransmission is required.  If a calculated time were even slightly
+   early, the result would be costly unnecessary retransmission.  On the
+   other hand, calculated arrival times may safely be several seconds
+   late: the only penalties for late timeout and retransmission are
+   slightly delayed data delivery and slightly delayed release of
+   session resources.
+
+   Since statistics derived from round-trip history cannot safely be
+   used as a predictor of LTP round-trip times, we have to assume that
+   round-trip timing is at least roughly deterministic -- i.e., that
+   sufficiently accurate RTT estimates can be computed individually in
+   real time from available information.
+
+   This computation is performed in two stages:
+
+      - We calculate a first approximation of RTT by simply doubling the
+        known one-way light time to the destination and adding an
+        arbitrary margin for any additional anticipated latency, such as
+        queuing and processing delay at both ends of the transmission.
+        For deep-space operations, the margin value is typically a small
+        number of whole seconds.  Although such a margin is enormous by
+        Internet standards, it is insignificant compared to the two-way
+
+
+
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 10]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+        light time component of round-trip time in deep space.  We
+        choose to risk tardy retransmission, which will postpone
+        delivery of one block by a relatively tiny increment, in
+        preference to premature retransmission, which will unnecessarily
+        consume precious bandwidth and thereby degrade overall
+        performance.
+
+      - Then, to account for the additional delay imposed by interrupted
+        connectivity, we dynamically suspend timers during periods when
+        the relevant remote LTP engines are known to be unable to
+        transmit responses.  This knowledge of the operational state of
+        remote entities is assumed to be provided by link state cues
+        from the operating environment.
+
+   The following discussion is the basis for LTP's expected arrival time
+   calculations.
+
+   The total time consumed in a single "round trip" (transmission and
+   reception of the original segment, followed by transmission and
+   reception of the acknowledging segment) has the following components:
+
+      - Protocol processing time: The time consumed in issuing the
+        original segment, receiving the original segment, generating and
+        issuing the acknowledging segment, and receiving the
+        acknowledging segment.
+
+      - Outbound queuing delay: The delay at the sender of the original
+        segment while that segment is in a queue waiting for
+        transmission, and delay at the sender of the acknowledging
+        segment while that segment is in a queue waiting for
+        transmission.
+
+      - Radiation time: The time that passes while all bits of the
+        original segment are being radiated, and the time that passes
+        while all bits of the acknowledging segment are being radiated.
+        (This is significant only at extremely low data transmission
+        rates.)
+
+      - Round-trip light time: The signal propagation delay at the speed
+        of light, in both directions.
+
+      - Inbound queuing delay: Delay at the receiver of the original
+        segment while that segment is in a reception queue, and delay at
+        the receiver of the acknowledging segment while that segment is
+        in a reception queue.
+
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 11]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+      - Delay in transmission of the original segment or the
+        acknowledging segment due to loss of connectivity -- that is,
+        interruption in outbound link activity at the sender of either
+        segment due to occultation, scheduled end of tracking pass, etc.
+
+   In this context, where errors on the order of seconds or even minutes
+   may be tolerated, protocol processing time at each end of the session
+   is assumed to be negligible.
+
+   Inbound queuing delay is also assumed to be negligible because, even
+   on small spacecraft, LTP processing speeds are high compared to data
+   transmission rates.
+
+   Two mechanisms are used to make outbound queuing delay negligible:
+
+      - The expected arrival time of an acknowledging segment is not
+        calculated until the moment the underlying communication system
+        notifies LTP that radiation of the original segment has begun.
+        All outbound queuing delay for the original segment has already
+        been incurred at that point.
+
+      - LTP's deferred transmission model minimizes latency in the
+        delivery of acknowledging segments (reports and acknowledgments)
+        to the underlying communication system.  That is, acknowledging
+        segments are (in concept) appended to the internal operations
+        queue rather than the application data queue, so they have
+        higher transmission priority than any other outbound segments,
+        i.e., they should always be de-queued for transmission first.
+        This limits outbound queuing delay for a given acknowledging
+        segment to the time needed to de-queue and radiate all
+        previously generated acknowledging segments that have not yet
+        been de-queued for transmission.  Since acknowledging segments
+        are sent infrequently and are normally very small, outbound
+        queuing delay for a given acknowledging segment is likely to be
+        minimal.
+
+   Deferring calculation of the expected arrival time of the
+   acknowledging segment until the moment at which the original segment
+   is radiated has the additional effect of removing from consideration
+   any original segment transmission delay due to loss of connectivity
+   at the original segment sender.
+
+   Radiation delay at each end of the session is simply segment size
+   divided by transmission data rate.  It is insignificant except when
+   the data rate is extremely low (for example, 10 bps), in which case
+   the use of LTP may well be inadvisable for other reasons (LTP header
+   overhead, for example, could be too much under such data rates).
+   Therefore, radiation delay is normally assumed to be negligible.
+
+
+
+Burleigh, et al.              Experimental                     [Page 12]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   We assume that one-way light time to the nearest second can always be
+   known (for example, provided by the operating environment).
+
+   So the initial expected arrival time for each acknowledging segment
+   is typically computed as simply the current time at the moment that
+   radiation of the original segment begins, plus twice the one-way
+   light time, plus 2*N seconds of margin to account for processing and
+   queuing delays and for radiation time at both ends.  N is a parameter
+   set by network management for which 2 seconds seem to be a reasonable
+   default value.
+
+   This leaves only one unknown, the additional round-trip time
+   introduced by loss of connectivity at the sender of the acknowledging
+   segment.  To account for this, we again rely on external link state
+   cues.  Whenever interruption of transmission at a remote LTP engine
+   is signaled by a link state cue, we suspend the countdown timers for
+   all acknowledging segments expected from that engine.  Upon a signal
+   that transmission has resumed at that engine, we resume those timers
+   after (in effect) adding to each expected arrival time the length of
+   the timer suspension interval.
+
+3.2.  Retransmission
+
+   Loss or corruption of transmitted segments may cause the operation of
+   LTP to deviate from the nominal sequence of events described above.
+
+   Loss of one or more red-part data segments other than the EORP
+   segment triggers data retransmission: the receiving engine returns a
+   reception report detailing all the contiguous ranges of red-part data
+   received (assuming no discretionary checkpoints were received, which
+   are described below).  The reception report is normally sent in a
+   single report segment that carries a unique report serial number and
+   the scope of red-part data covered.  For example, if the red-part
+   data covered block offsets [0:1000] and all but the segment in range
+   [500:600] were received, the report segment with a unique serial
+   number (say 100) and scope [0:1000] would carry two report entries:
+   (0:500) and (600:1000).  The maximum size of a report segment, like
+   all LTP segments, is constrained by the data-link MTU; if many non-
+   contiguous segments were lost in a large block transmission and/or
+   the data-link MTU was relatively small, multiple report segments need
+   to be generated.  In this case, LTP generates as many report segments
+   as are necessary and splits the scope of red-part data covered across
+   multiple report segments so that each of them may stand on their own.
+   For example, if three report segments are to be generated as part of
+   a reception report covering red-part data in range [0:1,000,000],
+   they could look like this: RS 19, scope [0:300,000], RS 20, scope
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 13]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   [300,000:950,000], and RS 21, scope [950,000:1,000,000].  In all
+   cases, a timer is started upon transmission of each report segment of
+   the reception report.
+
+   On reception of each report segment, the sending engine responds as
+   follows:
+
+      - It turns off the timer for the checkpoint referenced by the
+        report segment, if any.
+
+      - It enqueues a reception-acknowledgment segment acknowledging the
+        report segment (to turn off the report retransmission timer at
+        the receiving engine).  This segment is sent immediately at the
+        next transmission opportunity.
+
+      - If the reception claims in the report segment indicate that not
+        all data within the scope have been received, it normally
+        initiates a retransmission by enqueuing all data segments not
+        yet received.  The last such segment is marked as a checkpoint
+        and contains the report serial number of the report segment to
+        which the retransmission is a response.  These segments are
+        likewise sent at the next transmission opportunity, but only
+        after all data segments previously queued for transmission to
+        the receiving engine have been sent.  A timer is started for the
+        checkpoint, so that it can be retransmitted automatically if no
+        responsive report segment is received.
+
+      - On the other hand, if the reception claims in the report segment
+        indicate that all data within the scope of the report segment
+        have been received, and the union of all reception claims
+        received so far in this session indicates that all data in the
+        red-part of the block have been received, then the sending
+        engine notifies the local client service instance that the red-
+        part of the block has been successfully transmitted; the
+        session's red-part transmission has ended.
+
+   On reception of a report-acknowledgment segment, the receiver turns
+   off the timer for the referenced report segment.
+
+   On reception of a checkpoint segment with a non-zero report serial
+   number, the receiving engine responds as follows:
+
+      - It returns a reception report comprising as many report segments
+        as are needed in order to report in detail on all data reception
+        within the scope of the referenced report segment, and a timer
+        is started for each report segment.
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 14]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+      - If at this point all data in the red-part of the block have been
+        received, the receiving engine delivers the received block's
+        red-part to the local instance of the client service and, upon
+        reception of reception-acknowledgment segments acknowledging all
+        report segments, the session's red-part reception ends and
+        transmission of the block is complete.  Otherwise, the data
+        retransmission cycle continues.
+
+   Loss of a checkpoint segment or the report segment generated in
+   response causes timer expiry; when this occurs, the sending engine
+   normally retransmits the checkpoint segment.  Similarly, the loss of
+   a report segment or the corresponding report-acknowledgment segment
+   causes the report segment's timer to expire; when this occurs, the
+   receiving engine normally retransmits the report segment.
+
+   Note that the redundant reception of a report segment (i.e., one that
+   was already received and processed by the sender), retransmitted due
+   to loss of the corresponding report-acknowledgment segment for
+   example, causes another report-acknowledgment segment to be
+   transmitted in response but is otherwise ignored.  If any of the data
+   segments retransmitted in response to the original reception of the
+   report segment were lost, further retransmission of those data
+   segments will be requested by the reception report generated in
+   response to the last retransmitted data segment marked as a
+   checkpoint.  Thus, unnecessary retransmission is suppressed.
+
+   Note also that the responsibility for responding to segment loss in
+   LTP is shared between the sender and receiver of a block: the sender
+   retransmits checkpoint segments in response to checkpoint timeouts,
+   and retransmits missing data in response to reception reports
+   indicating incomplete reception, while the receiver retransmits
+   report segments in response to timeouts.  An alternative design would
+   have been to make the sender responsible for all retransmission, in
+   which case the receiver would not expect report-acknowledgment
+   segments and would not retransmit report segments.  There are two
+   disadvantages to this approach:
+
+   First, because of constraints on segment size that might be imposed
+   by the underlying communication service, it is at least remotely
+   possible that the response to any single checkpoint might be multiple
+   report segments.  An additional sender-side mechanism for detecting
+   and appropriately responding to the loss of some proper subset of
+   those reception reports would be needed.  We believe that the current
+   design is simpler.
+
+
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 15]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   Second, an engine that receives a block needs a way to determine when
+   the session can be closed.  In the absence of explicit final report
+   acknowledgment (which entails retransmission of the report in case of
+   the loss of the report acknowledgment), the alternatives are (a) to
+   close the session immediately on transmission of the report segment
+   that signifies complete reception and (b) to close the session on
+   receipt of an explicit authorization from the sender.  In case (a),
+   loss of the final report segment would cause retransmission of a
+   checkpoint by the sender, but the session would no longer exist at
+   the time the retransmitted checkpoint arrived.  The checkpoint could
+   reasonably be interpreted as the first data segment of a new block,
+   most of which was lost in transit, and the result would be redundant
+   retransmission of the entire block.  In case (b), the explicit
+   session termination segment and the responsive acknowledgment by the
+   receiver (needed in order to turn off the timer for the termination
+   segment, which in turn would be needed in case of in-transit loss or
+   corruption of the termination segment) would somewhat complicate the
+   protocol, increase bandwidth consumption, and retard the release of
+   session state resources at the sender.  Here again we believe that
+   the current design is simpler and more efficient.
+
+3.3.  Accelerated Retransmission
+
+   Data segment retransmission occurs only on receipt of a report
+   segment indicating incomplete reception; report segments are normally
+   transmitted only at the end of original transmission of the red-part
+   of a block or at the end of a retransmission.  For some applications,
+   it may be desirable to trigger data segment retransmission
+   incrementally during the course of red-part original transmission so
+   that the missing segments are recovered sooner.  This can be
+   accomplished in two ways:
+
+      - Any red-part data segment prior to the EORP can additionally be
+        flagged as a checkpoint.  Reception of each such "discretionary"
+        checkpoint causes the receiving engine to issue a reception
+        report.
+
+      - At any time during the original transmission of a block's red-
+        part (that is, prior to reception of any data segment of the
+        block's green-part), the receiving engine can unilaterally issue
+        additional asynchronous reception reports.  Note that the CFDP
+        protocol's "Immediate" mode is an example of this sort of
+        asynchronous reception reporting [CFDP].  The reception reports
+        generated for accelerated retransmission are processed in
+        exactly the same way as the standard reception reports.
+
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 16]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+3.4.  Session Cancellation
+
+   A transmission session may be canceled by either the sending or the
+   receiving engine in response either to a request from the local
+   client service instance or to an LTP operational failure as noted
+   earlier.  Session cancellation is accomplished as follows.
+
+   The canceling engine deletes all currently queued segments for the
+   session and notifies the local instance of the affected client
+   service that the session is canceled.  If no segments for this
+   session have yet been sent to or received from the corresponding LTP
+   engine, then at this point the canceling engine simply closes its
+   state record for the session and cancellation is complete.
+
+   Otherwise, a session cancellation segment is queued for transmission.
+   At the next opportunity, the enqueued cancellation segment is
+   immediately transmitted to the LTP engine serving the remote client
+   service instance.  A timer is started for the segment, so that it can
+   be retransmitted automatically if no response is received.
+
+   The corresponding engine receives the cancellation segment, enqueues
+   for transmission to the canceling engine a cancellation-
+   acknowledgment segment, deletes all other currently queued segments
+   for the indicated session, notifies the local client service instance
+   that the block has been canceled, and closes its state record for the
+   session.
+
+   At the next opportunity, the enqueued cancellation-acknowledgment
+   segment is immediately transmitted to the canceling engine.
+
+   The canceling engine receives the cancellation-acknowledgment, turns
+   off the timer for the cancellation segment, and closes its state
+   record for the session.
+
+   Loss of a cancellation segment or of the responsive cancellation-
+   acknowledgment causes the cancellation segment timer to expire.  When
+   this occurs, the canceling engine retransmits the cancellation
+   segment.
+
+4. Security Considerations
+
+   There is a clear risk that unintended receivers can listen in on LTP
+   transmissions over satellite and other radio broadcast data links.
+   Such unintended recipients of LTP transmissions may also be able to
+   manipulate LTP segments at will.
+
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 17]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   Hence, there is a potential requirement for confidentiality,
+   integrity, and anti-DoS (Denial of Service) security services and
+   mechanisms.
+
+   In particular, DoS problems are more severe for LTP compared to
+   typical Internet protocols because LTP inherently retains state for
+   long periods and has very long time-out values.  Further, it could be
+   difficult to reset LTP nodes to recover from an attack.  Thus, any
+   adversary who can actively attack an LTP transmission has the
+   potential to create severe DoS conditions for the LTP receiver.
+
+   To give a terrestrial example: were LTP to be used in a sparse sensor
+   network, DoS attacks could be mounted resulting in nodes missing
+   critical information, such as communications schedule updates.  In
+   such cases, a single successful DoS attack could take a node entirely
+   off the network until the node was physically visited and reset.
+
+   Even for deep-space applications of LTP, we need to consider certain
+   terrestrial attacks, in particular those involving insertion of
+   messages into an ongoing session (usually without having seen the
+   exact bytes of the previous messages in the session).  Such attacks
+   are likely in the presence of firewall failures at various nodes in
+   the network, or due to Trojan software running on an authorized host.
+   Many message insertion attacks will depend on the attacker correctly
+   "guessing" something about the state of the LTP peers, but experience
+   shows that successful guesses are easier than might be thought [DDJ].
+
+   We now consider the appropriate layer(s) at which security mechanisms
+   can be deployed to increase the security properties of LTP, and the
+   trade-offs entailed in doing so.
+
+   The Application layer (above-LTP)
+
+      Higher-layer security mechanisms clearly protect LTP payload, but
+      leave LTP headers open.  Such mechanisms provide little or no
+      protection against DoS type attacks against LTP, but may well
+      provide sufficient data integrity and ought to be able to provide
+      data confidentiality.
+
+   The LTP layer
+
+      An authentication header (similar to IPsec [AH]) can help protect
+      against replay attacks and other bogus packets.  However, an
+      adversary may still see the LTP header of segments passing by in
+      the ether.  This approach also requires some key management
+      infrastructure to be in place in order to provide strong
+      authentication, which may not always be an acceptable overhead.
+      Such an authentication header could mitigate many DoS attacks.
+
+
+
+Burleigh, et al.              Experimental                     [Page 18]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+      Similarly, a confidentiality service could be defined for LTP
+      payload and (some) header fields.  However, this seems less
+      attractive since (a) confidentiality is arguably better provided
+      either above or below the LTP layer, (b) key management for such a
+      service is harder (in a high-delay context) than for an integrity
+      service, and (c) forcing LTP engines to attempt decryption of
+      incoming segments can in itself provide a DoS opportunity.
+
+      Further, within the LTP layer we can make various design decisions
+      to reduce the probability of successful DoS attacks.  In
+      particular, we can mandate that values for certain fields in the
+      header (session numbers, for example) be chosen randomly.
+
+   The Data-link layer (below-LTP)
+
+      The lower layers can clearly provide confidentiality and integrity
+      services, although such security may result in unnecessary
+      overhead if the cryptographic service provided is not required for
+      all data.  For example, it can be harder to manage lower layers so
+      that only the data that requires encryption is in fact encrypted.
+      Encrypting all data could represent a significant overhead for
+      some LTP use cases.  However, the lower layers are often the place
+      where compression and error-correction is done, and so may well
+      also be the optimal place to do encryption since the same issues
+      with applying or not applying the service apply to both encryption
+      and compression.
+
+   In light of these considerations, LTP includes the following security
+   mechanisms:
+
+      The optional LTP Authentication mechanism is an LTP segment
+      extension comprising a ciphersuite identifier and optional key
+      identifier that precede the segment's content, plus an
+      authentication value (either a message authentication code or a
+      digital signature) that follows the segment's content; the
+      ciphersuite ID is used to indicate the length and format of the
+      authentication value.  The authentication mechanism serves to
+      assure the segment's integrity and, depending on the ciphersuite
+      selected and the key management regime, its authenticity.
+
+      The optional LTP cookie mechanism is an LTP segment extension
+      comprising a "cookie" -- a randomly chosen numeric value -- that
+      precedes the segment's content.  By increasing the number of bytes
+      in a segment that cannot be easily predicted by an inauthentic
+      data source, and by requiring that segments lacking the correct
+      values of these bytes be silently discarded, the cookie mechanism
+      increases the difficulty of mounting a successful denial-of-
+      service attack on an LTP engine.
+
+
+
+Burleigh, et al.              Experimental                     [Page 19]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+      The above mechanisms are defined in detail in the LTP extensions
+      document [LTPEXT].
+
+      In addition, the serial numbers of LTP checkpoints and reports are
+      required to be randomly chosen integers, and implementers are
+      encouraged to choose session numbers randomly as well.  This
+      randomness adds a further increment of protection against DoS
+      attacks.  See [PRNG] for recommendations related to randomness.
+
+5.  IANA Considerations
+
+   Please see the IANA Considerations sections of [LTPSPEC] and
+   [LTPEXT].
+
+6.  Acknowledgments
+
+   Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian
+   Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for
+   their thoughts on this protocol and its role in Delay-Tolerant
+   Networking architecture.
+
+   Part of the research described in this document was carried out at
+   the Jet Propulsion Laboratory, California Institute of Technology,
+   under a contract with the National Aeronautics and Space
+   Administration.  This work was performed under DOD Contract DAA-B07-
+   00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870;
+   and NASA Contract NAS7-1407.
+
+   Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers
+   at Ohio University for their suggestions and advice in making various
+   design decisions.  This work was done when Manikantan Ramadas was a
+   graduate student at the EECS Dept., Ohio University, in the
+   Internetworking Research Group Laboratory.
+
+   Part of this work was carried out at Trinity College Dublin as part
+   of the SeNDT contract funded by Enterprise Ireland's research
+   innovation fund.
+
+7.  References
+
+7.1.  Informative References
+
+   [LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
+             Transmission Protocol - Specification", RFC 5326, September
+             2008.
+
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 20]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+   [LTPEXT]  Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
+             Transmission Protocol - Security Extensions", RFC 5327,
+             September 2008.
+
+   [AH]      Kent, S., "IP Authentication Header", RFC 4302, December
+             2005.
+
+   [BP]      Scott, K. and S. Burleigh, "Bundle Protocol Specification",
+             RFC 5050, November 2007.
+
+   [CFDP]    CCSDS File Delivery Protocol (CFDP). Recommendation for
+             Space Data System Standards, CCSDS 727.0-B-2 BLUE BOOK
+             Issue 1, October 2002.
+
+   [DDJ]     I. Goldberg and E. Wagner, "Randomness and the Netscape
+             Browser", Dr. Dobb's Journal, 1996, (pages 66-70).
+
+   [DSN]     Deep Space Mission Systems Telecommunications Link Design
+             Handbook (810-005) web-page,
+             "http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/"
+
+   [DTN]     K. Fall, "A Delay-Tolerant Network Architecture for
+             Challenged Internets", In Proceedings of ACM SIGCOMM 2003,
+             Karlsruhe, Germany, Aug 2003.
+
+   [IPN]     InterPlanetary Internet Special Interest Group web page,
+             "http://www.ipnsig.org".
+
+   [TFRC]    Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
+             Friendly Rate Control (TFRC): Protocol Specification", RFC
+             3448, January 2003.
+
+   [HSTCP]   Floyd, S., "HighSpeed TCP for Large Congestion Windows",
+             RFC 3649, December 2003.
+
+   [SCTP]    Stewart, R., Ed., "Stream Control Transmission Protocol",
+             RFC 4960, September 2007.
+
+   [PRNG]    Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+             "Randomness Requirements for Security", BCP 106, RFC 4086,
+             June 2005.
+
+
+
+
+
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 21]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+Authors' Addresses
+
+   Scott C. Burleigh
+   Jet Propulsion Laboratory
+   4800 Oak Grove Drive
+   M/S: 301-485B
+   Pasadena, CA 91109-8099
+   Telephone: +1 (818) 393-3353
+   Fax: +1 (818) 354-1075
+   EMail: Scott.Burleigh@jpl.nasa.gov
+
+
+   Manikantan Ramadas
+   ISRO Telemetry Tracking and Command Network (ISTRAC)
+   Indian Space Research Organization (ISRO)
+   Plot # 12 & 13, 3rd Main, 2nd Phase
+   Peenya Industrial Area
+   Bangalore 560097
+   India
+   Telephone: +91 80 2364 2602
+   EMail: mramadas@gmail.com
+
+
+   Stephen Farrell
+   Computer Science Department
+   Trinity College Dublin
+   Ireland
+   Telephone: +353-1-896-1761
+   EMail: stephen.farrell@cs.tcd.ie
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 22]
+
+RFC 5325                    LTP - Motivation              September 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78 and at http://www.rfc-editor.org/copyright.html,
+   and except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Burleigh, et al.              Experimental                     [Page 23]
+