tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5326

 
 
 

Licklider Transmission Protocol - Specification

Part 2 of 2, p. 24 to 54
Prev RFC Part

 


prevText      Top      Up      ToC       Page 24 
6.  Internal Procedures

   This section describes the internal procedures that are triggered by
   the occurrence of various events during the lifetime of an LTP
   session.

   Whenever the content of any of the fields of the header of any
   received LTP segment does not conform to this specification document,
   the segment is assumed to be corrupt and MUST be discarded
   immediately and processed no further.  This procedure supersedes all
   other procedures described below.

   All internal procedures described below that are triggered by the
   arrival of a data segment are superseded by the following procedure
   in the event that the client service identified by the data segment
   does not exist at the local LTP engine:

      - If there is no transmission queue-set bound for the block sender
        (possibly because the local LTP engine is running on a receive-
        only device), then the received data segment is simply
        discarded.

      - Otherwise, if the data segment contains data from the red-part
        of the block, a CR with reason-code UNREACH MUST be enqueued for
        transmission to the block sender.  A CR with reason-code UNREACH
        SHOULD be similarly enqueued for transmission to the data sender
        even if the data segment contained data from the green-part of
        the block; note however that (for example) in the case where the
        block receiver knows that the sender of this green-part data is
        functioning in a "beacon" (transmit-only) fashion, a CR need not
        be sent.  In either case, the received data segment is
        discarded.

Top      Up      ToC       Page 25 
6.1.  Start Transmission

   This procedure is triggered by the arrival of a link state cue
   indicating the start of transmission to a specified remote LTP
   engine.

   Response: the de-queuing and delivery of segments to the LTP engine
   specified in the link state cue begins.

6.2.  Start Checkpoint Timer

   This procedure is triggered by the arrival of a link state cue
   indicating the de-queuing (for transmission) of a CP segment.

   Response: the expected arrival time of the RS segment that will be
   produced on reception of this CP segment is computed, and a countdown
   timer is started for this arrival time.  However, if it is known that
   the remote LTP engine has ceased transmission (Section 6.5), then
   this timer is immediately suspended, because the computed expected
   arrival time may require an adjustment that cannot yet be computed.

6.3.  Start RS Timer

   This procedure is triggered by the arrival of a link state cue
   indicating the de-queuing (for transmission) of an RS segment.

   Response: the expected arrival time of the RA (report acknowledgment)
   segment in response to the reception of this RS segment is computed,
   and a countdown timer is started for this arrival time.  However, as
   in Section 6.2, if it is known that the remote LTP engine has ceased
   transmission (Section 6.5), then this timer is immediately suspended,
   because the computed expected arrival time may require an adjustment
   that cannot yet be computed.

6.4.  Stop Transmission

   This procedure is triggered by the arrival of a link state cue
   indicating the cessation of transmission to a specified remote LTP
   engine.

   Response: the de-queuing and delivery to the underlying communication
   system of segments from traffic queues bound for the LTP engine
   specified in the link state cue ceases.

Top      Up      ToC       Page 26 
6.5.  Suspend Timers

   This procedure is triggered by the arrival of a link state cue
   indicating the cessation of transmission from a specified remote LTP
   engine to the local LTP engine.  Normally, this event is inferred
   from advance knowledge of the remote engine's planned transmission
   schedule.

   Response: countdown timers for the acknowledging segments that the
   remote engine is expected to return are suspended as necessary based
   on the following procedure.

   The nominal remote engine acknowledge transmission time is computed
   as the sum of the transmission time of the original segment (to which
   the acknowledging segment will respond) and the one-way light time to
   the remote engine, plus N seconds of "additional anticipated latency"
   (AAL) encompassing anticipated transmission delays other than signal
   propagation time.  N is determined in an implementation-specific
   manner.  For example, when LTP is deployed in deep-space vehicles,
   the one-way light time to the remote engine may be very large while N
   may be relatively small, covering processing and queuing delays.  N
   may be a network management parameter, for which 2 seconds seems like
   a reasonable default value.  As another example, when LTP is deployed
   in a terrestrial "data mule" environment, one-way light time latency
   is effectively zero while N may need to be some dynamically computed
   function of the data mule circulation schedule.

   If the nominal remote engine acknowledge transmission time is greater
   than or equal to the current time (i.e., the acknowledging segment
   may be presented for transmission during the time that transmission
   at the remote engine is suspended), then the countdown timer for this
   acknowledging segment is suspended.

6.6.  Resume Timers

   This procedure is triggered by the arrival of a link state cue
   indicating the start of transmission from a specified remote LTP
   engine to the local LTP engine.  Normally, this event is inferred
   from advance knowledge of the remote engine's planned transmission
   schedule.

   Response: expected arrival time is adjusted for every acknowledging
   segment that the remote engine is expected to return, for which the
   countdown timer has been suspended.  First, the transmission delay
   interval is calculated as follows:

Top      Up      ToC       Page 27 
      - The nominal remote engine acknowledge transmission time is
        computed as the sum of the transmission time of the original
        segment (to which the acknowledging segment will respond) and
        the one-way light time to the remote engine, plus N seconds of
        AAL Section 6.5.

      - If the nominal remote engine acknowledge transmission time is
        greater than the current time, i.e., the remote engine resumed
        transmission prior to presentation of the acknowledging segment
        for transmission, then the transmission delay interval is zero.

      - Otherwise, the transmission delay interval is computed as the
        current time less the nominal remote engine acknowledge
        transmission time.

   The expected arrival time is increased by the computed transmission
   delay interval for each of the suspended countdown timers, and the
   timers are resumed.

6.7.  Retransmit Checkpoint

   This procedure is triggered by the expiration of a countdown timer
   associated with a CP segment.

   Response: if the number of times this CP segment has been queued for
   transmission exceeds the checkpoint retransmission limit established
   for the local LTP engine by network management, then the session of
   which the segment is one token is canceled: the "Cancel Session"
   procedure (Section 6.19) is invoked, a CS with reason-code RLEXC is
   appended to the (conceptual) application data queue, and a
   transmission-session cancellation notice (Section 7.5) is sent back
   to the client service that requested the transmission.

   Otherwise, a new copy of the CP segment is appended to the
   (conceptual) application data queue for the destination LTP engine.

6.8.  Retransmit RS

   This procedure is triggered by either (a) the expiration of a
   countdown timer associated with an RS segment or (b) the reception of
   a CP segment for which one or more RS segments were previously issued
   -- a redundantly retransmitted checkpoint.

   Response: if the number of times any affected RS segment has been
   queued for transmission exceeds the report retransmission limit
   established for the local LTP engine by network management, then the
   session of which the segment is one token is canceled: the "Cancel
   Session" procedure (Section 6.19) is invoked, a CR segment with

