RFC 5326
Licklider Transmission Protocol - Specification
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.
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.
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:
- 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
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.
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
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
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.
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.
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
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.
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.
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.
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.
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.
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 +----------------------------------------+
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
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
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):
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.
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. +--------------------------->+
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
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.
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:
- 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.
- 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,
(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).
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.
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.
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
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.