Top      Up      ToC       Page 28 
   reason-code RLEXC is queued for transmission to the LTP engine that
   originated the session, and a reception-session cancellation notice
   (Section 7.6) is sent to the client service identified in each of the
   data segments received in this session.

   Otherwise, a new copy of each affected RS segment is queued for
   transmission to the LTP engine that originated the session.

6.9.  Signify Red-Part Reception

   This procedure is triggered by the arrival of a CP segment when the
   EORP for this session has been received (ensuring that the size of
   the data block's red-part is known; this includes the case where the
   CP segment itself is the EORP segment) and all data in the red-part
   of the block being transmitted in this session have been received.

   Response: a red-part reception notice (Section 7.3) is sent to the
   specified client service.

6.10.  Signify Green-Part Segment Arrival

   This procedure is triggered by the arrival of a data segment whose
   content is a portion of the green-part of a block.

   Response: a green-part segment arrival notice (Section 7.2) is sent
   to the specified client service.

6.11.  Send Reception Report

   This procedure is triggered by either (a) the original reception of a
   CP segment (the checkpoint serial number identifying this CP is new)
   (b) an implementation-specific circumstance pertaining to a
   particular block reception session for which no EORP has yet been
   received ("asynchronous" reception reporting).

   Response: if the number of reception problems detected for this
   session exceeds a limit established for the local LTP engine by
   network management, then the affected session is canceled: the
   "Cancel Session" procedure (Section 6.19) is invoked, a CR segment
   with reason-code RLEXC is issued and is, in concept, appended to the
   queue of internal operations traffic bound for the LTP engine that
   originated the session, and a reception-session cancellation notice
   (Section 7.6) is sent to the client service identified in each of the
   data segments received in this session.  One possible limit on
   reception problems would be the maximum number of reception reports
   that can be issued for any single session.

Top      Up      ToC       Page 29 
   If such a limit is not reached, a reception report is issued as
   follows.

   If production of the reception report was triggered by reception of a
   checkpoint:

      - The upper bound of the report SHOULD be the upper bound (the sum
        of the offset and length) of the checkpoint data segment, to
        minimize unnecessary retransmission.  Note: If a discretionary
        checkpoint is lost but subsequent segments are received, then by
        the time the retransmission of the lost checkpoint is received
        the receiver would have segments at block offsets beyond the
        upper bound of the checkpoint.  For deployments where bandwidth
        economy is not critical, the upper bound of a synchronous
        reception report MAY be the maximum upper bound value among all
        red-part data segments received so far in the affected session.

      - If the checkpoint was itself issued in response to a report
        segment, then this report is a "secondary" reception report.  In
        that case, the lower bound of the report SHOULD be the lower
        bound of the report segment to which the triggering checkpoint
        was itself a response, to minimize unnecessary retransmission.
        Note: For deployments where bandwidth economy is not critical,
        the lower bound of the report MAY instead be zero.

      - If the checkpoint was not issued in response to a report
        segment, this report is a "primary" reception report.  The lower
        bound of the first primary reception report issued for any
        session MUST be zero.  The lower bound of each subsequent
        primary reception report issued for the same session SHOULD be
        the upper bound of the prior primary reception report issued for
        the session, to minimize unnecessary retransmission.  Note: For
        deployments where bandwidth economy is not critical, the lower
        bound of every primary reception report MAY be zero.

   If production of the reception report is "asynchronous" as noted
   above:

      - The upper bound of the report MUST be the maximum upper bound
        among all red-part data segments received so far for this
        session.

      - The lower bound of the first asynchronous reception report
        issued for any session for which no other primary reception
        reports have yet been issued MUST be zero.  The lower bound of
        each subsequent asynchronous reception report SHOULD be the
        upper bound of the prior primary reception report issued for the

Top      Up      ToC       Page 30 
        session, to minimize unnecessary retransmission.  Note: For
        deployments where bandwidth economy is not critical, the lower
        bound of every asynchronous reception report MAY be zero.

   In all cases, if the applicable lower bound of the scope of a report
   is determined to be greater than or equal to the applicable upper
   bound (for example, due to out-of-order arrival of discretionary
   checkpoints) then the reception report MUST NOT be issued.
   Otherwise:

   As many RS segments must be produced as are needed in order to report
   on all data reception within the scope of the report, given whatever
   data size constraints are imposed by the underlying communication
   service.  The RS segments are, in concept, appended to the queue of
   internal operations traffic bound for the LTP engine that originated
   the indicated session.  The lower bound of the first RS segment of
   the report MUST be the reception report's lower bound.  The upper
   bound of the last RS segment of the report MUST be the reception
   report's upper bound.

6.12.  Signify Transmission Completion

   This procedure is triggered at the earliest time at which (a) all
   data in the block are known to have been transmitted *and* (b) the
   entire red-part of the block -- if of non-zero length -- is known to
   have been successfully received.  Condition (a) is signaled by
   arrival of a link state cue indicating the de-queuing (for
   transmission) of the EOB segment for the block.  Condition (b) is
   signaled by reception of an RS segment whose reception claims, taken
   together with the reception claims of all other RS segments
   previously received in the course of this session, indicate complete
   reception of the red-part of the block.

   Response: a transmission-session completion notice (Section 7.4) is
   sent to the local client service associated with the session, and the
   session is closed: the "Close Session" procedure (Section 6.20) is
   invoked.

6.13.  Retransmit Data

   This procedure is triggered by the reception of an RS segment.

   Response: first, an RA segment with the same report serial number as
   the RS segment is issued and is, in concept, appended to the queue of
   internal operations traffic bound for the receiver.  If the RS
   segment is redundant -- i.e., either the indicated session is unknown
   (for example, the RS segment is received after the session has been
   completed or canceled) or the RS segment's report serial number

Top      Up      ToC       Page 31 
   matches that of an RS segment that has already been received and
   processed -- then no further action is taken.  Otherwise, the
   procedure below is followed.

   If the report's checkpoint serial number is not zero, then the
   countdown timer associated with the indicated checkpoint segment is
   deleted.

   Note: All retransmission buffer space occupied by data whose
   reception is claimed in the report segment can (in concept) be
   released.

   If the segment's reception claims indicate incomplete data reception
   within the scope of the report segment:

      - If the number of transmission problems for this session exceeds
        a limit established for the local LTP engine by network
        management, then the session of which the segment is one token
        is canceled: the "Cancel Session" procedure (Section 6.19) is
        invoked, a CS with reason-code RLEXC is appended to the
        transmission queue specified in the transmission request that
        started this session, and a transmission-session cancellation
        notice (Section 7.5) is sent back to the client service that
        requested the transmission.  One possible limit on transmission
        problems would be the maximum number of retransmission CP
        segments that may be issued for any single session.

      - If the number of transmission problems for this session has not
        exceeded any limit, new data segments encapsulating all block
        data whose non-reception is implied by the reception claims are
        appended to the transmission queue bound for the receiver.  The
        last -- and only the last -- data segment must be marked as a CP
        segment carrying a new CP serial number (obtained by
        incrementing the last CP serial number used) and the report
        serial number of the received RS segment.

6.14.  Stop RS Timer

   This procedure is triggered by the reception of an RA.

   Response: the countdown timer associated with the original RS segment
   (identified by the report serial number of the RA segment) is
   deleted.  If no other countdown timers associated with RS segments
   exist for this session, then the session is closed: the "Close
   Session" procedure (Section 6.20) is invoked.

Top      Up      ToC       Page 32 
6.15.  Start Cancel Timer

   This procedure is triggered by arrival of a link state cue indicating
   the de-queuing (for transmission) of a Cx segment.

   Response: the expected arrival time of the CAx segment that will be
   produced on reception of this Cx segment is computed and a countdown
   timer for this arrival time is started.  However, if it is known that
   the remote LTP engine has ceased transmission (Section 6.5), then
   this timer is immediately suspended, because the computed expected
   arrival time may require an adjustment that cannot yet be computed.

6.16.  Retransmit Cancellation Segment

   This procedure is triggered by the expiration of a countdown timer
   associated with a Cx segment.

   Response: if the number of times this Cx segment has been queued for
   transmission exceeds the cancellation retransmission limit
   established for the local LTP engine by network management, then the
   session of which the segment is one token is simply closed: the
   "Close Session" procedure (Section 6.20) is invoked.

   Otherwise, a copy of the cancellation segment (retaining the same
   reason-code) is queued for transmission to the appropriate LTP
   engine.

6.17.  Acknowledge Cancellation

   This procedure is triggered by the reception of a Cx segment.

   Response: in the case of a CS segment where there is no transmission
   queue-set bound for the sender (possibly because the receiver is a
   receive-only device), then no action is taken.  Otherwise:

      - If the received segment is a CS segment, a CAS (cancel
        acknowledgment to block sender) segment is issued and is, in
        concept, appended to the queue of internal operations traffic
        bound for the sender.

      - If the received segment is a CR segment, a CAR (cancel
        acknowledgment to block receiver) segment is issued and is, in
        concept, appended to the queue of internal operations traffic
        bound for the receiver.

Top      Up      ToC       Page 33 
   It is possible that the Cx segment has been retransmitted because a
   previous responding acknowledgment CAx (cancel acknowledgment)
   segment was lost, in which case there will no longer be any record of
   the session of which the segment is one token.  If so, no further
   action is taken.

   Otherwise: the "Cancel Session" procedure (Section 6.19) is invoked
   and a reception-session cancellation notice (Section 7.6) is sent to
   the client service identified in each of the data segments received
   in this session.  Finally, the session is closed: the "Close Session"
   procedure (Section 6.20) is invoked.

6.18.  Stop Cancel Timer

   This procedure is triggered by the reception of a CAx segment.

   Response: the timer associated with the Cx segment is deleted, and
   the session of which the segment is one token is closed, i.e., the
   "Close Session" procedure (Section 6.20) is invoked.

6.19.  Cancel Session

   This procedure is triggered internally by one of the other procedures
   described above.

   Response: all segments of the affected session that are currently
   queued for transmission can be deleted from the outbound traffic
   queues.  All countdown timers currently associated with the session
   are deleted.  Note: If the local LTP engine is the sender, then all
   remaining data retransmission buffer space allocated to the session
   can be released.

6.20.  Close Session

   This procedure is triggered internally by one of the other procedures
   described above.

   Response: any remaining countdown timers associated with the session
   are deleted.  The session state record (SSR|RSR) for the session is
   deleted; existence of the session is no longer recognized.

6.21.  Handle Miscolored Segment

   This procedure is triggered by the arrival of either (a) a red-part
   data segment whose block offset begins at an offset higher than the
   block offset of any green-part data segment previously received for
   the same session or (b) a green-part data segment whose block offset
   is lower than the block offset of any red-part data segment

Top      Up      ToC       Page 34 
   previously received for the same session.  The arrival of a segment
   matching either of the above checks is a violation of the protocol
   requirement of having all red-part data as the block prefix and all
   green-part data as the block suffix.

   Response: the received data segment is simply discarded.

   The Cancel Session procedure (Section 6.19) is invoked and a CR
   segment with reason-code MISCOLORED SHOULD be enqueued for
   transmission to the data sender.

   Note: If there is no transmission queue-set bound for the sender
   (possibly because the local LTP engine is running on a receive-only
   device), or if the receiver knows that the sender is functioning in a
   "beacon" (transmit-only) fashion, a CR segment need not be sent.

   A reception-session cancellation notice (Section 7.6) is sent to the
   client service.

6.22.  Handling System Error Conditions

   It is possible (especially for long-lived LTP sessions) that an
   unexpected operating system error condition may occur during the
   lifetime of an LTP session.  An example is the case where the system
   faces severe memory crunch forcing LTP sessions into a scenario
   similar to that of TCP SACK [SACK] reneging.  But unlike TCP SACK
   reception reports, which are advisory, LTP reception reports are
   binding, and reneging is NOT permitted on previously made reception
   claims.

   Under any such irrecoverable system error condition, the following
   response is to be initiated: the Cancel Session procedure (Section
   6.19) is invoked.  If the error condition is observed on the sender,
   a CS segment with reason-code SYS_CNCLD SHOULD be enqueued for
   transmission to the receiver, and a transmission-session cancellation
   notice (Section 7.5) is sent to the client service; on the other
   hand, if it is observed on the receiver, a CR segment with the same
   reason-code SYS_CNCLD SHOULD be enqueued for transmission to the
   sender, and a reception-session cancellation notice (Section 7.6) is
   sent to the client service.

   Note that as in (Section 6.21), if there is no transmission queue-set
   bound for the sender (possibly because the local LTP engine is
   running on a receive-only device), or if the receiver knows that the
   sender of this green-part data is functioning in a "beacon"
   (transmit-only) fashion, a CR segment need not be sent.

Top      Up      ToC       Page 35 
   There may be other implementation-specific limits that may cause an
   LTP implementation to initiate session-cancellation procedures.  One
   such limit is the maximum number of retransmission-cycles seen.  A
   retransmission cycle at the LTP Sender comprises the two related
   events: the transmission of all outstanding CP segments from the
   sender, and the reception of all RS segments issued from the receiver
   in response to those CP segments.  A similar definition would apply
   at the LTP Receiver but relate to the reception of the CP segments
   and transmission of all RS segments in response.  Note that the
   retransmitted CP and RS segments remain part of their original
   retransmission-cycle.  Also, a single CP segment may cause multiple
   RS segments to be generated if a reception report would not fit in a
   single data link-MTU-sized RS segment; all RS segments that are part
   of a reception report belong to the same retransmission cycle to
   which the CP segment belongs.  In the presence of severe channel
   error conditions, many retransmission cycles may elapse before red-
   part transmission is deemed successful; an implementation may
   therefore impose a retransmission-cycle limit to shield itself from a
   resource-crunch situation.  If an LTP sender notices the
   retransmission-cycle limit being exceeded, it SHOULD initiate the
   Cancel Session procedure (Section 6.19), queuing a CS segment with
   reason-code RXMTCYCEXC and sending a transmission-session
   cancellation notice (Section 7.5) to the client service.

7.  Notices to Client Service

   In all cases, the representation of notice parameters is a local
   implementation matter.

7.1.  Session Start

   The Session Start notice returns the session ID identifying a newly
   created session.

   At the sender, the session start notice informs the client service of
   the initiation of the transmission session.  On receiving this notice
   the client service may, for example, release resources of its own
   that are allocated to the block being transmitted, or remember the
   session ID so that the session can be canceled in the future if
   necessary.  At the receiver, this notice indicates the beginning of a
   new reception session, and is delivered upon arrival of the first
   data segment carrying a new session ID.

Top      Up      ToC       Page 36 
7.2.  Green-Part Segment Arrival

   The following parameters are provided by the LTP engine when a green-
   part segment arrival notice is delivered:

      Session ID of the transmission session.

      Array of client service data bytes contained in the data segment.

      Offset of the data segment's content from the start of the block.

      Length of the data segment's content.

      Indication as to whether or not the last byte of this data
      segment's content is also the end of the block.

      Source LTP engine ID.

7.3.  Red-Part Reception

   The following parameters are provided by the LTP engine when a red-
   part reception notice is delivered:

      Session ID of the transmission session.

      Array of client service data bytes that constitute the red-part of
      the block.

      Length of the red-part of the block.

      Indication as to whether or not the last byte of the red-part is
      also the end of the block.

      Source LTP engine ID.

7.4.  Transmission-Session Completion

   The sole parameter provided by the LTP engine when a transmission-
   session completion notice is delivered is the session ID of the
   transmission session.

   A transmission-session completion notice informs the client service
   that all bytes of the indicated data block have been transmitted and
   that the receiver has received the red-part of the block.

Top      Up      ToC       Page 37 
7.5.  Transmission-Session Cancellation

   The parameters provided by the LTP engine when a transmission-session
   cancellation notice is delivered are:

      Session ID of the transmission session.

      The reason-code sent or received in the Cx segment that initiated
      the cancellation sequence.

   A transmission-session cancellation notice informs the client service
   that the indicated session was terminated, either by the receiver or
   else due to an error or a resource quench condition in the local LTP
   engine.  There is no assurance that the destination client service
   instance received any portion of the data block.

7.6.  Reception-Session Cancellation

   The parameters provided by the LTP engine when a reception
   cancellation notice is delivered are:

      Session ID of the transmission session.

      The reason-code explaining the cancellation.

   A reception-session cancellation notice informs the client service
   that the indicated session was terminated, either by the sender or
   else due to an error or a resource quench condition in the local LTP
   engine.  No subsequent delivery notices will be issued for this
   session.

7.7.  Initial-Transmission Completion

   The session ID of the transmission session is included with the
   initial-transmission completion notice.

   This notice informs the client service that all segments of a block
   (both red-part and green-part) have been transmitted.  This notice
   only indicates that original transmission is complete; retransmission
   of any lost red-part data segments may still be necessary.

Top      Up      ToC       Page 38 
8.  State Transition Diagrams

   The following mnemonics have been used in the sender and LTP receiver
   state transition diagrams that follow:

      TE      Timer Expiry
      RDS     Regular Red Data Segment (NOT {CP|EORP|EOB})
      GDS     Regular Green Data Segment (NOT EOB)
      RL EXC  Retransmission Limit Exceeded
      RP        Red-Part
      GP        Green-Part
      FG        Fully-Green

   Note that blocks represented in rectangles, as in

      +---------+
      | FG_XMIT |
      +---------+

   specify actual states in the state-transition diagrams, while blocks
   represented with jagged edges, as in

       /\/\/\/\
      | Cncld |
       \/\/\/\/

   are either pointers to a state or place-holders for sequences of
   state transitions.

Top      Up      ToC       Page 39 
8.1.  Sender
                 LTP Sender State Transition Diagram

                                  /\/\/\/\
                                 | Cncld |
                                  \/\/\/\/
                       +--------+    |     +------+
              Rcv CR;  |        V    V     V      | Rcv RS;
              Snd CAR  |       +-------------+    | Snd RA
                       +-------+   CLOSED    +----+
 +---------------------------->+------+------+
 |                                    | Blk. Trans. Req
 |                       Zero RP      +
 |  Xmit     ________________________/ \  Non-Zero RP
 |  GDS;    /                           \
 | +---+   |       +------------------+  |  +------+
 | |   V   V       |   /\/\   Rcv RS  V  V  V      |
 | |  +---------+  +<-| RX |<---+   +---------+    |
 | +<-+ FG_XMIT |  |   \/\/     +---+         +--->+ Xmit RDS;
 |    +----+----+  |                | RP_XMIT |    |
 |         |       |   /\/\     +---+         +--->+ Xmit {RDS, CP};
 +<--------+       +<-| CP |<---+   +-----+---+      Start CP Tmr
 |    Xmit             \/\/   CP TE       |    \
 | {GDS, EOB};                            |     |
 |                  Xmit {RDS, CP, EORP}; |     +-------+
 |                  Start CP Tmr          |             |
 |                                        |             |
 |                 +------------------+   |  +---+      | Xmit {RDS,
 |                 |   /\/\  Rcv RS   V   V  V   |      | CP, EORP,
 |                 +<-| RX |<---+   +---------+  |      | EOB};
 |                 |   \/\/     +---+         |  |      | Start
 |                 |                | GP_XMIT +->+      | CP Tmr
 |                 |   /\/\     +---+         | Xmit    |
 |                 +<-| CP |<---+   +-----+---+ GDS;    |
 |                     \/\/  CP TE        |             |
 |                                        |             |
 |                       Xmit {GDS, EOB}; |   +---------+
 |                                        |   |
 |                 +------------------+   |   |
 |                 |   /\/\  Rcv RS   V   V   V
 |                 +<-| RX |<---+   +-------------+
 |                 |   \/\/     +---+             |
 |                 |                | WAIT_RP_ACK |
 |                 |   /\/\     +---+             |
 |                 +<-| CP |<---+   +-----+-------+
 |                     \/\/  CP TE        | RP acknowledged fully;
 |                                        V
 +----------------------------------------+

Top      Up      ToC       Page 40 
          LTP Sender State Transition Diagram (contd.)

         /\/\                               /\/\
         |CP|                               |CX |
         \/\/                               \/\/
          | |                                 | Snd CS,
          | | RL EXC;                         | Start CS Tmr;
          | |                                 |
          | |        /\/\                     |  +---+
          | +------>| CX |                    V  V   |
          |          \/\/                +---------+ | CS TE,
          |                              | CS_SENT | | RL NOT EXC;
          V  RL NOT EXC;                 +-+--+--+-+ | Rxmt CS,
             Rxmt CP,                      |  |  |   | Restart
             Start CP Tmr;         CS TE,  |  |  +---+ CS Tmr
                                   RL EXC; |  |
                                           |  | Rcv CAS;
                                           V  V
                                           /\/\/\/\
                                          | Cncld  |
                                           \/\/\/\/

             /\/\
            | RX |
             \/\/
               |  Cncl CP Tmr (if any)
               V  Snd RA
         +---------+                                +----+
         | CHK_RPT |                                |    |
         +-+--+----+       RP in scope              V    |
           |  |     \     NOT rcvd. fully   +---------+  | Rxmt
 Redundant |  | RP   +--------------------->| RP_RXMT |  | missing
 RS rcvd;  |  | in scope                    +----+--+-+  | RDS;
           |  | rcvd. fully                      |  |    |
           V  V                    Rxmt last     |  +----+
                                   missing RDS   |
                                   (marked CP)   |
                                   Start CP Tmr; |
                                                 V

   Asynchronous cancel request may be received from the local client
   service while the LTP sender is in any of the states shown.  If it
   was not already in the sequence of state transitions beginning at the
   CX marker, the internal procedure Cancel Session (Section 6.19) is
   followed, and the LTP sender moves from its current state into the
   sequence beginning at the CX marker initiating session cancellation
   with reason-code USR_CNCLD.  From the CX marker, the CS segment with
   appropriate reason-code (USR_CNCLD or RLEXC depending on how the CX

Top      Up      ToC       Page 41 
   sequence was entered) is queued for transmission to the LTP receiver
   and the sender enters the Cancel-from-Sender Sent (CS_SENT) state.
   The internal procedure Start Cancel Timer (Section 6.15) is started
   upon receiving a link state cue indicating the beginning of
   transmission of the CS segment.  Upon receiving the acknowledging CAS
   segment from the receiver, the LTP sender moves to the CLOSED state
   (via the 'Cncld' pointer).  If the CS timer expires, the internal
   procedure Retransmit Cancellation Segment (Section 6.16) is followed:

      - If the network management set retransmission limit is exceeded,
        the session is simply closed and the LTP sender follows the
        Cncld marker to the CLOSED state.  If the retransmission limit
        is not exceeded however, the CS segment is queued for a
        retransmission and the LTP sender stays in the CS_SENT state.
        The CS timer is started upon receiving a link state cue
        indicating the beginning of actual transmission according to the
        internal procedure Start Cancel Timer (Section 6.15).

   Asynchronous cancel request may also be received from the receiver
   LTP in the form of a CR segment when the LTP sender is in any of the
   states.  Upon receiving such a CR segment, the internal procedure
   Acknowledge Cancellation (Section 6.17) is invoked: The LTP sender
   sends a CAR segment in response and returns to the CLOSED state.

   The LTP sender stays in the CLOSED state until receiving a Block
   Transmission Request (Blk. Trans. Req) from the client service
   instance.  Upon receiving the request, it moves to either the Fully
   Green Transmission State (FG_XMIT) if no portion of the block was
   requested to be transmitted as red or to the Red-Part Transmission
   State (RP_XMIT) state if a non-zero block-prefix was requested to be
   transmitted red.

   In the FG_XMIT state, the block is segmented as multiple green LTP
   data segments respecting the link MTU size and the segments are
   queued for transmission to the remote engine.  The last such segment
   is marked as EOB, and the LTP sender returns to the CLOSED state
   after queuing it for transmission.

   Similarly, from the RP_XMIT state, multiple red data segments are
   queued for transmission, respecting the link MTU size.  The sender
   LTP may optionally mark some of the red data segments as asynchronous
   checkpoints; the internal procedure Start Checkpoint Timer (Section
   6.2) is followed upon receiving a link state cue indicating the
   transmission of the asynchronous checkpoints.  If the block
   transmission request comprises a non-zero green part, the LTP sender
   marks the last red data segment as CP and EORP, and after queuing it
   for transmission, moves to the Green Part Transmission (GP_XMIT)
   state.  If the block transmission request was fully red however, the

Top      Up      ToC       Page 42 
   last red data segment is marked as CP, EORP, and EOB and the sender
   LTP moves directly to the Wait-for-Red-Part-Acknowledgment
   (WAIT_RP_ACK) state.  In both of the above state-transitions, the
   internal procedure Start Checkpoint Timer (Section 6.2) is followed
   upon receiving a link state cue indicating the beginning of
   transmission of the queued CP segments.  In the GP_XMIT state, the
   green-part of the block is segmented as green data segments and
   queued for transmission to the LTP receiver; the last green segment
   of the block is additionally marked as EOB, and after queueing it for
   transmission the LTP sender moves to the WAIT_RP_ACK state.

   While the LTP sender is at any of the RP_XMIT, GP_XMIT, or
   WAIT_RP_ACK states, it might be interrupted by the occurrence of the
   following events:

      1. An RS might be received from the LTP receiver (either in
         response to a previously transmitted CP segment or sent
         asynchronously for accelerated retransmission).  The LTP sender
         then moves to perform the sequence of state transitions
         beginning at the RX marker (second part of the diagram), and
         retransmits data if necessary, illustrating the internal
         procedure Retransmit Data (Section 6.13):

         First, if the RS segment had a non-zero CP serial number, the
         corresponding CP timer is canceled.  Then an RA segment
         acknowledging the received RS segment is queued for
         transmission to the LTP receiver and the LTP sender moves to
         the Check Report state (CHK_RPT).  If the RS segment was
         redundantly transmitted by the LTP receiver (possibly because
         either the last transmitted RA segment got lost or the RS
         segment timer expired prematurely at the receiver), the LTP
         sender does nothing more and returns back to the interrupted
         state.  Similarly, if all red data within the scope of the RS
         segment is reported as received, there is no work to be done
         and the LTP sender returns to the interrupted state.  However,
         if the RS segment indicated incomplete reception of data within
         its scope, the LTP sender moves to the Red-Part Retransmit
         state (RP_RXMT) where missing red data segments within scope
         are queued for transmission.  The last such segment is marked
         as a CP, and the LTP sender returns to the interrupted state.
         The internal procedure (Section 6.2) is followed upon receiving
         a link state cue indicating the beginning of transmission of
         the CP segment.

      2. A previously set CP timer might expire.  Now the LTP sender
         follows the states beginning at the CP marker (second part of
         the diagram), and follows the internal procedure Retransmit
         Checkpoint (Section 6.7):

Top      Up      ToC       Page 43 
         If the CP Retransmission Limit set by network management for
         the session has been exceeded, the LTP sender proceeds towards
         canceling the session (with reason-code RLEXC) as indicated by
         the sequence of state transitions following the CX marker.
         Otherwise (if the Retransmission Limit is not exceeded yet),
         the CP segment is queued for retransmission and the LTP sender
         returns to the interrupted state.  The internal procedure Start
         Checkpoint Timer (Section 6.2) is started again upon receiving
         a link state cue indicating the beginning of transmission of
         the segment.

   The LTP sender stays at the WAIT_RP_ACK state after reaching it until
   the red-part data is fully acknowledged as received by the receiver
   LTP, and then returns to the CLOSED state following the internal
   procedure Close Session (Section 6.20).

   Note that while at the CLOSED state, the LTP sender might receive an
   RS segment (if the last transmitted RA segment before session close
   got lost or if the LTP receiver retransmitted the RS segment
   prematurely), in which case it retransmits an acknowledging RA
   segment and stays in the CLOSED state.  If the session was canceled
   by the receiver by issuing a CR segment, the receiver may retransmit
   the CR segment (either prematurely or because the acknowledging CAR
   segment got lost).  In this case, the LTP sender retransmits the
   acknowledging CAR segment and stays in the CLOSED state.

Top      Up      ToC       Page 44 
8.2.  Receiver
                  LTP Receiver State Transition Diagram

                                             /\/\/\/\
                          +----+       +----+ Cncld  |
                  Rcv CS; |    V       V     \/\/\/\/
                  Snd CAS |  +-------------+
                          +--+    CLOSED   +<--------------------------+
                             +------+------+                           |
                            +----+  | Rcv first DS                     |
                 Rcv RA;    |    V  V                                  |
                Cncl RS Tmr |   +--------+                             |
                            +---+ DS_REC |                             |
 +----------------------------->+-+--+-+-+<----------------------+---+ |
 |          Svc. does not exist   |  | | RS TE                   |   | |
 |   /\/\  or Rcv miscolored seg. |  | |               /\/\      |   | |
 |  | CX |<-----------------------+  | +------------->| RX |---->+   | |
 |   \/\/                            |                 \/\/          | |
 |                        Rcv RDS;   |   Rcv GDS;                    | |
 |                       +-----------+------------+                  | |
 |                       V                        V                  | |
 |   /\/\  RS TE +--------------+             +--------+             | |
 +<-| RX |<------+    RCV_RP    |             | RCV_GP |             | |
 |   \/\/        +-+----+--+--+-+             +--+-+-+-+             | |
 |                 |    |  |  |                  | | |               | |
 |    Rcvd RDS;    |    |  |  | Rcvd {RDS, CP,   | | | RS TE  /\/\   | |
 |                 |    |  |  | EORP, EOB};      | | +------>| RX |->+ |
 +<----------------+    |  |  | Snd RS,          | |          \/\/   | |
 |                      |  |  | Start RS Tmr     | | Rcvd GDS;       | |
 | Rcvd {RDS, CP};      |  |  |                  | +---------------->+ |
 | Snd RS, Start RS Tmr |  |  +-------+    +-----+                     |
 +<---------------------+  |          |    | Rcvd {GDS, EOB};          |
 |                         |          |    |                           |
 |                         | +-----+  |    |   +------+                |
 | Rcvd {RDS, CP, EORP};   | |     V  V    V   V      |                |
 | Snd RS, Start RS Tmr    | |   +----------------+   | Rcv RDS;       |
 |                         | |   |                +-->+                |
 |                         | |   |   WAIT_RP_REC  |   | Rcv {RDS, CP}; |
 |                         | |   |                +-->+ Snd RS, Start  |
 +<------------------------+ |   +---+--+-+-+-----+   |        RS Tmr  |
                             | RS TE |  | | | Rcv RA; |                |
                             |       V  | | | Cncl    |                |
                             |    /\/\  | | | RS Tmr  |                |
                             +---| RX | | | +-------->+                |
                                  \/\/  | |                            |
          /\/\                          | |                            |
         | CX |<------------------------+ |  RP rcvd. fully            |
          \/\/      Rcv miscolored seg.   +--------------------------->+

Top      Up      ToC       Page 45 
 Receiver State Transition Diagram (contd.)

               /\/\
              | RX |
               \/\/
               |  |
               |  | RL EXC;    /\/\
  RL NOT EXC;  |  +---------->| CX |
  Rxmt RS,     |               \/\/
  Start RS Tmr |
               V

               /\/\
              | CX |
               \/\/
                 | Snd CR,
                 | Start CR Tmr;
                 |
                 |  +----+
                 V  V    |
             +---------+ | CR TE,
             | CR_SENT | | RL NOT EXC;
             +-+--+--+-+ | Rxmt CR,
               |  |  |   | Restart
       CR TE,  |  |  +---+ CR Tmr
       RL EXC; |  |
               |  | Rcv CAR;
               V  V
               /\/\/\/\
              | Cncld  |
               \/\/\/\/

   Asynchronous cancel requests are handled in a manner similar to the
   way they are handled in the LTP sender.  If the cancel request was
   made from the local client service instance and the LTP receiver was
   not already in the CR_SENT state, a CR segment with reason-code
   USR_CNCLD SHOULD be sent to the LTP sender following the sequence of
   state transitions beginning at the CX marker as described above.  If
   the asynchronous cancel request is received from the LTP sender, a
   CAS segment is sent and the LTP receiver moves to the CLOSED state
   (independent of the state the LTP receiver may be in).

   The LTP receiver begins at the CLOSED state and enters the Data
   Segment Reception (DS_REC) state upon receiving the first data
   segment.  If the client service ID referenced in the data segment was
   non-existent, a Cx segment with reason-code UNREACH SHOULD be sent to
   the LTP sender via the Cancellation sequence beginning with the CX
   marker (second part of the diagram).  If the received segment was

Top      Up      ToC       Page 46 
   found to be miscolored, the internal procedure Handle Miscolored
   Segment (Section 6.21) is followed, and a CX segment with reason-code
   MISCOLORED SHOULD be sent to the LTP sender with the Cancellation
   sequence beginning with the CX marker.

   Otherwise, the LTP receiver enters the Receive Red-Part state
   (RCV_RP) or the Receive Green-Part state (RCV_GP) depending on
   whether the segment received was red or green, respectively.

   In the RCV_RP state, a check is made of the nature of the received
   red DS.  If the segment was a regular red data segment, the receiver
   LTP just returns to the DS_REC state.  For red data segments marked
   also as CP and as CP & EORP, a responding RS segment is queued for
   transmission to the sender following either the internal procedure
   Retransmit RS (Section 6.8) or Send Reception Report (Section 6.11)
   depending on whether the CP segment was a retransmission (an RS
   segment corresponding to the checkpoint serial number in the CP
   segment was previously issued) or not, respectively.  The LTP
   receiver then returns to the DS_REC state.  If the block transmission
   was fully red and the segment was marked as CP, EORP, and EOB, the
   LTP receiver enters the Wait-for-Red-Part-Reception state
   (WAIT_RP_REC).  In all cases, the internal procedure Start RS Timer
   (Section 6.3) is followed upon receiving link state cues indicating
   the beginning of transmission of the RS segments.

   In the RCV_GP state, if the received green data segment was not
   marked EOB, the LTP receiver returns to the DS_REC state.  Otherwise,
   it enters the WAIT_RP_REC state to receive the red-part of the block
   fully.

   A previously set RS timer may expire and interrupt the LTP receiver
   while in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC state.  If so,
   the internal procedure Retransmit RS (Section 6.8) is followed as
   illustrated in the states beginning at the RX marker (shown in the
   second part of the diagram) before returning to the interrupted
   state:

      - A check is made here to see if the retransmission limit set by
        the network management has been exceeded in the number of RSs
        sent in the session.  If so, a CR segment with reason-code RLEXC
        SHOULD be sent to the LTP sender and the sequence indicated by
        the CX marker is followed.  Otherwise, the RS segment is queued
        for retransmission and the associated RS timer is started
        following the internal procedure Start RS Timer (Section 6.3)
        upon receiving a link state cue indicating the beginning of its
        transmission.

Top      Up      ToC       Page 47 
   The LTP receiver may also receive RA segments from the sender in
   response to the RS segments sent while in the DS_REC state.  If so,
   then the RS timer corresponding to the report serial number mentioned
   in the RA segment is canceled following the internal procedure Stop
   RS Timer (Section 6.14).

   The LTP receiver stays in the WAIT_RP_REC state until the entire red-
   part of the block is received, and moves to the CLOSED state upon
   full red-part reception.  In this state, a check is made upon
   reception of every red-part data segment to see if it is at a block
   offset higher than any green-part data segment received.  If so, the
   internal procedure Handle Miscolored Segment (Section 6.21) is
   invoked and the sequence of state transitions beginning with the CX
   marker is followed; a CX segment with reason-code MISCOLORED SHOULD
   be sent to the LTP sender with the Cancellation sequence beginning
   with the CX marker.

   Note that if there were no red data segments received in the session
   yet, including the case where the session was indeed fully green or
   the pathological case where the entire red-part of the block gets
   lost but at least the green data segment marked EOB is received (the
   LTP receiver has no indication of whether the session had a red-part
   transmission), the LTP receiver assumes the "RP rcvd. fully"
   condition to be true and moves to the CLOSED state from the
   WAIT_RP_REC state.

   In the WAIT_RP_REC state, the LTP receiver may receive the
   retransmitted red data segments.  Upon receiving red data segments
   marked CP, it queues the responding RS segment for transmission based
   on either internal procedure Retransmit RS (Section 6.8) or Send
   Reception Report (Section 6.11) depending on whether the CP was found
   to be a retransmission or not, respectively.  The internal procedure
   Start RS Timer is invoked upon receiving a link state cue indicating
   the beginning of transmission of the RS segment.  If an RA segment is
   received, the RS timer corresponding to the report segment mentioned
   is canceled and the LTP receiver stays in the state until the entire
   red-part is received.

   In the sequence of state transitions beginning at the CX marker, the
   CR segment with the given reason-code (depending on how the sequence
   is entered) is queued for transmission, and the CR timer is started
   upon reception of the link state cue indicating actual transmission
   following the internal procedure Start Cancel Timer (Section 6.15).
   If the CAR segment is received from the LTP sender, the LTP receiver
   returns to the CLOSED state (via the Cncld marker) following the
   internal procedure Stop Cancel Timer (Section 6.18).  If the CR timer
   expires asynchronously, the internal procedure Retransmit
   Cancellation Segment (Section 6.16) is followed:

Top      Up      ToC       Page 48 
      - A check is made to see if the retransmission limit set by the
        network management for the number of CR segments per session has
        been exceeded.  If so, the LTP receiver returns to the CLOSED
        state following the Cncld marker.  Otherwise, a CR segment is
        scheduled for retransmission with the CR timer being started
        following the internal procedure Start Cancel Timer (Section
        6.15) upon reception of a link state cue indicating actual
        transmission.

   The LTP receiver might also receive a retransmitted CS segment at the
   CLOSED state (either if the CAS segment previously transmitted was
   lost or if the CS timer expired prematurely at the LTP sender).  In
   such a case, the CAS is scheduled for retransmission.

9.  Security Considerations

9.1.  Denial of Service Considerations

   Implementers SHOULD consider the likelihood of the following Denial
   of Service (DoS) attacks:

      - A fake Cx could be inserted, thus bringing down a session.

      - Various acknowledgment segments (RA, RS, etc.) could be deleted,
        causing timers to expire, and having the potential to disable
        communication altogether if done with a knowledge of the
        communications schedule.  This could be achieved either by
        mounting a DoS attack on a lower-layer service in order to
        prevent it from sending an acknowledgment segment, or by simply
        jamming the transmission (all of which are more likely for
        terrestrial applications of LTP).

      - An attacker might also corrupt some bits, which is tantamount to
        deleting that segment.

      - An attacker may flood an LTP engine with segments for the
        internal operations queue and prevent transmission of legitimate
        data segments.

Top      Up      ToC       Page 49 
      - An attacker could attempt to fill up the storage in an engine by
        sending many large messages to it.  In terrestrial LTP
        applications, this may be much more serious since spotting the
        additional traffic may not be possible from any network
        management point.

   If any of the above DoS attacks is likely, then one or more of the
   following anti-DoS mechanisms ought to be employed:

      - Session numbers SHOULD be partly random making it harder to
        insert valid segments.

      - An engine that suspects that either it or its peer is under DoS
        attack could frequently checkpoint its data segments (if it were
        the sender) or send asynchronous RSs (if it were the receiver),
        thus eliciting an earlier response from its peer or timing out
        earlier due to the failure of an attacker to respond.

      - Serial numbers (checkpoint serial numbers, report serial
        numbers) MUST begin each session anew using random numbers
        rather than from 0.

      - The authentication header [LTPEXT].

9.2.  Replay Handling

   The following algorithm is given as an example of how an LTP
   implementation MAY handle replays.

   1. On receipt of an LTP segment, check against a cache for replay.
      If this is a replay segment and if a pre-cooked response is
      available (stored from the last time this segment was processed),
      then send the pre-cooked response.  If there is no pre-cooked
      response, then silently drop the inbound segment.  This can all be
      done without attempting to decode the buffer.

   2. If the inbound segment does not decode correctly, then silently
      drop the segment.  If the segment decodes properly, then add its
      hash to the replay cache and return a handle to the entry.

   3. For those cases where a pre-cooked response should be stored,
      store the response using the handle received from the previous
      step.  These cases include:

      (a) when the inbound packet is a CP segment, the RS segment sent
          in response gets stored as pre-cooked,

Top      Up      ToC       Page 50 
      (b) when the Incoming packet is an RS segment, the RA segment is
          stored as pre-cooked, and

      (c) when the incoming packet is a Cx segment, the CAx segment sent
          in response gets stored pre-cooked.

   4. Occasionally clean out the replay cache -- how frequently this
      happens is an implementation issue.

   The downside of this algorithm is that receiving a totally bogus
   segment still results in a replay cache search and attempted LTP
   decode operation.  It is not clear that it is possible to do much
   better though, since all an attacker would have to do to get past the
   replay cache would be to tweak a single bit in the inbound segment
   each time, which is certainly cheaper than the hash+lookup+decode
   combination, though also certainly more expensive than simply sending
   the same octets many times.

   The benefit of doing this is that implementers no longer need to
   analyze many bugs/attacks based on replaying packets, which in
   combination with the use of LTP authentication should defeat many
   attempted DoS attacks.

9.3.  Implementation Considerations

   SDNV

      Implementations SHOULD make sanity checks on SDNV length fields
      and SHOULD check that no SDNV field is too long when compared with
      the overall segment length.

      Implementations SHOULD check that SDNV values are within suitable
      ranges where possible.

   Byte ranges

      Various report and other segments contain offset and length
      fields.  Implementations MUST ensure that these are consistent and
      sane.

   Randomness

      Various fields in LTP (e.g., serial numbers) MUST be initialized
      using random values.  Good sources of randomness that are not
      easily guessable SHOULD be used [ESC05].  The collision of random
      values is subject to the birthday paradox, which means that a
      collision is likely after roughly the square root of the space has
      been seen (e.g., 2^16 in the case of a 32-bit random value).

Top      Up      ToC       Page 51 
      Implementers MUST ensure that they use sufficiently long random
      values so that the birthday paradox doesn't cause a problem in
      their environment.

10.  IANA Considerations

10.1.  UDP Port Number for LTP

   The UDP port number 1113 with the name "ltp-deepspace" has been
   reserved for LTP deployments.  An LTP implementation may be
   implemented to operate over UDP datagrams using this port number for
   study and testing over the Internet.

10.2.  LTP Extension Tag Registry

   The IANA has created and now maintains a registry for known LTP
   Extension Tags (as indicated in Section 3.1).  The registry has been
   populated using the initial values given in Section 3.1 above.  IANA
   may assign LTP Extension Tag values from the range 0x02-0xAF
   (inclusive) using the Specification Required rule [GUIDE].  The
   specification concerned can be an RFC (whether Standards Track,
   Experimental, or Informational), or a specification from any other
   standards development organization recognized by IANA or with a
   liaison with the IESG, specifically including CCSDS
   (http://www.ccsds.org/).  Any use of Reserved values (0xB0-0xBF
   inclusive) requires an update this specification.

11.  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, Dovel Myers, and
   Jayram Deshpande 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.

Top      Up      ToC       Page 52 
   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.

12.  References

12.1.  Normative References

   [B97]    Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

   [GUIDE]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
            2008.

   [LTPMTV] Burleigh, S., Ramadas, M., and S. Farrell,"Licklider
            Transmission Protocol - Motivation", RFC 5325, September
            2008.

   [LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
            Transmission Protocol - Security Extensions", RFC 5327,
            September 2008.

12.2. Informative References

   [ASN1]   Abstract Syntax Notation One (ASN.1). ASN.1 Encoding Rules:
            Specification of Basic Encoding Rules (BER), Canonical
            Encoding Rules (CER), and Distinguished Encoding Rules
            (DER). ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002.

   [BP]     Scott, K. and S. Burleigh, "Bundle Protocol Specification",
            RFC 5050, November 2007.

   [DTN]    K. Fall, "A Delay-Tolerant Network Architecture for
            Challenged Internets", In Proceedings of ACM SIGCOMM 2003,
            Karlsruhe, Germany, Aug 2003.

   [ESC05]  D. Eastlake, J. Schiller and S. Crockerr, "Randomness
            Recommendations for Security", RFC 4086, June 2005.

   [SACK]   M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP
            Selective Acknowledgement Options", RFC 2018, October 1996.

Top      Up      ToC       Page 53 
Authors' Addresses

   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

   Scott C. Burleigh
   Jet Propulsion Laboratory
   4800 Oak Grove Drive
   M/S: 301-490
   Pasadena, CA 91109-8099
   Telephone: +1 (818) 393-3353
   Fax: +1 (818) 354-1075
   EMail: Scott.Burleigh@jpl.nasa.gov

   Stephen Farrell
   Computer Science Department
   Trinity College Dublin
   Ireland
   Telephone: +353-1-896-1761
   EMail: stephen.farrell@cs.tcd.ie

Top      Up      ToC       Page 54 
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.