WDIFF

draft-irtf-dtnrg-ltp-01.txt-143214.txt --> draft-irtf-dtnrg-ltp-01.txt

Internet Draft NASA/Jet Propulsion Laboratory
<draft-irtf-dtnrg-ltp-01.txt> M. Ramadas
May
July 2004 Ohio University
Expires November 2004 January 2005 S. Farrell
Trinity College Dublin

Licklider Transmission Protocol

Status of this Memo

This document is an Internet-Draft

By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and is any of which we become aware will be
disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026. RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as a "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
http://www.ietf.org/shadow.html

Discussions on this internet-draft are being made in the Delay
Tolerant Networking Research Group (DTNRG) mailing list. More
information can be found in the DTNRG web-site at
http://www.dtnrg.org

Abstract

This document describes the Licklider Transmission Protocol (LTP)
designed to provide retransmission-based reliability over links
characterized by in
challenged internet environments exhibiting extremely long message
round-trip times (RTTs).
These long round-trip times may result from the use of half-duplex
channels or from data propagation delays that are so lengthy as to
simulate half-duplex transmission. Such environments are not well
served by TCP, which depends on relatively short round-trip times for
retransmission buffer management, timely flow control, (RTTs), frequent interruptions in connectivity, and
negotiation of other connection parameters.

Burleigh et al. Expires - November 2004 [Page 1]

Internet Draft Licklider Transmission Protocol May 2004

Communication
high bit error rates. Since communication across interplanetary
space is the most prominent example of this sort of environment, and LTP
is in fact adapted from
existing communication technologies designed to support deep space
flight missions. It is principally aimed at supporting "long-haul" reliable transmission

Burleigh et al. Expires - January 2005 [Page 1]
Internet Draft Licklider Transmission Protocol July 2004

in the interplanetary space space, but might have applications in other long-RTT
environments as well.

In an Interplanetary Internet setting deploying the Bundling protocol
being developed by the Delay Tolerant Networking Research Group, LTP
is intended to serve as a reliable convergence layer over single hop
deep-space RF links. LTP does ARQ of data transmissions by soliciting
selective-acknowledgment reception reports, is stateful, has no
negotiation or handshakes, and supports out-of-transmission-order
data delivery.

Table of Contents

1. Introduction ................................................. 3 4
2. Motivation ................................................... 5
2.1 IPN Operating Environment ................................ 5
2.2 Why not TCP? ............................................. 7
3. Features ..................................................... 7 8
3.1 Massively Parallel Massive State Retention ....................... 8
3.1.1 Out-of-order Delivery ............................... .................................. 9
3.1.1 Multiplicity of Protocol State Machines ............. 10
3.1.2 Session IDs ......................................... 10
3.1.3 Use of Non-volatile Storage ......................... 11 10
3.2 Absence of Negotiation ................................... 11
3.3 Laconic Acknowledgment ................................... 12 11
3.4 Adjacency ................................................ 13 12
3.5 Optimistic and Dynamic Timeout Interval Computation ...... 14 13
3.6 Deferred Transmission .................................... 15 14
4. Terminology .................................................. 15 14
5. Overall Operation ............................................ 19 18
5.1 Nominal Operation ........................................ 19 18
5.2 Retransmission ........................................... 20
5.2.1 Reception Reporting Rules ........................... 22
5.2.2 Design Rationale .................................... 22
5.3 Accelerated Delivery ..................................... 24 23
5.4 Accelerated Retransmission ............................... 24
5.5 Session Cancellation ..................................... 25 24
5.6 Unreliable Transmission .................................. 26 25
6. Functional Model ............................................. 26
6.1 Deferred Transmission .................................... 27 26
6.2 Bandwidth Management ..................................... 27
6.3 Timers ................................................... 28
7. Segment Structure ............................................ 30
7.1 Segment Header ........................................... 30
7.1.1 Segment Type Flags .................................. 31
7.1.2 Segment Type Codes .................................. 32
7.1.3 Segment Class Masks ................................. 32
7.1.4 Extensions Field .................................... 33
7.2 Segment Content .......................................... 33 34

Burleigh et al. Expires - January 2005 [Page 2]
Internet Draft Licklider Transmission Protocol July 2004

7.2.1 Data Segment ........................................ 33 34
7.2.2 Report Segment ...................................... 34 35
7.2.3 Report Acknowledgment Segment ....................... 36 37
7.2.4 Session Management Segments ......................... 36 37
8. Requests from Client Service ................................. 37 38
8.1 Transmission Request ..................................... 37

Burleigh et al. Expires - November 2004 [Page 2]

Internet Draft Licklider Transmission Protocol May 2004 38
8.2 Cancellation Request ..................................... 38 39
9. Internal Procedures .......................................... 39 40
9.1 Start Transmission ....................................... 39 41
9.2 Start Checkpoint Timer ................................... 40 41
9.3 Start RS Timer ........................................... 40 41
9.4 Stop Transmission ........................................ 40 41
9.5 Suspend Timers ........................................... 40 41
9.6 Resume Timers ............................................ 41 42
9.7 Retransmit Checkpoint .................................... 42 43
9.8 Retransmit RS ............................................ 42 43
9.9 Signify Segment Arrival .................................. 42 44
9.10 Signify Block Reception ................................. 43 44
9.11 Send Reception Report ................................... 43 44
9.12 Signify Transmission Completion ......................... 44 45
9.13 Retransmit Data ......................................... 44 45
9.14 Stop RS Timer ........................................... 45 46
9.15 Start Cancel Timer ...................................... 45 46
9.16 Retransmit Cancellation Segment ......................... 45 47
9.17 Acknowledge Cancellation ................................ 46 47
9.18 Stop Cancellation Timer ................................. 46 48
9.19 Cancel Session .......................................... 47 48
9.20 Close Session ........................................... 47 48
10. Notices to Client Service ................................... 47 48
10.1 Session Start ............................................ 47 48
10.2 Data Segment Arrival ..................................... 47 49
10.3 Block Reception .......................................... 48 49
10.4 Transmission Completion .................................. 48 49
10.5 Transmission Cancellation ................................ 48 50
10.6 Reception Cancellation ................................... 49 50
11. State Transition Diagrams .................................... 50
11.1 Sender ................................................... 52
11.2 Receiver ................................................. 55
12. Requirements from the Operating Environment .................. 49
12. 58
13. Security Considerations ...................................... 49
12.1 58
13.1 Mechanisms and Layering Considerations ................... 51
12.2 59
13.2 Denial of Service Considerations ......................... 52
12.3 60
13.3 LTP Authentication header .................................... 53
12.4 ....................................... 61
13.4 Implementation Considerations ............................ 53
12.5 Miscellaneous ............................................ 54
13. 64
13.5 Replay Handling .......................................... 65
14. Tracing LTP back to CFDP ..................................... 54
14. 65
15. IANA Considerations .......................................... 56
15. 67
16. Acknowledgments .............................................. 56
16. 68

Burleigh et al. Expires - January 2005 [Page 3]
Internet Draft Licklider Transmission Protocol July 2004

17. References ................................................... 57
17. 68
17.1 Informative References ................................... 68
17.2 Normative References ..................................... 68
18. Author's Addresses ........................................... 57 69
19. Copyright Statement .......................................... 70

1. Introduction

The Licklider Transmission Protocol (LTP) described in this memo is
designed to provide retransmission-based reliability over links
characterized by extremely long message round-trip times. These long
round-trip times may result from the use of half-duplex channels or

Burleigh et al. Expires - November 2004 [Page 3]

Internet Draft Licklider Transmission Protocol May 2004

from data propagation delays that are so lengthy as to simulate half-
duplex transmission. Such environments are not well served by TCP,
which depends on relatively short round-trip times for retransmission
buffer management, timely flow control, times, frequent
interruptions in connectivity, and negotiation of other
connection parameters.

As communication across high bit error rates.
Communication in interplanetary space is the most prominent example
of this sort of environment, and LTP is principally aimed at
supporting "long-haul" reliable transmission in the Interplanetary
Internet (IPN) [IPN]. over deep-space RF
links.

Since 1982 the principal source of standards for space communications
has been the Consultative Committee for Space Data Systems
(CCSDS)[CCSDS]. (CCSDS)
[CCSDS]. Engineers of CCSDS member agencies have developed
communication protocols that function within the constraints imposed
by operations in deep space. These constraints differ sharply from
those within which the Internet typically functions:

o Extremely long signal propagation delays, on the order of
seconds, minutes, or hours rather than milliseconds.

o Frequent and lengthy interruptions in connectivity.

o Low levels of communication traffic coupled with high rates of
transmission error.

o Meager bandwidth and highly asymmetrical data rates.

The CCSDS File Delivery Protocol (CFDP) [CFDP], in particular,
automates reliable file transfer across interplanetary distances by
detecting data loss and initiating the requisite retransmission
without mission operator intervention.

CFDP by itself is sufficient for operating individual missions, but
its built-in networking capabilities are rudimentary. In order to
operate within the IPN environment it must rely on the routing and
incremental retransmission capabilities of the Bundling protocol [BP]
defined for Delay-Tolerant Networking [BP][DTNRG]. Networks [DTN]. LTP is intended to serve
as a reliable "convergence layer" protocol underlying Bundling in DTN
regions whose links are characterized by very long round-trip times.

Burleigh et al. Expires - January 2005 [Page 4]
Internet Draft Licklider Transmission Protocol July 2004

Its design notions are directly descended from the retransmission
procedures defined for CFDP.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [B97].

Burleigh et al. Expires - November 2004 [Page 4]

Internet Draft Licklider Transmission Protocol May 2004

2. Motivation

2.1 IPN Operating Environment

There are a number of fundamental differences between the environment
for terrestrial communications and the operating environments
envisioned for the IPN.

The most challenging difference between communication among points on
Earth and communication among planets is round-trip delay, of which
there are two main sources, both relatively intractable: natural law
and economics.

The more obvious type of delay imposed by nature is signal
propagation time. Our inability to transmit data at speeds higher
than the speed of light means that, that while round-trip times in the
terrestrial Internet range from milliseconds to a few seconds,
minimum round-trip times to Mars range from 8 to 40 minutes,
depending on the planet's position. Round-trip times between Earth
and Jupiter's moon Europa run between 66 and 100 minutes.

Less obvious and more dynamic is the delay imposed by occultation.
Communication between planets must be by radiant transmission, which
is usually possible only when the communicating entities are in line
of sight of each other. An entity residing on a planetary surface
will be periodically taken out of sight by the planet's rotation (it
will be "on the other side of" the planet); an entity that orbits a
planet will be periodically taken out of sight by orbital motion (it
will be "behind" the planet); and planets themselves lose mutual
visibility when their trajectories take them to opposite sides of the
sun.
Sun. During the time that communication is impossible, delivery is
impaired and messages must wait in a queue for later transmission. Delivery is necessarily
retarded.

Round-trip times and occultations can at least be readily computed
given the ephemerides of the communicating entities. Additional
delay that is less easily predictable is introduced by discontinuous
transmission support, which is rooted in economics.

Communicating over interplanetary distances requires expensive
special equipment: large antennas, high-performance receivers, etc.
For most deep-space missions, even non-NASA ones, these are currently

Burleigh et al. Expires - January 2005 [Page 5]
Internet Draft Licklider Transmission Protocol July 2004

provided by NASA's Deep Space Network (DSN). (DSN) [DSN]. The communication
resources of the DSN are currently oversubscribed and will probably
remain so for the foreseeable future. While studies have been done
as to the feasibility of upgrading or replacing the current DSN, the
number of deep space missions will probably continue to grow faster
than the terrestrial infrastructure that supports them, making over-

Burleigh et al. Expires - November 2004 [Page 5]

Internet Draft Licklider Transmission Protocol May 2004
subscription a persistent problem. Radio contact via the DSN must
therefore be carefully scheduled and is often severely limited.

This over-subscription means that the round-trip times experienced by
packets will be affected not only by the signal propagation delay and
occultation, but also by the scheduling and queuing delays imposed by
management of Earth-based resources: packets to be sent to a given
destination may have to be queued until the next scheduled contact
period, which may be hours, days, or even weeks away. While queuing
and scheduling delays are generally known well in advance except when
missions need emergency service (such as during landings and
maneuvers), the long and highly variable delays make the design of
timers, and retransmission timers in particular, quite difficult.

Another significant difference between deep space and terrestrial
communication is bandwidth availability. The combined effects of
large distances (resulting in signal attenuation), the expense and
difficulty of deploying large antennas to distant planets, and the
difficulty of generating electric power in space all mean that the
available bandwidth for communication in the IPN will likely remain
modest compared to terrestrial systems. Maximum data rates on the
order of a few tens of megabits per second will probably be the norm
for the next few decades.

Moreover, the available bandwidths are highly asymmetrical: data are
typically transmitted at different rates in different directions on
the same link. Current missions are usually designed with a much
higher data "return" rate (from spacecraft to Earth) than "command"
rate (from Earth to spacecraft). The reason for the asymmetry is
simple: nobody ever wanted a high-rate command channel, and, all else
being equal, it was deemed better to have a more reliable command
channel than a faster one. This design choice has led to data rate
asymmetries in excess of 100:1, sometimes approaching 1000:1. A
strong desire for a very robust command channel will probably remain,
so any transport protocol designed for use in the IPN will need to
function with a relatively low-bandwidth outbound channel to
spacecraft and landers.

The difficulty of generating power on and around other planets will
also result in relatively low signal-to-noise ratios and thus high
bit error rates. Current deep-space missions operate with raw bit
error rates on the order of 10^-1, 10^(-1), or one error in ten bits; heavy

Burleigh et al. Expires - January 2005 [Page 6]
Internet Draft Licklider Transmission Protocol July 2004

coding is used to reduce these rates, and of course this coding
further reduces the residual bandwidth available for data
transmission.

Propagation

Signal propagation delay is the only truly immutable characteristic
that distinguishes the IPN from terrestrial communications (unless
and

Burleigh et al. Expires - November 2004 [Page 6]

Internet Draft Licklider Transmission Protocol May 2004 until we find a way to transmit information faster than the speed
of light). Queuing and scheduling delays, low data rates,
intermittent connectivity, and high bit error rates can all be
mitigated or eliminated by adding more infrastructure. But this
additional infrastructure is likely to be provided (if at all) only
in the more highly developed core areas of the IPN. We see the IPN
growing outwards from Earth as we explore more and more planets,
moons, asteroids, and possibly other stars. This suggests that there
will always be a "fringe" to the fabric of the IPN, an area without a
rich communications infrastructure. The delay, data rate,
connectivity, and error characteristics mentioned above will probably
always be an issue somewhere in the IPN.

2.2 Why not TCP?

These environmental characteristics - long delays, low and asymmetric
bandwidth, intermittent connectivity, and relatively high error rate rates
- make using unmodified TCP for end to end communications in the IPN
infeasible. Using the equations TCP throughput equation from Mathis, et al., [MSM97], [TFRC] we can
calculate an upper bound on the sustainable throughput loss event rate (p) required to achieve a given steady-
state throughput. Assuming the closest RTT to Mars from planet Earth
of 8 minutes, a TCP
connection, taking into account TCP's congestion avoidance
mechanisms. Even if only 1 packet size of 1500 bytes, assuming the receiver to
acknowledge every other packet, and ignoring negligible higher order
terms in p (i.e., ignoring the second additive term in the
denominator of the throughput equation from [TFRC]), we obtain the
following table of loss event rates required to achieve various
throughput values.

Throughput Loss event rate (p)
---------- -------------------
10 Mbps 4.68 * 10^(-12)
1 Mbps 4.68 * 10^(-10)
100 million packets Kbps 4.68 * 10^(-8)
10 Kbps 4.68 * 10^(-6)

Note that multiple losses encountered in a single RTT are lost, counted to
be part of a single loss event in the TCP
connection to Mars is limited throughput equation.
However, such loss event rates are still too high to just under 250kbps. If we assume
that 1 realize in 5000 packets is lost (this figure was reported by Paxson as
the packet corruption rate deep
space links where typical raw bit error rates are in the Internet [P97] then that number
falls to around 1,600bps.

These order of
10^(-1).

The above values are upper bounds on steady-state throughput. Since

Burleigh et al. Expires - January 2005 [Page 7]
Internet Draft Licklider Transmission Protocol July 2004

the number of packets in an episode of connectivity will generally be
under 10,000 due to the low available bandwidth, TCP performance
would be dominated by its behavior during slow-start. This means
that even when Mars is at its closest approach to Earth it would take
a TCP nearly 100 minutes to ramp up to an Earth-Mars transmission
rate of 20kbps.

Note: lab experiments using a channel emulator and standard
applications show that even if TCP could be pushed to work
efficiently at such distances, many applications either rely on
several rounds of handshaking or have built-in timers that render
them non-functional when the round-trip-time is over a couple of
minutes. For example, it typically takes eight round trips for FTP
to get to a state where data can begin flowing. Since an FTP server
may time out and reset the connection after 5 minutes of inactivity,
a conformant standard FTP server could be unusable for communicating
even with the closest planets.

3. Features

Burleigh et al. Expires - November 2004 [Page 7]

Internet Draft Licklider Transmission Protocol May 2004

The design of LTP differs from that of TCP in several significant
ways. The common themes running through these differences are two
central design assumptions, both of which amount to making virtues of
necessity.

First: given the severe innate constraints on interplanetary
communication discussed above, we assume that the computational
resources available to LTP engines will always be ample compared to
the communication resources available on the link between them.

Certainly in many cases the computational resources available to a
given LTP engine - such as one on board a small robotic spacecraft
will not be ample by the standards of the Internet. But in those
cases we expect that the associated communication resources
(transmitter power, antenna size) will be even less ample, preserving
the expected disproportion between the two.

Second, we note that establishing a communication link across
interplanetary distance entails enacting several hardware
configuration measures based on the presumed operational state of the
remote communicating entity:

o orienting a directional antenna correctly;

o tuning a transponder to pre-selected transmission and/or
reception frequencies;

o diverting precious electrical power to the transponder at the

Burleigh et al. Expires - January 2005 [Page 8]
Internet Draft Licklider Transmission Protocol July 2004

last possible moment, and for the minimum necessary length of
time.

We therefore assume that the operating environment in which LTP
functions is able to pass information on the link status (called
"link state cues" from here on) to LTP, telling it which remote LTP
engine(s) should currently be transmitting to the local LTP engine
and vice versa. The operating environment itself must have this
information in order to configure communication link hardware
correctly.

3.1 Massively Parallel Massive State Retention

Like any reliable transport service, service employing ARQ, LTP is "stateful".
In order to assure the reception of a block of data it has sent, LTP
must retain for possible retransmission all portions of that block
which might not yet have been received. In order to do so, it must
keep track of which portions of the block are known to have been
received so far, and which are not, together with any additional
information needed for purposes of retransmitting part or all of that
block.

Burleigh et al. Expires - November 2004 [Page 8]

Internet Draft Licklider Transmission Protocol May 2004

Long round-trip times mean substantial delay between the transmission
of a block of data and the reception of an acknowledgment from the
block's destination, signaling arrival of the block. If LTP
postponed transmission of additional blocks of data until it received
acknowledgment of the arrival of all prior blocks, valuable
opportunities to utilize what little deep space transmission
bandwidth is available would be forever lost.

For this reason, LTP is based in part on a notion of massively
parallel transmission. massive state
retention. Any number of requested transmissions may be concurrently
"in flight" at various displacements along the link between two LTP
engines, and the LTP engines must necessarily retain transmission
status and retransmission resources for all of them. Moreover, if
any of the data of a given block are lost en route, it will be
necessary to retain the state of that transmission during an
additional round trip while the lost data are retransmitted; even
multiple retransmission cycles may be necessary.

In sum, LTP transmission state information persists for a long time
because a long time must pass before LTP can be assured of
transmission success - so LTP must retain a great deal of state
information.

Since the alternatives are non-reliability on the one hand and severe
under-utilization of transmission opportunities on the other, we
believe such massive statefulness is cost-justified (though probably

Burleigh et al. Expires - January 2005 [Page 9]
Internet Draft Licklider Transmission Protocol July 2004

not in all applications).

3.1.1 Out-of-order Delivery Multiplicity of Protocol State Machines

This design decision is reflected in a significant structural
difference between LTP and TCP.

Both TCP and LTP provide mechanisms for multiplexing access by a
variety of higher-layer services or applications: LTP's "client
service IDs" correspond to TCP's port numbers. Also, both TCP and
LTP implement devices for encapsulating threads of retransmission
protocol:
protocol (protocol state machines): LTP's "sessions" functionally
correspond to TCP connections. At any moment each such thread of
retransmission protocol is engaged in conveying some single block of
data from one protocol end point to another.

But while TCP permits only

However, a single connection on a given TCP association (local host address, local port
number, foreign host address, foreign port number) can accommodate at
most one connection at any
time, one time. In contrast, a single LTP permits an unlimited number of concurrent sessions for each
association (local engine ID, local client service. And just as in TCP service ID, foreign engine
ID, foreign client service ID) can accommodate multiple concurrent
sessions.

3.1.2 Session IDs

In TCP, the vagaries of retransmission
may cause data transmitted on fact that any single association is occupied by at most
one connection (on one port) at any time enables the protocol to be

Burleigh et al. Expires - November 2004 [Page 9]

Internet Draft Licklider Transmission Protocol May 2004

delivered after use host addresses
and port numbers to demultiplex arriving data that were subsequently transmitted on another
connection (another port), so too in LTP is it to the appropriate
protocol state machines. LTP's possible multiplicity of sessions per
association makes it necessary for each segment of application data
transmitted in one session (for one client service)
to be delivered
after data include an additional demultiplexing token, a "session ID" that were subsequently transmitted in another session (for
another - or possibly
uniquely identifies the same - client service).

In short, while TCP always delivers data session in transmission order on a
single port, LTP may well deliver data out which the segment was issued.

3.1.3 Use of transmission order to a
single client service. The contrasts may be summarized as follows:

------TCP------ -------LTP-------

number Non-volatile Storage

Another important implication of "ports" 65,535 unlimited; normally 1

"connections" per "port" 1 unlimited

maximum number massive statefulness is that
implementations of 65,535 unlimited
concurrent connection LTP should consider retaining transmission state machines

blocks transmitted per unlimited 1
"connection" (one at a time)

Out-of-transmission-order delivery of transmitted blocks to client
services averts two serious problems that could be raised by a single
"bit hit" - the unrecoverable corruption of a single segment of one
block - followed by the successful reception
information in non-volatile storage of some number of
subsequently transmitted blocks while retransmission of the lost
segment is requested and accomplished.

First, it ensures that delivery of the successfully received data is
not unnecessarily postponed. LTP leaves up to the client service all
decisions on what can and cannot be done with this data pending
delivery of kind, such as magnetic
disk or flash memory. Transport protocols such as TCP typically
retain transmission state in dynamic RAM; if the undelivered block. [Note that this places computer on which
the
client services software resides is rebooted or powered down, then all responsibility for establishing sequence
relationships among transmitted blocks, e.g., embedding timestamps
and/or sequence numbers within the blocks.]

Second, it enables LTP to release resources allocated to the
completed sessions' state information as rapidly as possible. This
somewhat mitigates
transmissions currently in progress are aborted but the burden resulting
degree of statefulness at the receiving
engine.

3.1.2 Session IDs

In TCP, communication disruption is limited, because the delivery number of data in transmission order on any single
port, without gaps, enables the application that
concurrent connections is receiving data limited. Rebooting or power-cycling a
computer on
that port to use delivery order as the basis for reconstituting the which an LTP engine resides could abort a much larger
number of transmission sessions in various stages of completion, at a
much larger total cost.

Burleigh et al. Expires - November 2004 January 2005 [Page 10]
Internet Draft Licklider Transmission Protocol May July 2004

originally transmitted data items. LTP client services count on LTP
to accomplish this reconstitution at the block level, but LTP itself
cannot rely on data delivery order being similarly useful for this
purpose. LTP instead attaches to each segment of application data
the "session ID" that uniquely identifies the original transmission
in which the data were issued. Session ID and block offset enable
LTP to reassemble the originally transmitted data block from segments
of data received out of offset order.

Note that, even so, the order of delivery of completed blocks may
differ from the order in which the blocks were originally
transmitted. Again, attaching the appropriate service-specific
semantic significance to each delivered block is a client service
responsibility.

3.1.3 Use of Non-volatile Storage

Another important implication of massive statefulness is that
implementations of LTP should consider retaining transmission state
information in non-volatile storage of some kind, such as magnetic
disk or flash memory. Transport protocols such as TCP typically
retain transmission state in dynamic RAM; if the computer on which
the software resides is rebooted or powered down, then all
transmissions currently in progress are aborted but the resulting
degree of communication disruption is limited, because the number of
concurrent transmissions is limited. Rebooting or power-cycling a
computer on which an LTP engine resides could abort a much larger
number of transmission sessions in various stages of completion, at a
much larger total cost.

3.2 Absence of Negotiation

Implicit in the design of TCP is the assumption that the parameters
of communication over a given connection can be bilaterally
negotiated and renegotiated in a timely manner. Adjustment of
transmission rate in particular is accomplished by the exchange of
information in real time.

3.2 Absence of Negotiation

In the IPN, however, round-trip times may be so long and communication
opportunities so brief that a negotiation exchange exchange, such as an
adjustment of transmission rate, might not be completed before
connectivity was lost. Even if connectivity were uninterrupted,
waiting for negotiation to complete before revising data transmission
parameters might well result in costly under-utilization of link
resources.

For this reason, all LTP communication session parameters are
established
asserted unilaterally, subject to application-level network
management activity that may not take effect for hours, days, or

Burleigh et al. Expires - November 2004 [Page 11]

Internet Draft Licklider Transmission Protocol May 2004
weeks.

3.3 Laconic Acknowledgment

Another respect in which LTP differs from TCP is that, while TCP
connections are bidirectional (blocks of application data may be
flowing in both directions on any single connection), LTP sessions
are unidirectional. This design decision derives from the possible
multiplicity of parallel sessions for any single client service,
together with the fact that
the flow of data in deep space flight missions is usually
unidirectional. (Long round trip times make interactive spacecraft
operation infeasible, so spacecraft spacecrafts are largely autonomous and
command traffic is very light.)

One could imagine an LTP instance, upon being asked to transmit a
block of data, searching through all existing sessions in hopes of
finding one that was established upon reception of data from the new
block's destination; transmission of the new block could be
piggybacked on the acknowledgment traffic for that session. But the
prevailing unidirectionality of space data communications means that
such a search would frequently fail, and a new unidirectional session
would have to be established anyway. Session bidirectionality
therefore seemed to entail somewhat greater complexity unmitigated by
any clear performance advantage, so we abandoned it. Bidirectional
data transfer is supported, but it requires opening two individual
LTP sessions.

Because they are not piggybacked on data segments, LTP data
acknowledgments - "reception reports" - are carried in a separate
segment type. To minimize consumption of low and asymmetric
transmission bandwidth in the IPN, these report segments are sent
infrequently; each one contains a comprehensive report of all data
received within some specified range of offsets from the start of the
transmitted block. The expectation is that most data segments will
arrive safely, so individual acknowledgment of each one would be
expensive in information-theoretical terms: the real information

Burleigh et al. Expires - January 2005 [Page 11]
Internet Draft Licklider Transmission Protocol July 2004

provided per byte of acknowledgment data transmitted would be very
small. Instead, report segments are normally sent only upon
encountering explicit solicitations for reception reports -
"checkpoints" - in the sequence of incoming data segments.

The aggregate nature of reception reports gives LTP transmission an
episodic character:

o "Original transmissions" are sequences of data segments issued
in response to transmission requests from client services.

o "Retransmissions" are sequences of data segments issued in

Burleigh et al. Expires - November 2004 [Page 12]

Internet Draft Licklider Transmission Protocol May 2004
response to the arrival of report segments that indicate
incomplete reception.

Checkpoints are mandatory only at the end of each original
transmission or retransmission. such sequence. For
applications that require accelerated retransmission (and can afford
the additional bandwidth consumption entailed), reception reporting
can be more aggressive. Additional checkpoints may optionally be
inserted at other points in an original transmission, and additional
reception reports may optionally be sent on an asynchronous basis. basis
during reception of an original transmission.

3.4 Adjacency

TCP reliability is "end to end": traffic between two TCP endpoints
may traverse any number of intermediate network nodes, and two
successively transmitted segments may travel by entirely different
routes to reach the same destination. The underlying IP network-
layer protocol accomplishes this routing. Although TCP always
delivers data segments to any single port in order and without gaps,
the IP datagrams delivered to TCP itself may not arrive in the order
in which they were transmitted.

In contrast, LTP reliability is a protocol for "point to point": point" reliability on a
single link: traffic between two LTP engines is expected not to
traverse any intermediate relays. Point-to-point topology is innate
in the nature of deep space communication, which is simply the
exchange of radiation between two mutually visible antennae. No
underlying network infrastructure is presumed, so no underlying
network-layer protocol activity is expected; the underlying
communication service is assumed to be a point-to-point link-layer
protocol such as CCSDS Telemetry/Telecommand [TM][TC] (or, for
terrestrial applications, PPP). The contents of link-layer frames
delivered to LTP are always expected to arrive in the order in which
they were transmitted, though possibly with any number of gaps due to
data loss or corruption.

Burleigh et al. Expires - January 2005 [Page 12]
Internet Draft Licklider Transmission Protocol July 2004

Note that building an interplanetary network infrastructure - the
DTN-based architecture of the IPN - *on top of* LTP does not conflict
with LTP design principles. The Bundling protocol functions at a new
hyper-network level, and LTP bears essentially the same relationship
to Bundling that a reliable link protocol (for example, the ARQ
capabilities of LLC) would bear to IP. The design of LTP relies
heavily on this topological premise, in at least two ways:

If two successively transmitted segments could travel by materially
different routes to reach the same destination, then the assumption
of rough determinism in timeout interval computation discussed below
would not hold. Our inability to estimate timeout intervals with any

Burleigh et al. Expires - November 2004 [Page 13]

Internet Draft Licklider Transmission Protocol May 2004
accuracy would severely compromise performance.

If data arrived at an LTP engine out of transmission order, then the
assumptions on which the rules for reception reporting are based
would no longer hold. A more complex and/or less efficient
retransmission mechanism would be needed.

3.5 Optimistic and Dynamic Timeout Interval Computation

TCP determines timeout intervals by measuring and recording actual
round trip times, then applying statistical techniques to recent RTT
history to compute a predicted round trip time for each transmitted
segment.

The problem is at once both simpler and more difficult for LTP:

o The massively parallel nature of LTP changes the granularity at
which timer accuracy is required. Confirmation of the reception

Since multiple sessions can be conducted on any single
association, retardation of one block, or one segment, does not retard transmission of
the next, so on any single session
while awaiting a timeout values need not degrade communication
performance on the association as a whole. Timeout intervals that
would be intolerably optimistic in TCP don't constrain necessarily degrade
LTP's bandwidth utilization.

But the reciprocal half-duplex nature of LTP communication makes
it infeasible to use statistical analysis of round-trip history as
a means of predicting round-trip time. The round-trip time for
transmitted segment N could easily be orders of magnitude greater
than that for segment N-1. N-1 if there happened to be a transient loss
of connectivity between the segment transmissions.

Since statistics derived from round-trip history cannot safely be
used as a predictor of LTP round-trip times, we have to assume that
round-trip timing is at least roughly deterministic - i.e., that
sufficiently accurate RTT estimates can be computed individually in
real time from available information.

Burleigh et al. Expires - January 2005 [Page 13]
Internet Draft Licklider Transmission Protocol July 2004

This computation is performed in two stages.

We calculate a first approximation of RTT by simply doubling the
known one-way light time to the destination and adding an arbitrary
margin for possible any additional anticipated latency, such as queuing and
processing delay at both ends of the transmission. The For deep space
operations, the margin value is typically a small number of whole
seconds. Although such a margin is enormous by Internet standards,
it is insignificant compared to the two-way light time component of
round-trip time in deep space. We choose to risk tardy
retransmission, which will postpone delivery of one block by a
relatively tiny increment, in preference to premature retransmission,
which will unnecessarily consume precious bandwidth and thereby
degrade overall performance.

Burleigh et al. Expires - November 2004 [Page 14]

Internet Draft Licklider Transmission Protocol May 2004

Then, to account for the additional delay imposed by interrupted
connectivity, we dynamically suspend timers during periods when the
relevant remote LTP engines are known to be unable to transmit
responses. This knowledge of the operational state of remote
entities is assumed to be provided by link state cues from the
operating environment, as discussed earlier.

3.6 Deferred Transmission

Link state cues also notify LTP when it is and isn't possible to
transmit segments by passing them to the underlying communication
service.

Continuous duplex communication is the norm for TCP operations in the
Internet; when communication links are not available, TCP simply does
not operate. In deep space communications, however, at no moment can
there ever be any expectation of two-way connectivity. It is always
possible for LTP to be generating outbound segments - in response to
received segments, timeouts, or requests from client services - that
cannot immediately be transmitted. These segments must be queued for
transmission at a later time when a link has been established, as
signaled by a link state cue.

4. Terminology

(1) Engine ID

A number that uniquely identifies a given LTP engine, within some
closed set of communicating LTP engines. Note that, that when LTP is
operating underneath the DTN Bundling protocol, the convergence layer
adapter mediating between the two will be responsible for translating
between DTN endpoint IDs and LTP engine IDs in an implementation-
specific manner.

Burleigh et al. Expires - January 2005 [Page 14]
Internet Draft Licklider Transmission Protocol July 2004

(2) Block

An array of contiguous octets of application data handed down by the
upper layer (typically the bundling layer) to be transmitted via LTP
from one client service instance to another.

(3) Block Prefix

Any subset of a block that begins at the start of the block.

(4) Session

A thread of LTP protocol activity conducted for the purpose of
transmitting a block.

Burleigh et al. Expires - November 2004 [Page 15]

Internet Draft Licklider Transmission Protocol May 2004

(5) Segment

The unit of LTP data transmission activity. It is the data structure
transmitted from one LTP engine to another in the course of a
session. An LTP segment is either a data segment, a report segment, a
report-acknowledgment segment, a cancel segment, or a cancel-
acknowledgment segment.

(6) Scope

A subset Reception Claim

An assertion of a block. Scope comprises reception of some number of contiguous octets of
application data (a subset of a block) characterized by the offset of
the first received octet and the number of contiguous octets
received.

(7) Scope

Scope identifies a subset of a block and comprises two numbers, numbers -
upper bound and lower bound.

For a data segment, lower bound is the offset of the segment's client
service
application data from the start of the block, block (in octets), while upper
bound is the sum of the offset and length of the segment's client service data.
application data (in octets). For example, a segment with block
offset 1000 and length 500 would have a lower bound 1000 and upper
bound 1500.

For a report segment, upper bound is the end of the block prefix to
which the reception claims in the report apply, while lower bound is
the end of the (smaller) interior block prefix to which the reception
claims in the report do *not* apply. That is, data at any offset
equal to or greater than the report's lower bound but less than its
upper bound, bound and not designated as "received" by any of the report's

Burleigh et al. Expires - January 2005 [Page 15]
Internet Draft Licklider Transmission Protocol July 2004

reception claims, claims must be assumed not yet received and therefore eligible
for retransmission. For example, if a report segment carried a lower
bound of 1000 and an upper bound of 5000, and the reception claims
indicated reception of data within offsets 1000-1999 and 3000-4999,
data within the block offsets 2000-2999 can be considered eligible
for retransmission.

Reception reports (which may comprise multiple report segments) also
have scope, as defined in Section 5.2.1 below.

(7) Sec 5.2.1.

(8) End of Block (EOB)

The last data segment transmitted as part of the original
transmission of a block. This data segment also indicates that the
segment's upper bound is the total length of the block.

(8) block (in octets).

(9) Checkpoint

A data segment soliciting a reception report from the receiving LTP
engine. All checkpoints other than the EOB segment that are NOT
themselves issued in response to a reception report, are
discretionary checkpoints, sent unreliably. The EOB segment and all
checkpoints issued in response to reception reports are mandatory

Burleigh et al. Expires - November 2004 [Page 16]

Internet Draft Licklider Transmission Protocol May 2004
checkpoints, sent reliably.

(9)

(10) Reception Report

A sequence of one or more report segments reporting on all block data
reception (within some scope) since the start of the block's
transmission session.

(10)

(11) Synchronous Reception Report

A reception report that is issued in response to a checkpoint.

(11)

(12) Asynchronous Reception Report

A reception report that is issued in response to some implementation implementation-
defined event other than the arrival of a checkpoint.

(12)

(13) Primary Reception Report

A reception report that is issued in response to some event other
than the arrival of a checkpoint segment that was itself issued in
response to a reception report. Primary reception reports include
all asynchronous reception reports and all synchronous reception
reports that are sent in response to discretionary checkpoints or to
the EOB for a session.

(13)

Burleigh et al. Expires - January 2005 [Page 16]
Internet Draft Licklider Transmission Protocol July 2004

(14) Secondary Reception Report

A reception report that is issued in response to the arrival of a
checkpoint segment that was itself issued in response to a reception
report.

(14)

(15) Self-Delimiting Numeric Value (SDNV)

The design of LTP attempts to reconcile minimal consumption of
transmission bandwidth with

(a) extensibility to satisfy requirements not yet identified and
(b) scalability across a very wide range of network sizes and
transmission payload sizes.

A key strategic element in the design is the use of self-delimiting
numeric values (SDNVs) that are similar in design to the Abstract
Syntax Notation One [ASN1] encoding. An SDNV can be used to encode a
variable length number from 1 to 128 bytes long, and is of two basic
types, SDNV-8 and SDNV-16.

The first octet of an SDNV - the "discriminant" - fully characterizes

Burleigh et al. Expires - November 2004 [Page 17]

Internet Draft Licklider Transmission Protocol May 2004
the SDNV's value.

SDNV-8

If the first most significant bit of the discriminant is zero, the
length of the SDNV-8 is 1 octet and the contents of the remaining
7 bits of the discriminant viewed as an unsigned integer is the
value encoded. An integer in the range of 0 to 127 can be encoded
this way.

Otherwise (if the first most significant bit of the discriminant is 1),
the remaining 7 bits encode the length of the encoded number. If
the content of the remaining 7 bits viewed as an unsigned integer
has the value N, the encoded number is N+1 octets long and has the
value found by concatenating octets 2 through N+2 of the SDNV-8,
viewed as an unsigned integer. For example, if N were 0, the
following single octet would have the value of the SDNV-8; if N
were 127, the following 128 octets would have the encoded unsigned
number.

SDNV-16

If the first most significant bit of the discriminant is zero, then the
length of the SDNV-16 is 2 octets and the contents of the
remaining 7 bits of the discriminant concatenated with the
following octet, viewed as a 15-bit unsigned integer, is the value

Burleigh et al. Expires - January 2005 [Page 17]
Internet Draft Licklider Transmission Protocol July 2004

encoded. An integer in the range of 0 to 32767 can be encoded this
way.

Otherwise (if the first most significant bit of the discriminant is 1),
the encoding is similar to SDNV-8. If the content of the remaining
7 bits viewed as an unsigned integer has the value N, the encoded
number is N+1 octets long, and has the value found by
concatenating octets 2 through N+2 of the SDNV-16, viewed as an
unsigned integer.

An SDNV can therefore be used to represent both very large and very
small integer values. For example, the maximum size of an SDNV - a
1024-bit number - is large enough to contain a fairly safe encryption
key, while any whole-degree Celsius temperature in the range that
humans tolerate in which
water is a liquid can be represented in a single-octet SDNV-8.

In the LTP header specification that follows, various fields in the
header are defined to be of types SDNV-8 or SDNV-16 depending on the
typical range of values expected for the field. If a field in the
header carries a number that typically requires 16 bits to encode,
but under certain infrequent conditions may grow longer and require,
say
say, 32 bits to encode, it might be optimal to specify it as an
SDNV-16 instead of specifying the field as a fixed 32 bit integer.

Burleigh et al. Expires - November 2004 [Page 18]

Internet Draft Licklider Transmission Protocol May 2004

However, SDNV is clearly not the best way to represent every numeric
value. When the maximum possible value of a number is known without
question, the cost of an additional 8 bits of discriminant may not be
justified. For example, an SDNV-8 is a poor way to represent an
integer whose value typically falls in the range 128 to 255.

In general, though, we believe that SDNV representation of selected
numeric values in LTP segments yields the smallest segment sizes
without sacrificing scalability.

(16) Client Service Instance

A software entity, such as an application or a higher-layer protocol
implementation, that is using LTP to transfer data.

5. Overall Operation

5.1 Nominal Operation

The nominal sequence of events in an LTP transmission session is as
follows.

Operation begins when a client service instance asks an LTP engine to
transmit a block to a remote client service instance. The sending

Burleigh et al. Expires - January 2005 [Page 18]
Internet Draft Licklider Transmission Protocol July 2004

engine opens a Sending State Record (SSR) for a new session, thereby
starting the session, and it notifies the client service instance that
the session has been started. The sending engine then initiates an
original transmission: it queues for transmission as many data
segments as are necessary to transmit the entire block, within the
constraints on maximum segment size imposed by the underlying
communication service. The last such segment is marked both as a
checkpoint
checkpoint, indicating that the receiving engine must issue a
reception report upon receving receiving the segment, and as an EOB EOB,
indicating that the receiving engine can calculate the size of the
block by summing the offset and length of the data in the segment.

At the next opportunity, subject to allocation of bandwidth to the
queue into which the block data segments were written, the enqueued
segments are transmitted to the LTP engine serving the remote client
service instance. A timer is started for the EOB, so that it can
automatically be
retransmitted automatically if no response is received.

On reception of the first data segment for the block, the receiving
engine opens a Receiving State Record (RSR) for the new session, session and
it
notifies the local instance of the relevant client service that the
session has been started. In the nominal case it receives all
segments of the original transmission without error. Therefore on
reception of the EOB data segment it responds by (a) queuing for
transmission to the sending engine a report segment indicating
complete reception and (b) delivering the received block to the local
instance of the client service.

Burleigh et al. Expires - November 2004 [Page 19]

Internet Draft Licklider Transmission Protocol May 2004

At the next opportunity, the enqueued report segment is immediately
transmitted to the sending engine and a timer is started so that the
report segment can be retransmitted automatically if no response is
received.

The sending engine receives the report segment, turns off the timer
for the EOB, enqueues for transmission to the receiving engine a
report-acknowledgment segment, notifies the local client service
instance that the block has been successfully transmitted, and closes
the SSR for the session.

At the next opportunity, the enqueued report-acknowledgment segment
is immediately transmitted to the receiving engine.

The receiving engine receives the report-acknowledgment segment,
turns off the timer for the report segment, and closes the RSR for
the session.

Closing both the SSR and RSR for a session terminates the session.

Burleigh et al. Expires - January 2005 [Page 19]
Internet Draft Licklider Transmission Protocol July 2004

5.2 Retransmission

Loss or corruption of transmitted segments causes the operation of
LTP to deviate from the nominal sequence of events described above.

Loss of one or more data segments other than the EOB triggers data
retransmission:

Rather than returning a single reception report indicating complete
reception, the receiving engine returns a reception report comprising
as many report segments as are needed in order to report in detail on
all data reception for this session (other than data reception that
was previously reported in response to any discretionary
checkpoints), within the constraints on maximum segment size imposed
by the underlying communication service. [Still, only one report
segment is normally returned; multiple report segments are needed
only when a large number of segments comprising non-contiguous
intervals of block data are lost.] A timer is started for *each* each
report segment.

On reception of each report segment the sending engine responds as
follows:

It turns off the timer for the checkpoint referenced by the report
segment, if any.

It enqueues a reception-acknowledgment segment acknowledging the
report segment (to turn off the report retransmission timer at the

Burleigh et al. Expires - November 2004 [Page 20]

Internet Draft Licklider Transmission Protocol May 2004
receiving engine). This segment is sent immediately at the next
transmission opportunity.

If the reception claims in the report segment indicate that not
all data within the scope have been received, it normally
initiates a retransmission by re-enqueuing enqueuing all data segments not yet
received. The last such segment is marked a checkpoint and
contains the report serial number of the report segment to which
the retransmission is a response. These segments are likewise
sent at the next transmission opportunity, but subject to
allocation of bandwidth to the queue into which the retransmission
data segments were written. A timer is started for the
checkpoint, so that it can automatically be retransmitted automatically if no
responsive report segment is received.

However, if the number of checkpoints issued for this session
has reached a predefined limit (established by network
management), then the receiving engine instead cancels the
session as described later.

If, on

Burleigh et al. Expires - January 2005 [Page 20]
Internet Draft Licklider Transmission Protocol July 2004

On the other hand, if the reception claims in the RS report segment
indicate that all data within the scope of the RS report segment have
been received, and
moreover the union of all reception claims received so
far in this session indicate that all data in the block have been
received, then the sending engine notifies the local client
service instance that the block has been successfully transmitted
and closes the SSR for the session.

On reception of a checkpoint segment with a non-zero report serial
number, the receiving engine first turns off the timer for the
referenced report segment. Then it returns a reception report
comprising as many report segments as are needed in order to report
in detail on all data reception within the scope of the referenced
report segment, within the constraints on maximum segment size
imposed by the underlying communication service; a timer is started
for each report segment. If at this point all data in the block have
been received, the receiving engine delivers the received block to
the local instance of the client service and closes the RSR for the
session; otherwise the data retransmission cycle continues.

However, if the number of reception reports issued for this
session has reached a predefined limit (established by network
management), then the receiving engine instead cancels the session
as described later.

The detailed rules under which reception reports are produced are
defined in Section 5.2.1 below.

Burleigh et al. Expires - November 2004 [Page 21]

Internet Draft Licklider Transmission Protocol May 2004 Sec 5.2.1.

Loss of an EOB or other checkpoint segment, or of the responsive
report segment causes the checkpoint timer to expire. When this
occurs, the sending engine normally retransmits the checkpoint
segment. However, if the number of times this checkpoint has been
retransmitted has reached a predefined limit (established by network
management), then the sending agent instead cancels the session.

Similarly, loss of a report segment or of the responsive report-
acknowledgment segment causes the report segment's timer to expire.
When this occurs, the receiving engine normally retransmits the
report segment. However, if the number of times this report segment
has been retransmitted has reached a predefined limit (established by
network management), then the receiving agent instead cancels the
session.

Reception of a previously received report segment that was
retransmitted due to loss of an report-acknowledgment segment causes
another responsive report-acknowledgment segment to be transmitted,
but is otherwise ignored; if any of the data retransmitted in
response to the previously received report segment were lost, further

Burleigh et al. Expires - January 2005 [Page 21]
Internet Draft Licklider Transmission Protocol July 2004

retransmission of those data will be requested by one or more new
report segments issued in response to that earlier retransmission's
checkpoint. Thus unnecessary retransmission is suppressed.

5.2.1 Reception Reporting Rules

The upper bound of a synchronous reception report is the upper bound
of the checkpoint segment to which it responds.

The upper bound of an asynchronous reception report is the maximum
upper bound value among all data segments received so far in the
affected session.

The lower bound of a primary reception report is the upper bound of
the previously issued primary reception report for the same session,
if any; otherwise it is zero.

The lower bound of a secondary reception report is the lower bound of
the report segment to which the triggering checkpoint was itself a
response.

Asynchronous reception reports are never issued after the arrival of
the EOB segment for a session.

A reception report comprises as many reception segments as are
necessary to report on all data reception in the scope of the
reception report, within the constraints on maximum segment size
imposed by the underlying communication service. [Again, a reception

Burleigh et al. Expires - November 2004 [Page 22]

Internet Draft Licklider Transmission Protocol May 2004
report normally comprises only a single reception segment; multiple
report segments are needed only when a large number of segments for
non-contiguous intervals of block data are lost.] The lower bound of
the first report segment of a reception report is the reception
report's lower bound; the upper bound of the last report segment of a
reception report is the reception report's upper bound.

5.2.2 Design Rationale

Note that the responsibility for responding to segment loss in LTP is
shared between the sender and receiver of a block: the sender
retransmits checkpoint segments in response to checkpoint timeouts,
and it retransmits non-checkpoint data segments in response to
reception reports indicating incomplete reception, while the receiver
additionally retransmits report segments in response to timeouts. An
alternative design would have been to make the sender responsible for
all retransmission, in which case the receiver would not expect
report-acknowledgment segments and would not retransmit report
segments. There are two disadvantages to this approach:

Burleigh et al. Expires - January 2005 [Page 22]
Internet Draft Licklider Transmission Protocol July 2004

First, because of constraints on segment size that might be imposed
by the underlying communication service, it is at least remotely
possible that the response to any single checkpoint might be multiple
report segments. An additional sender-side mechanism for detecting
and appropriately responding to the loss of some proper subset of
those reception reports would be needed. We believe the current
design is simpler.

Second, an engine that receives a block needs a way to determine when
the session can be closed. In the absence of explicit final report
acknowledgment (which entails retransmission of the report in case of
the loss of the report acknowledgment), the alternatives are (a) to
close the session immediately on transmission of the report segment
that signifies complete reception and (b) to close the session on
receipt of an explicit authorization from the sender. In case (a),
loss of the final report segment would cause retransmission of a
checkpoint by the sender, but the session would no longer exist at
the time the retransmitted checkpoint arrived; the checkpoint could
reasonably be interpreted as the first data segment of a new block,
most of which was lost in transit, and the result would be redundant
retransmission of the entire block. In case (b), the explicit
session termination segment and the responsive acknowledgment by the
receiver (needed in order to turn off the timer for the termination
segment, which in turn would be needed in case of in- transit loss or
corruption of that segment) would somewhat complicate the protocol,
increase bandwidth consumption, and retard the release of session
state resources at the sender. Again we believe the current design
is simpler and more efficient.

Burleigh et al. Expires - November 2004 [Page 23]

Internet Draft Licklider Transmission Protocol May 2004

5.3 Accelerated Delivery

The receiving engine normally delivers block data content to the
client service only at the moment when reception of the block is
completed - that is, on reception of the last not-yet-received
segment of the block. For some applications, applications however, it may be
desirable to deliver block data content incrementally, upon arrival,
because portions of the block may be individually useful to the
client service.

When the client service requests accelerated delivery of a block, the
arrival of each new data segment causes the receiving engine to
deliver to the client service the data content of the segment
together with the segment's offset within the block. The client
service assumes all responsibility for reassembling the block; upon
completion of reception, the receiving engine just delivers the final
data segment's content and offset to the client service as usual but
additionally indicates that reception is now complete.

Burleigh et al. Expires - January 2005 [Page 23]
Internet Draft Licklider Transmission Protocol July 2004

5.4 Accelerated Retransmission

Data segment retransmission occurs only on receipt of a report
segment indicating incomplete reception; report segments in turn, are normally
transmitted only at the end of an original transmission or
retransmission. For some applications it may be desirable to trigger
data segment retransmission incrementally during the course of an
original transmission so that the retransmitted segments arrive
sooner. This can be accomplished in two ways:

Any data segment prior to the last one in the transmission can
additionally be flagged as a checkpoint. Reception of each
checkpoint causes the receiving engine to issue a reception
report.

At any time during the original transmission of a session (that
is, prior to reception of the EOB), the receiving engine can
unilaterally issue additional "asynchronous" reception reports.
[Note
Note that the CFDP protocol's "Immediate" mode is an example of
this sort of asynchronous reception reporting; see Section 12.] Sec 12. The
reception reports generated for accelerated retransmission are
processed in exactly the same way as the standard reception
reports.

Note that checkpoints and reception reports transmitted to perform
accelerated retransmission are discretionary in nature and are sent
unreliably, i.e. no timers are started upon their transmission to
retransmit them automatically later.

5.5 Session Cancellation

A transmission session may be canceled by either the sending or the
receiving engine, in response either to a request from the local
client service instance or to an LTP operational failure as noted

Burleigh et al. Expires - November 2004 [Page 24]

Internet Draft Licklider Transmission Protocol May 2004
earlier. Session cancellation is accomplished as follows.

The canceling engine deletes all currently queued segments for the
session and notifies the local instance of the affected client
service that the session is canceled. If no segments for this
session have yet been sent to or received from the corresponding LTP
engine, then at this point the canceling engine simply closes its
state record for the session and cancellation is complete.
Otherwise, the canceling engine queues for transmission to the
corresponding engine a session cancellation segment.

At the next opportunity, subject to allocation of bandwidth to the
queue into which the cancellation segment was written, the enqueued
cancellation segment is transmitted to the LTP engine serving the

Burleigh et al. Expires - January 2005 [Page 24]
Internet Draft Licklider Transmission Protocol July 2004

remote client service instance. A timer is started for the segment,
so that it can automatically be retransmitted automatically if no response is
received.

The corresponding engine receives the cancellation segment, enqueues
for transmission to the canceling engine a cancellation-
acknowledgment segment, deletes all other currently queued segments
for the indicated session, notifies the local client service instance
that the block has been canceled, and closes its state record for the
session.

At the next opportunity, the enqueued cancellation-acknowledgment
segment is immediately transmitted to the canceling engine.

The canceling engine receives the cancellation-acknowledgment, turns
off the timer for the cancellation segment, and closes its state
record for the session.

Loss of a cancellation segment or of the responsive cancellation-
acknowledgment causes the cancellation segment timer to expire. When
this occurs, the canceling engine normally retransmits the
cancellation segment. However, if the number of times this
cancellation segment has been retransmitted has reached a predefined
limit (established by network management), then the canceling agent
instead simply closes its state record for the session.

5.6 Unreliable Transmission

For operational conditions in which the massive statefulness of LTP
reliability is unsupportable or unnecessary, LTP can perform
unreliable transmission. In unreliable mode all retransmission and
session cancellation capabilities are disabled, but LTP's block
segmentation,
segmentation and reassembly, deferred transmission, bandwidth
management, and interface to the underlying communication service, and incremental data delivery service may
still make

Burleigh et al. Expires - November 2004 [Page 25]

Internet Draft Licklider Transmission Protocol May 2004 it useful to client services.

The nominal sequence of events in an unreliable transmission session
is much simplified.

Operation begins when a client service instance asks an LTP engine to
transmit a block unreliably to a remote client service instance. The
sending engine queues for transmission as many data segments as are
necessary to transmit the entire block, within the constraints on
maximum segment size imposed by the underlying communication service.
The last such segment is marked an EOB signifying that the receiving
engine can calculate the size of the block by summing the offset and
length of the data in this segment. Note that this segment is an EOB
but not a checkpoint.

Burleigh et al. Expires - January 2005 [Page 25]
Internet Draft Licklider Transmission Protocol July 2004

The arrival of each data segment causes the receiving engine to
deliver to the client service the data content of the segment
together with the segment's offset within the block. The client
service assumes all responsibility for reassembling the block.

Upon arrival of the EOB segment, the receiving engine just delivers
that final data segment's content and offset to the client service as
usual but additionally indicates that reception of the block is now
complete.

Loss or corruption of transmitted data segments is not recoverable in
this mode. Loss of the EOB is particularly troublesome: the
receiving client service instance cannot readily distinguish between
actual data loss and very severe queuing delay in this case, and the
total size of the block can never be known. But for some
applications (e.g., continuous telemetry streaming), or in deployment
over a reliable link-layer protocol, this deficiency may be
unimportant.

6. Functional Model

The functional model underlying the specification of LTP is one of
deferred, opportunistic transmission, with access to the active
transmission link apportioned among multiple outbound traffic queues.
The accuracy of LTP retransmission timers depends depend in large part on a
faithful adherence to this model.

6.1 Deferred Transmission

Burleigh et al. Expires - November 2004 [Page 26]

Internet Draft Licklider Transmission Protocol May 2004

Every outbound LTP segment is appended to one of several (conceptual) conceptual
queues -- forming a "queue set" -- of traffic bound for the LTP
engine that is that segment's destination. Production One such conceptual
traffic queue is designated the "internal operations queue" of that
queue set, and the queue set includes at least one additional
conceptual queue for application data transmission.

The production and enqueuing of a segment and the subsequent actual
transmission of that segment are in principle wholly asynchronous.

In the event that (a) a transmission link to the destination is
currently active and (b) the queue to which a given outbound segment
is appended is otherwise empty and (c) this queue is determined to
have the highest transmission priority among all outbound traffic

Burleigh et al. Expires - January 2005 [Page 26]
Internet Draft Licklider Transmission Protocol July 2004

queues associated with that destination, the segment will be
transmitted immediately upon production. Transmission of a newly
appended
queued segment is necessarily deferred in all other circumstances.

Conceptually, the de-queuing of segments from traffic queues bound
for a given destination is initiated upon reception of a link state
cue indicating that the underlying communication system is now
transmitting to that destination, i.e., the link to that destination
is now active. It ceases upon reception of a link state cue
indicating that the underlying communication system is no longer
transmitting to that destination, i.e., the link to that destination
is no longer active.

Note: in the following discussion, the de-queuing of a segment always
implies delivering it to the underlying communication system for
immediate transmission.

6.2 Bandwidth Management

We believe it is necessary for LTP to provide a mechanism for
apportioning access to the active transmission link, possibly
unevenly, among multiple classes of client service data traffic, and
at the same time to provide a minimum-latency control channel for
acknowledgment traffic. To accomplish these ends,

One such mechanism is described below, but note that hardware
limitations or other management considerations might render this
bandwidth management model sub-optimal or infeasible. In cases where
more optimal bandwidth queue management mechanisms are available,
implementations are free to use them. We strongly recommend at least
providing a minimum-latency path for control traffic to enable
efficient protocol operation. Although the choice of bandwidth
management mechanism may have an impact on protocol performance, it
will not affect interoperability; an LTP functional implementation using a
different bandwidth management model is based on or none at all may still be
deemed compliant with this specification.

In the use of N outbound proposed model, one physical traffic queues, N > 1, queue for each
destination with which the LTP engine can communicate.

One such queue is strictly reserved for LTP the conceptual internal operations:
operations queue: it contains only report and acknowledgment segments
(collectively, "acknowledging segments"), which must be transmitted
promptly to protect timer accuracy. A second physical queue for each
destination is reserved for segments produced in sessions designated
as "priority" sessions. Any other Other physical traffic queues supported by a
given LTP engine are for segments produced in non-priority sessions,
typically of varying levels of urgency. The client service specifies
the queue to be used for transmitting a given block - either the
priority session queue or one of the non- priority session queues - at the time transmission of the block is
requested.

Burleigh et al. Expires - November 2004 January 2005 [Page 27]
Internet Draft Licklider Transmission Protocol May July 2004

at the time transmission of the block is requested.

While the link to a given destination is active, continuous iteration
of the following algorithm governs the de-queuing of segments from
the N physical traffic queues bound for that destination:

If any segments are currently in the internal operations queue,
then de-queue the oldest such segment.

Otherwise, if any segments are currently in the priority session
queue, then de-queue the oldest such segment.

Otherwise, if there are any other non-empty queues, invoke an
implementation-specific algorithm to select the next queue to
transmit from and then de-queue the oldest segment in that queue.

6.3 Timers

LTP relies on accurate calculation of expected arrival times for
report and acknowledgment segments in order to know when proactive
retransmission is required. If a calculated time were even slightly
early, the result would be costly unnecessary retransmission. On the
other hand, calculated arrival times may safely be several seconds
late: the only penalties for late timeout and retransmission are
slightly delayed data delivery and slightly delayed release of
session resources.

The following discussion is the basis for LTP's expected arrival time
calculations.

The total time consumed in a single "round trip" (transmission and
reception of the original segment, followed by transmission and
reception of the acknowledging segment) has the following components:

Protocol processing time consumed in issuing the original segment,
receiving the original segment, generating and issuing the
acknowledging segment, and receiving the acknowledging segment.

Outbound queuing delay: delay at the sender of the original
segment while that segment is in a queue waiting for transmission,
and delay at the sender of the acknowledging segment while that
segment is in a queue waiting for transmission.

Radiation time: the time that passes while all bits of the
original segment are being radiated, and the time that passes
while all bits of the acknowledging segment are being radiated.
(This is significant only at extremely low data transmission
rates.)

Round-trip light time: propagation delay at the speed of light, in
both directions.

Burleigh et al. Expires - November 2004 January 2005 [Page 28]
Internet Draft Licklider Transmission Protocol May July 2004

Round-trip light time: propagation delay at the speed of light, in
both directions.

Inbound queuing delay: delay at the receiver of the original
segment while that segment is in a reception queue, and delay at
the receiver of the acknowledging segment while that segment is in
a reception queue.

Delay in transmission of the acknowledging segment due to loss of
connectivity - that is, interruption in outbound link activity at
the sender of the acknowledging segment due to occultation,
scheduled end of tracking pass, etc.

In this context, where errors on the order of seconds or even minutes
may be tolerated, processing time at each end of the session is
assumed to be negligible.

Inbound queuing delay is also assumed to be negligible because, even
on small spacecraft, LTP processing speeds are high compared to data
transmission rates.

Two mechanisms are used to make outbound queuing delay negligible:

The expected arrival time of an acknowledging segment is not
calculated until the moment the underlying communication system
notifies LTP that radiation of the original segment has begun.
All outbound queuing delay for the original segment has already
been incurred at that point.

Acknowledging

The bandwidth management mechanism [Sec 6.2] is expected to
minimize latency in the delivery of acknowledging segments
(reports and acknowledgments) to the underlying communication
system. For example, in the example bandwidth management model
described in Sec 6.2, acknowledging segments are always appended
to the physical internal operations queue. This limits outbound
queuing delay for an acknowledging segment to the time needed to de-
queue
de-queue and radiate all other acknowledging segments that are
currently in that queue. Since acknowledging segments are sent
infrequently and are normally very small, outbound queuing delay
for a given acknowledging segment is likely to be minimal.

Radiation delay at each end of the session is simply segment size
divided by transmission data rate. It is insignificant except when
data rate is extremely low (e.g., 10 bps), in which case the use of
LTP may well be inadvisable for other reasons. Therefore radiation
delay is normally assumed to be negligible.

And we assume that one-way light time to the nearest second can

Burleigh et al. Expires - January 2005 [Page 29]
Internet Draft Licklider Transmission Protocol July 2004

always be known (e.g., provided by the operating environment).

So the initial expected arrival time for each acknowledging segment
is typically computed as simply the current time at the moment that
radiation of the original segment begins, plus twice the one-way
light time, plus 2*N seconds of margin to account for processing and
queuing delays and for radiation time at both ends. N is a parameter
set by

Burleigh et al. Expires - November 2004 [Page 29]

Internet Draft Licklider Transmission Protocol May 2004 network management for which 2 seconds seem to be a reasonable
default value.

This leaves only one unknown, the additional round trip time
introduced by loss of connectivity. To account for this, we again
rely on external link state cues. Whenever interruption of
transmission at a remote LTP engine is signaled by a link state cue,
we suspend the countdown timers for all acknowledging segments
expected from that engine. Upon a signal that transmission has
resumed at that engine, we resume those timers after (in effect)
adding to each expected arrival time the length of the timer
suspension interval.

7. Segment Structure

Each LTP segment comprises (a) a "header" in a standard format and format, (b)
zero or more octets of "content". "content", (c) zero or more octets of
"trailer" as indicated by information in the "extensions field" of
the header. LTP segments are of four general types, depending on the
nature of the content carried.

Data segments carry client service (application) data, together
with metadata enabling the receiving client service instance to
receive and make use of that data.

Report segments carry

A report segment carries data reception claims together with the
upper and lower bounds of the data block scope to which the claims
pertain.

Report acknowledgment segments carry

A report-acknowledgment segment carries only the serial number of
the report being acknowledged.

Session management segments are of two general subtypes:
Cancellation and Cancellation-acknowledgment. A Cancellation acknowledgment. The Cancellation
segments carry
segment carries a single byte reason-code to indicate the reason
for the cancellation. Cancellation acknowledgment Cancellation-acknowledgment segments have no
content.

7.1 Segment Header

<< Recommendations of SDNV-8 / SDNV-16 for fields in the segment

Burleigh et al. Expires - January 2005 [Page 30]
Internet Draft Licklider Transmission Protocol July 2004

header as recommended in this section, section are under discussion. Future
versions of the draft may recommend fields to be of one SDNV type
instead of the other (SDNV-8 in place of SDNV-16, for example), if
found to be more appropriate. >>

An LTP segment header comprises three data items: a single-octet
control byte, a session ID, and an expansion zone. extensions field.

Control byte comprises the following:

Burleigh et al. Expires - November 2004 [Page 30]

Internet Draft Licklider Transmission Protocol May 2004

Version number (4 bits): MUST be set to the binary value 0000 for
this version of the protocol.

Segment type flags (4 bits): described below.

Session ID uniquely identifies, among all transmissions between the
segment's sender and receiver, the session of which the segment is
one token. It comprises the following:

Session originator: the engine ID of the LTP engine that initiated
the session, in SDNV-8 representation.

Session number: a number in SDNV-16 representation, typically a
timestamp,
random number (for anti-DoS reasons), generated by the LTP engine
identified as the session originator.

The format and resolution of session number are matters that are
private to the session-originating engine; the only requirement
imposed by LTP is that every session initiated by an LTP engine
MUST be uniquely identified by the session ID. For example, if
timestamp resolution is not sufficient, an LTP implementation may
choose to append an 8 or 16 bit sequence number to the timestamp
to guard against the possibility of multiple sessions starting at
the same system time.

Expansion zone

The extensions field is a numeric value described in SDNV-8 representation intended
for future expansion of LTP capabilities. In the absence of any
expansion features, it MUST be a single octet whose binary value is
zero. section 7.1.4 below.

7.1.1 Segment Type Flags

The last four bits of the control byte in the segment header are
flags that indicate the nature of the segment. In order (most
significant bit first), these flags are as follows.

Control flag (CTRL)

A value of 0 indicates that the segment carries data and is a data segment, while a
value of 1 indicates that the segment carries is a control information for the protocol (and not data). segment.

Exception flag (EXC)

A value of 1 in a data segment indicates that the segment is being
transmitted unreliably. In a control segment (CTRL flag set), this
indicates that the segment pertains to session cancellation
activity.

Burleigh et al. Expires - November 2004 January 2005 [Page 31]
Internet Draft Licklider Transmission Protocol May July 2004

indicates that the segment pertains to session cancellation
activity.

Request flag (REQ)

If set, this flag signifies a request for some specific response
from the receiver. The nature of that response depends receiver, depending on the values of the other flags as
described below.

Closure flag (CLOS)

When set, this flag signifies the termination of some element of
protocol activity. The nature of the activity being terminated
again depends on the values of the other flags as described below.

7.1.2 Segment Type Codes

Combinations of the settings of the segment type flags CTRL, EXC, REQ
and CLOS constitute segment type codes which serve as concise
representations of detailed segment nature.

CTRL EXC REQ CLOS Code Nature of segment
---- ---- ---- ---- ---- ---------------------------------------
0 0 0 0 0 Data, NOT a Checkpoint, NOT EOB
0 0 0 1 1 Undefined
0 0 1 0 2 Data, Checkpoint, NOT EOB
0 0 1 1 3 Data, Checkpoint, EOB

0 1 0 0 4 Data [unreliable transmission], not EOB
0 1 0 1 5 Data [unreliable transmission], EOB
0 1 1 0 6 Undefined
0 1 1 1 7 Undefined

1 0 0 0 8 Report segment
1 0 0 1 9 Report acknowledgment Report-acknowledgment
1 0 1 0 10 Undefined
1 0 1 1 11 Undefined

1 1 0 0 12 Cancel segment from block sender
1 1 0 1 13 Cancel acknowledgment Cancel-acknowledgment segment
to block sender

1 1 1 0 14 Undefined Cancel segment from block receiver
1 1 1 1 15 Undefined Cancel-acknowledgment segment
to block receiver

7.1.3 Segment Class Masks

Burleigh et al. Expires - January 2005 [Page 32]
Internet Draft Licklider Transmission Protocol July 2004

For the purposes of this specification, some bit patterns in the
segment type flags field correspond to "segment classes" that are
designated by mnemonics. The mnemonics are intended to evoke the
characteristics shared by all types of segments characterized by
these flag bit patterns.

Burleigh et al. Expires - November 2004 [Page 32]

Internet Draft Licklider Transmission Protocol May 2004

CTRL EXC REQ CLOS Mnemonic Description
---- ---- ---- ---- -------- ---------------------------
0 0 1 - CP Checkpoint

0 0 1 - - 1 EOB End of block;
0 1 0 1
block size = offset + length

1 0 0 0 R RS Report segment;
carries reception claims

1 0 0 1 RA Report acknowledgment Report-acknowledgment segment

1 1 0 0 C Cancellation CS Cancel segment from block sender

1 1 0 1 CA Cancellation acknowledgment CAS Cancel-acknowledgment segment
to block sender

1 1 1 0 CR Cancel segment from block receiver

1 1 1 1 CAR Cancel-acknowledgment segment
to block receiver

1 1 - 0 Cx Cancel segment (generic)

1 1 - 1 CAx Cancel-acknowledgment segment
(generic)

7.1.4 Extensions field

The extension field contains a sequence of zero or more extensions to
the basic segment header.

The first octet of the extensions field contains the number of
extensions present (thus 255 is the maximum number of extensions for
a single segment). In the absence of any extensions, this octet MUST
contain zero.

Each extension consists of a one-octet tag identifying the type of
extension, followed by an extension specification in SDNV-8 format.

The diagram below shows how the expansion zone is constructed.

Burleigh et al. Expires - January 2005 [Page 33]
Internet Draft Licklider Transmission Protocol July 2004

For each extension present, the segment will have a sequence of zero
or more octets of trailer information. Trailer information sequences
appear in the same order as the corresponding extensions. The size
of each trailer information sequence is extension-specific and may be
determined from the tag and specification of the corresponding
extension.

One extension type is defined at this time.

Extension tag Meaning
------------- -------
0x00 LTP authentication extension as defined in Section 13.3
0x01-0xff Reserved

7.2 Segment Content

7.2.1 Data Segment (DS)

The content of a data segment includes client service data and
metadata enabling the receiving client service instance to receive
and make use of that data.

If the data segment is a checkpoint, the segment MUST additionally
include the following two serial numbers (Checkpoint serial number,
Report serial number) to support efficient retransmission. All non-
checkpoint data segments MUST NOT have these two fields and MUST
begin with the

Client service ID field defined below as the first
element of the data segment.

Checkpoint serial number [SDNV-8]

The checkpoint serial number uniquely identifies the checkpoint
among all checkpoints issued by the block sender in a session.
The first checkpoint issued by the sender MUST have this serial
number chosen randomly for security reasons, and it is RECOMMENDED
that the sender use the guidelines in [ECS94] for this. Any
subsequent checkpoints issued by the sender MUST have the serial
number value one more than the last checkpoint serial number
issued. Any retransmission of the checkpoint segment MUST have the
same serial number as the original transmission.

Report serial number [SDNV-8]

If the checkpoint was queued for transmission in response to the
reception of an R segment [Sec 9.13], then its value MUST be the
report serial number value of the R segment that caused the data

Burleigh et al. Expires - November 2004 [Page 33]

Internet Draft Licklider Transmission Protocol May 2004

segment to be queued for transmission.

Otherwise, the value of report serial number MUST be zero.

Client service ID [SDNV-8]

The client service ID client service ID number identifies the upper-level service to
which the segment is to be delivered by the destination LTP
engine. It is functionally analogous to a well-known TCP port
number. If multiple instances of the client service are present
at the destination, multiplexing must be done by the client
service itself on the basis of information encoded within the
transmitted block.

At this time the only LTP client service we envision in the IPN is
the DTN Bundling protocol. The client service ID value assigned to
this client service is the number 1.

Offset [SDNV-16]

Offset indicates the location of the segment's client service data
within the session's transmitted block. It is the number of bytes
in the block prior to the byte from which the first octet of the

Burleigh et al. Expires - January 2005 [Page 34]
Internet Draft Licklider Transmission Protocol July 2004

segment's client service data was copied.

Length [SDNV-16]

The length of the following client service data, in octets.

Client service data [array of octets]

The client service data carried in

If the data segment is a copy of a
subset of the bytes in the original client service data block,
starting at checkpoint, the indicated offset.

7.2.2 Report Segment

The content of an R segment comprises one or more data reception
claims, together with MUST additionally
include the upper and lower bounds of the scope within
the data block to which the claims pertain. It also includes following two serial numbers (Checkpoint serial number
and Report serial number) to support efficient retransmission.

Report Data
segments that are not checkpoints MUST NOT have these two fields in
the header and MUST continue on directly with the client service
data.

Checkpoint serial number [SDNV-8]

The report checkpoint serial number uniquely identifies the report checkpoint
among all
reports checkpoints issued by the block receiver sender in a session.
The first
report checkpoint issued by the receiver sender MUST have this serial
number chosen

Burleigh et al. Expires - November 2004 [Page 34]

Internet Draft Licklider Transmission Protocol May 2004 randomly for security reasons, and it is RECOMMENDED
that the
receiver sender use the guidelines in [ECS94] for this. Any
subsequent
reports checkpoints issued by the receiver sender MUST have the serial
number value
one more than found by incrementing the last report prior checkpoint serial
number issued. Any
retransmission of the R by 1. When a checkpoint segment is retransmitted however,
its serial number MUST have be the same serial number as the original transmission.

Checkpoint when it was originally
transmitted.

Report serial number [SDNV-8]

The value of checkpoint serial number MUST be zero if

If the report
segment is NOT a checkpoint was queued for transmission in response to the
reception of a checkpoint, i.e., an RS [Sec 9.13], then its value MUST be the
reception report is asynchronous; otherwise it is the checkpoint
serial number value of the checkpoint RS that caused the R data segment to be
issued.

Upper bound [SDNV-16]

The upper bound
queued for transmission.

Otherwise, the value of a report serial number MUST be zero.

Client service data [array of octets]

The client service data carried in the segment is a copy of a
subset of the size bytes in the original client service data block,
starting at the indicated offset.

7.2.2 Report Segment (RS)

The content of an RS comprises one or more data reception claims,
together with the upper and lower bounds of the scope within the data
block
prefix to which the segment's reception claims pertain.

Lower bound [SDNV-16]

The lower bound of It also includes two serial
numbers to support efficient retransmission.

Burleigh et al. Expires - January 2005 [Page 35]
Internet Draft Licklider Transmission Protocol July 2004

Report serial number [SDNV-8]

The report serial number uniquely identifies the report among all
reports issued by the block receiver in a session. The first
report issued by the receiver MUST have this serial number chosen
randomly for security reasons, and it is RECOMMENDED that the
receiver use the guidelines in [ECS94] for this. Any subsequent
reports issued by the receiver MUST have the serial number value
found by incrementing the last report serial number by 1. When an
RS is retransmitted however, its serial number MUST be the same as
when it was originally transmitted.

Checkpoint serial number [SDNV-8]

The value of checkpoint serial number MUST be zero if the report
segment is NOT a response to reception of a checkpoint, i.e., the
reception report is asynchronous; otherwise it is the checkpoint
serial number of the checkpoint that caused the RS to be issued.

Upper bound [SDNV-16]

The upper bound of a report segment is the size of the block
prefix to which the segment's reception claims pertain.

Lower bound [SDNV-16]

The lower bound of a report segment is the size of the (interior)
block prefix to which the segment's reception claims do NOT
pertain.

Reception claim count [SDNV-8]

The number of data reception claims in this report segment.

Data reception

Reception claims

Each reception claim comprises two elements: offset and length.

Offset [SDNV-16]

The offset indicates the successful reception of data beginning
at the indicated offset from the lower bound of the report. RS. The
offset within the entire block can be calculated by summing
this offset with the lower bound of the report. RS.

Length [SDNV-16]

The length of a reception claim indicates the number of

Burleigh et al. Expires - January 2005 [Page 36]
Internet Draft Licklider Transmission Protocol July 2004

contiguous octets of block data starting at the indicated
offset (within the scope of the report) that have been
successfully received so far.

Burleigh et al. Expires - November 2004 [Page 35]

Internet Draft Licklider Transmission Protocol May 2004

Reception claims MUST conform to the following rules:

A reception claim's offset shall never be less than zero and
its length shall never be less than 1.

The offset of a reception claim shall always be greater than
the sum of the offset and length of the prior claim, if any.

The sum of a reception claim's offset and length shall never
exceed the difference between the upper and lower bounds of the
report segment.

Implied requests for retransmission of client service data can be
inferred from an R segment's RS's data reception claims. However, *nothing* can
be inferred regarding reception of block data at any offset equal to
or greater than the segment's upper bound or at any offset less than
the segment's lower bound.

For example, if the scope of a report segment has lower bound 0 and
upper bound 6000, and the report contains a single data reception
claim with offset 0 and length 6000, then the report signifies
successful reception of the first 6000 bytes of the block. If the
total length of the block is 6000, then the report additionally
signifies successful reception of the entire block.

If on the other hand, the scope of a report segment has lower bound
1000 and upper bound 6000, and the report contains two data reception
claims, one with offset 0 and length 2000 and the other with offset
3000 and length 500, then the report signifies successful reception
only of bytes 1000-2999 and 4000-4499 of the block. From this we
can infer that bytes 3000-3999 and 4500-5999 of the block need to be
retransmitted, but we cannot infer anything about reception of the
first 1000 bytes.

7.2.3 Report Acknowledgment Segment

The content of an RA segment is simply the report serial number of the R segment RS in
response to which the segment was generated.

Report serial number [SDNV-8]

This field returns the report serial number of the R segment RS being
acknowledged.

7.2.4 Session Management Segments

The C segment carries a single byte reason-code with the following
semantics.

Burleigh et al. Expires - November 2004 January 2005 [Page 36] 37]
Internet Draft Licklider Transmission Protocol May July 2004

Note : the reason we use different cancel segments for the originator
and recipient is to allow a loopback mode to work without disturbing
replay protection.

Cancel segments (Cx) carry a single byte reason-code with the
following semantics :

Reason-Code Semantics
----------- -------------------------------- -------------------------------------
00 CNCLD Client Service canceled session
01 UNREACH Unreachable Client Service
02 RLEXC Retransmission limit exceeded
03-FF Undefined

The CA segments Cancel-acknowledgments (CAx) have no content.

8. Requests from Client Service

In all cases the representation of request parameters is a local
implementation matter, as are validation of parameter values and
notification of the client service in the event that a request is
found to be invalid.

8.1 Transmission Request

In order to request transmission of a block of client service data,
the client service MUST provide the following parameters to LTP:

Client service ID

Destination LTP engine ID

Data to send, as an array of bytes.

Length of the data to be sent.

Quality of service required: reliable or unreliable transmission.

Flow-label, used as a bandwidth management hint; for example, in
the example bandwidth management model described in 6.2 above it
would be used to choose the transmission queue within the queue-set
for the LTP destination.

On reception of a valid transmission request from a client service,
LTP proceeds as follows.

First the array of data to be sent is subdivided as necessary, with
each subdivision serving as the client service data of a single new

Burleigh et al. Expires - January 2005 [Page 38]
Internet Draft Licklider Transmission Protocol July 2004

LTP data segment. The algorithm used for subdividing the data is a
local implementation matter; it is expected that data size
constraints imposed by the underlying communication service, if any,
will be accommodated in this algorithm.

The last (and only the last) of the resulting data segments MUST be
marked as an EOB, with appropriate EOB segment flag bits set
depending on reliable / unreliable transmission [Sec 7.1.2].

Burleigh et al. Expires - November 2004 [Page 37]

Internet Draft Licklider Transmission Protocol May 2004

If the requested quality of service is reliable transmission, then
all data segments resulting from subdivision of the data MUST have
the EXC flag cleared. Moreover, at least the EOB segment MUST also
be marked a checkpoint by having the REQ flag set; zero or more other
data segments (selected according to an algorithm that is a local
implementation matter) MAY additionally have the REQ flag set to act
as
indicate additional checkpoints.

On the other hand hand, if the requested quality of service is unreliable
transmission,
transmission then all data segments resulting from subdivision of the
data MUST have the EXC flag set and REQ flag cleared.

All data segments are appended to the appropriate (conceptual)
transmission queue as specified in the transmission request.

Finally, a session start notice [Sec 10.1] is sent back to the client
service that requested the transmission.

8.2 Cancellation Request

In order to request cancellation of a session, either as sender or as
receiver of the associated data block, the client service must
provide to LTP the session ID of the session to be cancelled. canceled.

On reception of a valid cancellation request from a client service,
LTP proceeds as follows.

First the internal "Cancel session" procedure [Sec 9.19] is invoked.

Next, if the session is being canceled by the block sender, i.e., the
session originator part of the session ID supplied in the
cancellation request is the local LTP engine ID:

If none of the data segments previously queued for transmission as
part of this session have yet been de-queued and radiated, radiated - i.e.,
if the destination engine cannot possibly be aware of this session
- then the session is simply closed; the "Close session" procedure
[Sec 9.20] is invoked.

Burleigh et al. Expires - January 2005 [Page 39]
Internet Draft Licklider Transmission Protocol July 2004

Otherwise, a C segment CS with reason-code value 00 [Sec 7.2.4] MUST be appended to the internal operations queue of the queue-set
bound
queued for transmission to the destination LTP engine specified in
the transmission request that started this session.

Otherwise, (i.e., the session is being canceled by the block
receiver):

If there is no transmission queue-set bound for the block sender

Burleigh et al. Expires - November 2004 [Page 38]

Internet Draft Licklider Transmission Protocol May 2004
(possibly because the local LTP engine is running on a receive-
only device), then the session is simply closed; the "Close
session" procedure [Sec 9.20] is invoked.

Otherwise, a C segment CR with reason-code value 00 [Sec 7.2.4] MUST be appended to the internal operations queue of the queue-set
bound
queued for transmission to the block sender.

9. Internal Procedures

This section describes the internal procedures that are triggered by
the occurrence of various events during the life-time of the 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.

The data segments transmitted in the course of any single LTP session
MUST either all have segment be transmitted reliably (segment type code value less
than 4 (reliable
transmission) 4) or else all have segment unreliably (segment type code value greater than 3
(unreliable transmission). 3).

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 receive-
only device), then the data segment is simply discarded.
Otherwise, if the data segment was transmitted reliably (segment type code less
than 4), reliably, a C segment CR with
reason-code value 01 [Sec 7.2.4] UNREACH MUST be
added to the internal operations queue of the queue-set bound enqueued for transmission to the block
sender; a C segment CR with reason-code value 01 UNREACH SHOULD be similarly added to the internal operations queue bound enqueued
for transmission to the data sender if the data segment was
transmitted unreliably (segment type
code greater than 3) unreliably. [For example, in the case where the block
receiver knows that the sender is functioning in a "beacon"
(transmit-only) fashion, a C segment CR need not be sent]. In either case
the received data segment is discarded.

Burleigh et al. Expires - January 2005 [Page 40]
Internet Draft Licklider Transmission Protocol July 2004

9.1 Start Transmission

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

Burleigh et al. Expires - November 2004 [Page 39]

Internet Draft Licklider Transmission Protocol May 2004

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

9.2 Start Checkpoint Timer

This procedure is triggered by arrival of a link state cue indicating
the de-queuing for transmission (for transmission) of a CP segment, provided that it this
segment either is
also the EOB for a session or if it else was issued in
response to an R
segment RS -- i.e., the segment's report serial number is non-zero. non-
zero.

Response: the expected arrival time of the R segment RS that will be produced
on reception of this CP 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 [Sec 9.5], then this timer
is immediately suspended, because the computed expected arrival time
may require an adjustment that cannot yet be computed.

9.3 Start RS Timer

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

Response: the expected arrival time of the RA segment that will be produced
on reception of this R segment RS 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 [Sec 9.5], then this timer is
immediately suspended, because the computed expected arrival time may
require an adjustment that cannot yet be computed.

9.4 Stop Transmission

This procedure is triggered by 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.

9.5 Suspend Timers

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

Burleigh et al. Expires - January 2005 [Page 41]
Internet Draft Licklider Transmission Protocol July 2004

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

Burleigh et al. Expires - November 2004 [Page 40]

Internet Draft Licklider Transmission Protocol May 2004
on the following procedure:

The nominal 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 margin to account "additional anticipated latency"
(AAL) encompassing anticipated transmission delays other than signal
propagation time. N is determined in an implementation-specific
manner. When LTP is deployed in deep space vehicles, for example,
the one-way light time to the remote engine may be very large while N
normally need only reflect processing and queuing delay at the remote engine; N should margin; it
can be a network management parameter, for which 2 seconds seems to
be a reasonable default value. When LTP is deployed in a terrestrial
"data mule" environment, on the other hand, 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 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.

9.6 Resume Timers

This procedure is triggered by 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. In each case, expected arrival
time is increased by a transmission delay interval that is calculated
as follows:

The nominal 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 margin to account for
processing and queuing delay at the remote engine; again, N should
be a network management parameter, for which 2 seconds seems to be
a reasonable default value. additional anticipated
latency as discussed in Sec 9.5.

If the nominal acknowledge transmission time is greater than the

Burleigh et al. Expires - January 2005 [Page 42]
Internet Draft Licklider Transmission Protocol July 2004

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 acknowledge transmission time.

After adjustment of expected arrival time, each of the suspended
countdown timers is resumed.

Burleigh et al. Expires - November 2004 [Page 41]

Internet Draft Licklider Transmission Protocol May 2004

9.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 [Sec 9.19] is invoked, a C segment CS with reason-code value
02 [Sec 7.2.4] RLEXC is
appended to the transmission queue specified in the transmission
request that started this session, and a transmission cancellation
notice [Sec 10.5] is sent back to the client service that requested
the transmission.

Otherwise, a new copy of the CP segment is appended to the
transmission queue specified in the transmission request that started
this session.

9.8 Retransmit RS

This procedure is triggered by either (a) expiration of a countdown
timer associated with an R segment RS or (b) reception of a CP segment whose
checkpoint serial number is equal to that of one or more previously
issued R segments RSs for the same session -- an unnecessarily retransmitted
checkpoint.

Response: if the number of times any affected R segment RS 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
[Sec 9.19] is invoked, a C segment CR with reason-
code value 02 [Sec 7.2.4] reason-code RLEXC is appended to the queue of internal
operations traffic bound queued for
transmission to the LTP engine that originated the session, and a
reception cancellation notice [Sec 10.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 R segment RS is appended to the
queue of internal operations traffic bound queued for transmission

Burleigh et al. Expires - January 2005 [Page 43]
Internet Draft Licklider Transmission Protocol July 2004

to the LTP engine that originated the session.

9.9 Signify Segment Arrival

This procedure is triggered by the arrival of a data segment, but
only when either (a) the data segment is being transmitted unreliably
or (b) segment arrival notification has been authorized for the local
LTP engine by client service or network management.

Burleigh et al. Expires - November 2004 [Page 42]

Internet Draft Licklider Transmission Protocol May 2004

Response: a segment arrival notice [Sec 10.2] is sent to the
specified client service.

9.10 Signify Block Reception

This procedure is triggered by the arrival of a data segment, but
only when either (a) the segment is also the EOB segment for a block
being transmitted unreliably or (b) the segment is also a CP segment
for a reliably transmitted block, and the EOB for this session has
been received (including (ensuring that the data block's size is known; this
includes the case where this segment itself is the EOB segment) and the data block's size is known, segment), and
all data in the block being transmitted in this session have been
received.

Response: a block reception notice [Sec 10.3] is sent to the
specified client service.

9.11 Send Reception Report

This procedure is triggered by either (a) reception of a CP segment
whose checkpoint serial number is not equal to that of any previously
issued R segment RS or (b) an implementation-specific circumstance pertaining
to a particular block reception session for which no EOB has yet been
received ("asynchronous" reception reporting). The response in
either case is the same.

Response: if the number of reception reports issued errors detected for this session exceeds the a
limit established for the local LTP engine by network management,
then the affected session is canceled: the "Cancel session" procedure
[Sec 9.19] is invoked, a C segment CR with reason-
code value 02 [Sec 7.2.4] reason-code RLEXC is appended to the
queue of internal operations traffic bound for the LTP engine that
originated the session, and a reception cancellation notice [Sec
10.6] is sent to the client service identified in each of the data
segments received in this session. One possible limit is to place a
maximum on the number of reception reports which can be issued for
the session.

Otherwise, a reception report is issued as follows.

Burleigh et al. Expires - January 2005 [Page 44]
Internet Draft Licklider Transmission Protocol July 2004

As many R segments RSs are 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.
They are appended to the queue of internal operations traffic bound
for the LTP engine that originated the indicated session. If
production of the reception report was triggered by reception of a
checkpoint:

The upper bound of the report is the upper bound (the sum of the
offset and length) of the checkpoint data segment.

If the checkpoint was itself issued in response to a report
segment, then this report is a "secondary" reception report and

Burleigh et al. Expires - November 2004 [Page 43]

Internet Draft Licklider Transmission Protocol May 2004
the lower bound of the report is that earlier report segment's
lower bound. Otherwise, this report is a "primary" reception
report and the lower bound of the report is the upper bound of the
prior primary reception report issued for this session.

Otherwise, i.e., the reception report is asynchronous:

The upper bound of the report is the maximum upper bound among all
data segments received so far for this session.

The lower bound of the report is the upper bound of the prior
primary reception report issued for this session.

9.12 Signify Transmission Completion

This procedure is triggered by either (a) reception of an R segment RS whose
reception claims taken together with the reception claims of all
other report segments RSs previously received in the course of this session indicate
complete reception of an entire data block, or (b) arrival of a link
state cue indicating the de-queuing (for transmission) of an EOB
segment for a block transmitted unreliably.

Response: a transmission completion notice [Sec 10.4] is sent to the
client service that requested the transmission identified in the
segment header and the session is closed: the "Close session"
procedure [Sec 9.20] is invoked.

9.13 Retransmit Data

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

Response: first, an RA segment with the same report serial number as the R segment RS
is appended to the queue of internal operations traffic bound for the
LTP engine that originated the indicated session. If the R segment RS is
redundant -- i.e., either the indicated session is unknown (if for (for

Burleigh et al. Expires - January 2005 [Page 45]
Internet Draft Licklider Transmission Protocol July 2004

example, the R segment RS is received after the session has been completed or
canceled), or the R segment's RS's report serial number is equal to that of a
previously received report segment for this session -- 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.

All retransmission buffer space occupied by data whose reception is
claimed in the report segment can be released.

Burleigh et al. Expires - November 2004 [Page 44]

Internet Draft Licklider Transmission Protocol May 2004

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

If the number of CP segments issued errors for this session exceeds the 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 [Sec 9.19] is invoked, a C segment CO with
reason-code value 02 [Sec 7.2.4] RLEXC is appended to the transmission queue specified
in the transmission request that started this session, and a
transmission cancellation notice [Sec 10.5] is sent back to the
client service that requested the transmission. One possible
limit here is a maximum on the number of CP segments which may be
issued for the session.

Otherwise, new data segments encapsulating all block data whose
non-reception is implied by the reception claims are appended to
the transmission queue specified in the transmission request that
started this session. The last - and only the last - such segment
must me be marked as a CP segment and must contain the report serial
number of the received R segment. RS.

9.14 Stop RS Timer

This procedure is triggered by reception of an RA segment. RA.

Response: the countdown timer associated with the original R
segment RS
(identified by the report serial number of the RA segment) is
deleted. If no other countdown timers associated with R
segments existed RSs exist
for this session, then the session is closed: the "Close session"
procedure [Sec 9.20] is invoked.

9.15 Start Cancel Timer

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

Burleigh et al. Expires - January 2005 [Page 46]
Internet Draft Licklider Transmission Protocol July 2004

Response: the expected arrival time of the CA segment CAx that will be
produced on reception of this C segment Cx 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 [Sec 9.5] then this
timer is immediately suspended, because the computed expected
arrival time may require an adjustment that cannot yet be
computed.

9.16 Retransmit Cancellation Segment

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

Burleigh et al. Expires - November 2004 [Page 45]

Internet Draft Licklider Transmission Protocol May 2004 Cx.

Response: if the number of times this C segment Cx 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 [Sec 9.20] is invoked.

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

9.17 Acknowledge Cancellation

This procedure is being sent triggered by the block sender, then the
appropriate transmission queue is the one specified reception of a Cx.

Response: in the case of a CS where there is no transmission request that started this session; otherwise, the
appropriate transmission queue is the queue of internal operations
traffic
queue-set bound for the LTP engine that originated the session.

9.17 Acknowledge Cancellation

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

Response: if the local segment is not the block sender for the
block identified in the C segment and there is no transmission
queue-set bound for the block sender segment's
session (possibly because the local LTP engine is running on a
receive-only device), then no action is taken. Otherwise, Otherwise:
If the received segment is a CA CS, a CAS is appended to the queue
of internal operations traffic bound for the LTP engine that
sent the CS.

Otherwise (the received segment is a CR), a CAR is appended to
the queue of internal operations traffic bound for the LTP
engine that sent the
C segment. CR.

It is possible that the C segment is being Cx has been retransmitted because a
previous CA responding acknowledgment CAx 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 that session is locally canceled: the "Cancel session"
procedure [Sec 9.19] is invoked and a reception cancellation
notice [Sec 10.6] is sent to the client service identified in each
of the data segments received in this session. Finally, the

Burleigh et al. Expires - January 2005 [Page 47]
Internet Draft Licklider Transmission Protocol July 2004

session is closed: the "Close session" procedure [Sec 9.20] is
invoked.

9.18 Stop Cancellation Timer

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

Response: the session of which the segment is one token is closed,
i.e., the "Close session" procedure [Sec 9.20] is invoked.

9.19 Cancel Session

This procedure is triggered internally by one of the other

Burleigh et al. Expires - November 2004 [Page 46]

Internet Draft Licklider Transmission Protocol May 2004
procedures described above.

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

9.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 (such as the timer associated with a C segment) Cx) are deleted. All
other state information regarding the session is deleted;
existence of the session is no longer recognized.

10. Notices to Client Service

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

10.1 Session Start

The LTP engine returns the Session ID of the new transmission
session when a session start notice is delivered.

A session start notice informs the client service of the
initiation of a transmission session in response to a transmission
request from that client service. 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.

Burleigh et al. Expires - January 2005 [Page 48]
Internet Draft Licklider Transmission Protocol July 2004

10.2 Data Segment Arrival

The parameters provided by the LTP engine when a data segment
arrival notice is delivered are:

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

Burleigh et al. Expires - November 2004 [Page 47]

Internet Draft Licklider Transmission Protocol May 2004

Length of the data segment's content

Source LTP engine ID

A flag indicating if this segment was an EOB segment or not.

Data segment arrival notices deliver block data incrementally, as
it is received. This enables the receiving client service
instance to make use of partial data immediately, rather than
potentially waiting hours or days for the retransmission of
missing segments and the ultimate delivery of the completed block.
Incremental block data delivery is mandatory for unreliable
transmission, because there's never any guarantee that the EOB
segment- which is required in order to deliver a complete block -
will ever be received at all. Incremental delivery also enables
the client service to cancel reception of a block, if necessary.

10.3 Block Reception

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

Session ID of the transmission session.

Array of client service data bytes that constitutes the block

Length of the block.

Source LTP engine ID.

A block reception notice delivers a complete data block to the
client service.

10.4 Transmission Completion

Burleigh et al. Expires - January 2005 [Page 49]
Internet Draft Licklider Transmission Protocol July 2004

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

A transmission completion notice informs the client service that
the indicated session has successfully completed; the destination
LTP engine has received the entire data block.

10.5 Transmission Cancellation

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

A transmission cancellation notice informs the client service that

Burleigh et al. Expires - November 2004 [Page 48]

Internet Draft Licklider Transmission Protocol May 2004
the indicated session was terminated, either by decision of the
destination client service instance or due to violation of a
retransmission limit in the local LTP engine. There is no
assurance that the destination client service instance received
the data block.

10.6 Reception Cancellation

The sole parameter provided by the LTP engine when a reception
cancellation notice is delivered is the Session ID of the
transmission session.

A reception cancellation notice informs the client service that
the indicated session was terminated, either by decision of the
source client service instance or due to violation of a
retransmission limit in the local LTP engine. The complete data
block will not be delivered.

11. Requirements from the Operating Environment

LTP requires support from its operating environment (which
includes network management activities) and link-state cues from
the data-link layer State Transition Diagrams

The state transition diagrams for its operations. a reliable block delivery
session are described in this section. The local data-link layer needs terms "sender" and
"receiver" are here used to inform LTP whenever the link refer to
a specific LTP destination is brought up or torn down. Similarly,
the operating environment needs to inform the local LTP engine
whenever it is known sending and receiving
lobes of this single session state machine; note that a remote any LTP
engine is set to begin
communication with might at any moment comprise any number of session state
machine nodes of both types.

The diagrams do not include the local engine from behavior of the operating schedules.
LTP also needs to be able to query sender and
receiver under accelerated delivery or accelerated retransmission,
nor in the current speed-of-light case where a reception report must comprise multiple
report segments.

<<We propose to
its peer engine from update the operating environment to calculate its
timers.

A MIB (Management Information Base) diagrams with the above parameters
filled accelerated features

Burleigh et al. Expires - January 2005 [Page 50]
Internet Draft Licklider Transmission Protocol July 2004

in by the local data-link layer and the operating
environment periodically, should be made available for the LTP
engine for its operations. The exact details of the MIB are beyond
the scope subsequent versions of this document.

LTP also requires the underlying data-link layer to perform data
integrity check of the segments received. Specifically, the data-
link layer is expected to detect any segments received corrupted,
and to silently discard them.

12. Security Considerations

<<This section is really only an initial set of notes resulting
from discussions on and off the DTNRG list. Further analysis will draft.>>

Burleigh et al. Expires - November 2004 January 2005 [Page 49] 51]
Internet Draft Licklider Transmission Protocol May July 2004

be required as LTP itself develops and is implemented.>>

11.1 Sender
LTP is designed as a hyper-datalink layer to primarily do ARQ of
data transmissions over a point-to-point link exhibiting some or
all of the following characteristics: high delays, high BERs and
intermittent, possibly strictly scheduled connectivity.

However, how "point-to-point" the link is physically, depends on
the underlying datalink. For Sender State Transition Diagram

+----+ +----+ Rcv RS;
Rcv CR; | V V | Snd RA
Snd CAR | +-------------+--+
+--+ CLOSED |<-----------------+----+----------------+
+------+------+ ^ ^ |
| | | |
| Blk Trans Req | | |
+----+ | | | |
Snd DS | V V Rcv CAS | | CS TE, |
(NOT EOB/CP) | +-------------+ | | RL EXC |
+--+PRI_BLK_TRANS|==> | | |
+------+------+ | | |
| | | |
Snd DS (EOB/CP), | | | |
Start CP Tmr | | | |
| | | |
+-------------------+ | | | |
| | | | | |
| CP TE,+----+ | | | | +-------+ |
| RL NOT EXC;| V V V | | V | |
| Rxmt CP,| +-------------+ +---+----+----+ | |
| Restart +-+ CP_SENT |==> | CANCEL_SENT |==> | |
| CP Tmr +------+---+--+ +-----------+-+ | |
| | | CP TE, RL EXC; ^ | | |
| Rcv RS; | | Snd CS | +-------+ |
| Stop CP Tmr, | | Start CS Tmr | CS TE, |
| Snd RA | | | RL NOT EXC; |
| V +-------------------+ Rxmt CS, |
| +-------------+ Restart CS Tmr |
| |CHK_BLK_RCVD |==> |
| +----+-----+--+ |
| Blk NOT / | Blk rcvd fully |
| rcvd fully / | |
| / | |
| | +-------------------------------------------+
| | +--------+
| V V | KEY
| +-------------+ | ---
| +SEC_BLK_TRANS|==> | ==>: Async Cncl Req
| +------+---+--+ | RL : Retrans. limit
| | | | EXC: Exceeded
| Snd missing | +--------+ TE : Timer Expiry
| DS (CP), | Snd missing DS
| Start CP Tmr | (NOT CP)
+---------------+

Burleigh et al. Expires - January 2005 [Page 52]
Internet Draft Licklider Transmission Protocol July 2004

CLOSED

The sender is initially in this state. Upon reception of a
block transmission request from the upper layer, the sender
moves to the PRI_BLK_TRANS state.

The sender enters CLOSED state upon having sent an RA (for a
fully received block) or a CAR, or upon having received a CAS,
or upon exceeding a retransmission limit, while in any state
other than CLOSED. After entering CLOSED state in this way,
the sender lobe of the session state machine can no longer move
to any other state. If an RS or CR arrives at the sender when
it is in this condition (possibly due to retransmission by the
receiver, in the event that either the RA/CAR was corrupted or
the corresponding count-down timer expired prematurely), the
sender retransmits the relevant RA/CAR but remains in the
CLOSED state.

PRI_BLK_TRANS (Primary Block Transmission)

The sender segments the received block respecting the current
link MTU and enqueues the DSs for transmission. Upon
transmission of the last DS (marked EOB, CP), the CP timer is
started and the sender enters the CP_SENT state.

CP_SENT (Checkpoint Sent)

In this state, the sender expects an RS acknowledging the CP DS
sent most recently. Upon reception of the RS corresponding to
that CP, the CP timer is stopped, an RA acknowledging the RS is
sent, and the sender enters the CHK_BLK_RCVD state.

If the CP timer expires before the expected RS arrives, a check
is made to see if the Retransmission Limit (RL) set by network
management is exceeded by the number of times this CP has been
retransmitted. If the RL is not exceeded, a duplicate CP
segment is queued for transmission and the CP timer restarted
when that transmission occurs. The sender remains in CP_SENT
state.

On the other hand, if the RL has been reached already at the
time the CP timer expires, a CS with reason-code RLEXC is
queued for transmission, and the CS timer is started upon
transmission. The sender then enters the CANCEL_SENT state.

CHK_BLK_RCVD (Check Block Received)

In this state, the sender checks if the entire block has been

Burleigh et al. Expires - January 2005 [Page 53]
Internet Draft Licklider Transmission Protocol July 2004

reported as received, aggregating all the RSs received so far.
If so, the sender enters the CLOSED state; if not, the
SEC_BLK_TRANS state is entered.

SEC_BLK_TRANS (Secondary Block Transmission)

In this state, the sender queues for retransmission all the
data segments reported missing from the last RS received. Upon
transmission of the last DS retransmitted (marked CP), the CP
timer is started and the sender returns to the CP_SENT state.

CANCEL_SENT

In this state, the sender waits for the CAS acknowledging the
transmitted CS. Upon receiving the CAS, the sender returns to
the CLOSED state.

If the CS timer expires before reception of the CAS, and the RL
is not exceeded, a duplicate CS (with the same reason-code
value sent last) is queued for transmission, and the CS timer
is restarted upon transmission. However, if the CS timer
expires and the RL value has been reached in the number of
times this CS has been transmitted, the sender simply returns
to the CLOSED state.

Async Cncl Req (Asynchronous Cancel Request)

An asynchronous cancel request might be received by a sender in
any state. If the request is received locally from the client
service in a Cancel Request while the sender is in any state
other than CLOSED or CANCEL_SENT, a CS with reason-code CNCLD
is queued for transmission to the receiver and the session
enters the CANCEL_SENT state. On the other hand, if the cancel
request was received from the receiver in a CR segment, a CAR
segment is queued for transmission in response, and the sender
returns to the CLOSED state.

Burleigh et al. Expires - January 2005 [Page 54]
Internet Draft Licklider Transmission Protocol July 2004

11.2 Receiver
LTP Receiver State Transition Diagram
+----+ +--------------------------+--+
Rcv CS; | V V ^ ^
Snd CAS | +-------------+ Rcv CAR| | CR TE,
+--+ CLOSED | | | RL EXC
+-------------->+------+------+ | |
| | Clnt svc. doesn't exist; | |
| Rcv DS; | Snd CR, Start CR Tmr | |
| Start Session | +------------------+ | | +-----+
| V / V | | V |
| +----------------+ +-----+--+----+ |
| | FIRST_DS_REC |==> | CANCEL_SENT |==>|
| +------+-------+-+ +-----------+-+ |
| Rcv DS (EOB, CP) | | Rcv DS ^ |_____|
| | | (NOT CP) +------+ | CR TE,
| | V V | | RL NOT EXC;
| | +--------------+ | | Rxmt CR,
| | | PRI_BLK_REC |==> | | Restart CR Tmr
| | +------------+-+ | |
| | / |______| +-----------------+
| | / Rcv DS Rcv DS |
| +------------+ | | (EOB, CP) (NOT CP) RS TE, |
| | V V V RL NOT EXC; |
| | +-------------+ Rcv CP; Rxmt RS, |
| | |CHK_BLK_RCVD |==> Rxmt RS Restart RS Tmr |
| | +-+-----------+ Blk rcvd fully; +--+ +------+ |
| | | | Snd RS, | V V | |
| | | | Start RS Tmr +-+----------+ | |
| | Rcv CP; | +------------------>+ CLOSE_WAIT |==> | |
| | Rxmt RS | Blk NOT rcvd +-+--+-----+-+ | |
| | +---+ | fully; Snd RS, Rcv RA; | | |______| |
| | | | | Start RS Tmr Stop RS Tmr | | |
| | | V V | | |
| | | +-------------+<---+ RS TE, | | RS TE, |
| | +--+ RPT_SENT |==> | RL NOT EXC; | | RL EXC; |
| | +----+---+--+-+ | Rxmt RS, | | Snd CR, |
| | | | |______| Restart RS Tmr / | Start CR Tmr |
| | Rcv DS | | | | |
| |(NOT CP) | +---------------------------|----+------------------+
| | +---+ | Rcv RA; RS TE, |
| | | V V Stop RS Tmr RL EXC; \ KEY
| | | +-------------+ Snd CR, | ---
| | +--+ SEC_BLK_REC |==> Start CR Tmr | ==>: Async Cncl Req
| | +------+------+ | RL : Retrans. limit
| | | Rcv DS (CP) | EXC: Exceeded
| +------------+ | TE : Timer Expiry
+-----------------------------------------------+

Burleigh et al. Expires - January 2005 [Page 55]
Internet Draft Licklider Transmission Protocol July 2004

CLOSED

The receiver is in the CLOSED state until the arrival of the
session's first DS. At that time, the receiver enters the
FIRST_DS_REC state.

The receiver enters CLOSED state upon having sent a CAS, or
upon having received an RA (for a fully received block) or a
CAR, or upon exceeding a retransmission limit, while in any
state other than CLOSED. After entering CLOSED state in this
way, the receiver can no longer move to any other state. If a
CS arrives at the receiver when it is in this condition
(possibly due to retransmission by the sender, in the event
that either the CAS was corrupted or the corresponding count-
down timer expired prematurely), the receiver retransmits the
relevant CAS but remains in the CLOSED state.

FIRST_DS_REC (First Data Segment Received)

In this state, the receiver considers the DS received and
checks to see if the referenced client service is reachable. If
not, the receiver schedules a CR with reason-code UNREACH for
transmission, starts a CR timer upon transmission, and then
enters the CANCEL_SENT state.

Otherwise (if the client service exists): if the DS is marked
EOB and CP, (a single-segment block transmission), the receiver
enters the CHK_BLK_RCVD state; if not, it enters the
PRI_BLK_REC state.

PRI_BLK_REC (Primary Block Reception)

The receiver stays in this state until receiving the last
segment of primary block transmission, marked with EOB, CP.
When the EOB, CP marked DS is received, the receiver enters the
CHK_BLK_RCVD state.

CHK_BLK_RCVD (Check Block Received)

In this state the receiver checks to see if the block has been
received fully. If so, it queues an RS claiming successful
reception for transmission, starts an RS timer upon
transmission, and then enters the CLOSE_WAIT state.

Otherwise, if there are still holes in the block transmitted,
the receiver queues for transmission an RS selectively

Burleigh et al. Expires - January 2005 [Page 56]
Internet Draft Licklider Transmission Protocol July 2004

acknowledging the received segments of data, starts an RS timer
upon transmission of the RS, and then enters the RPT_SENT
state.

CLOSE_WAIT

In this state, the receiver expects the arrival of an RA
acknowledging the RS most recently sent. Upon arrival of the
RS, it returns to the CLOSED state.

If the RS timer expires before the arrival of the RA, the
sender checks to see if the Retransmission Limit (RL) set by
network management was exceeded by the number of times this RS
has been retransmitted. If so, it schedules a CR with reason-
code RLEXC for transmission, starts the CR timer upon
transmission of the CR, and enters the CANCEL_SENT state. If
the RL value was not exceeded, the receiver queues a duplicate
RS for transmission, starts the RS timer upon transmission, and
stays in CLOSE_WAIT state.

RPT_SENT (Report Sent)

Much like the CLOSE_WAIT state, the receiver expects an RA in
this state. Upon reception of the RA, the receiver stops the RS
timer, and enters the SEC_BLK_REC state.

If the RS timer expires before arrival of the RA and the RL is
not exceeded by the number of times this RS has been
retransmitted, the receiver queues a duplicate RS for
transmission and starts an RS timer upon transmission of the
RS. If the RL has been reached, the receiver queues a CR with
reason-code RLEXC, starts a CR timer upon its transmission, and
then enters the CANCEL_SENT state.

SEC_BLK_REC

The receiver stays in this Secondary Block Reception State
while continuing to receive non-checkpoint DSs constituting
recovery of the segments reported missing. When a checkpoint DS
is received, the receiver goes back to the CHK_BLK_RCVD state
to see if the block reception is complete.

CANCEL_SENT

In this state, the receiver waits for the CAR acknowledging the
transmitted CR. Upon receiving the CAR, it returns to the
CLOSED state.

Burleigh et al. Expires - January 2005 [Page 57]
Internet Draft Licklider Transmission Protocol July 2004

If the CR timer expires before reception of the CAR, and the RL
is not exceeded, a duplicate CR (with the same reason-code
value sent last) is queued for transmission and the CR timer is
restarted upon transmission. However, if the CR timer expires
and the RL value has been exceeded by the number of times this
CR has been retransmitted, the receiver returns to the CLOSED
state.

Async Cncl Req (Asynchronous Cancel Request)

An asynchronous cancel request might be received by an LTP
receiver in any state. If the request is received locally from
the client service in a Cancel Request while in any state other
than CLOSED or CANCEL_SENT, a CR with reason-code CNCLD is
queued for transmission to the sender and the receiver enters
the CANCEL_SENT state. On the other hand, if the cancel
request was received from the sender in a CS segment, a CAS
segment is queued for transmission in response and the receiver
returns to the CLOSED state.

12. Requirements from the Operating Environment

LTP requires support from its operating environment (which
includes network management activities) and link-state cues from
the data-link layer for its operations.

The local data-link layer needs to inform LTP whenever the link to
a specific LTP destination is brought up or torn down. Similarly,
the operating environment needs to inform the local LTP engine
whenever it is known that a remote LTP engine is set to begin
communication with the local engine based on the operating
schedules. LTP also needs to be able to query the current
distance (in light seconds) to any peer engine in order to
calculate timeout intervals in a typical deep-space environment.

A MIB (Management Information Base), with the above parameters
filled in by the local data-link layer and the operating
environment periodically, should be made available for the LTP
engine for its operations. The exact details of the MIB are,
however, beyond the scope of this document.

In the absence of the use of LTP authentication [Sec 13.3] LTP
also requires the underlying data-link layer to perform data
integrity check of the segments received. Specifically, the data-
link layer is expected to detect any corrupted segments received
and to silently discard them.

13. Security Considerations

Burleigh et al. Expires - January 2005 [Page 58]
Internet Draft Licklider Transmission Protocol July 2004

There is a clear risk that unintended receivers can listen in on
LTP transmissions over satellite and other radio broadcast
datalinks. Such unintended recipients of LTP transmissions may
also be able to manipulate LTP segments at will.

Hence there is a potential requirement for confidentiality,
integrity and anti-DoS (Denial of Service) security services and
mechanisms.

In particular, DoS problems are more severe for LTP compared to
other typical internet protocols because LTP inherently retains
state for long periods, and has very high time-out values.
Further, it could be difficult to reset LTP nodes to recover from
an attack. Thus any adversary who can actively attack an LTP
transmission has the potential to create severe DoS conditions for
the LTP receiver.

To give a terrestrial example - were LTP to be used in a deep-space link using radio
datalink, say sparse
sensor network, DoS attacks could be mounted resulting in nodes
missing critical information, for example, communications schedule
updates. In such cases, a single successful DoS attack could take
a node entirely off the network until the node is physically
visited and reset.

Even for deep space applications of LTP, we do need to consider
certain terrestrial attacks, in particular those involving
insertion of messages into an on-going session (usually without
having seen the exact bytes of the previous messages in the
session). Such attacks are talking from a Deep-Space-Network giant dish
antenna likely in the presence of firewall
failures at various nodes in the network, or due to Trojan
software running on an orbiter authorized host.

Many message insertion attacks will depend on Mars, the signal could attacker
correctly "guessing" something about the state of the LTP peers,
but experience shows that successful guesses are easier than might
be received thought [DDJ].

13.1 Security Mechanisms and Layering Considerations

In this section we consider the appropriate layer(s) at which
security mechanisms can best be deployed to increase the security
properties of LTP.

The Application layer (above-LTP)

Higher layer security mechanisms clearly protect LTP payload,
but leave LTP headers open. Such mechanisms provide little or
no protection against DoS type attacks against LTP, but may

Burleigh et al. Expires - January 2005 [Page 59]
Internet Draft Licklider Transmission Protocol July 2004

well provide sufficient data integrity and ought to be able to
provide data confidentiality.

The LTP layer

An authentication header (similar to IPSEC [AH]) can help
protect against replay attacks and
processed by any other orbiter bogus packets.
However, an adversary may still see the LTP header of segments
passing at by in the same time ether. This approach also requires some key
management infrastructure to be in the
Mars orbiter's reception area, place in order to provide
strong authentication, which could potentially cover
hundreds or thousands of square miles. Similarly a link
transmitting data from may not always be an orbiter to a ground-rover acceptable
overhead. Such an authentication header could have mitigate against
many DoS attacks.

Similarly, a
reception-coverage area of tens of square miles. So there is an
inherent risk that of unintended receivers listening in on LTP
transmissions over such datalinks.

Such promiscuous recipients of our LTP transmissions confidentiality service could
potentially replay the transmissions sent, twiddle with control
bits in the be defined for LTP
payload and (some) header before they do so (more dangerous fields. However, this seems less
attractive since (a) confidentiality is the
case when they make the bits claim arguably better
provided either above or below the LTP segment to be layer, (b) key
management for such a Cancel
segment closing the session). Such problems are more severe service is harder (in a high-delay
context) than for an integrity service, and (c) forcing LTP compared
engines to other terrestrial Internet protocols because LTP
inherently does a lot attempt decryption of state retention (to handle incoming segments can in
itself provide a DoS opportunity.

Further, within the high
delays and intermittent connectivity of its links), has very high
time-out values and LTP nodes may be quite difficult layer we can make various design
decisions to reset. reduce the probability of successful DoS attacks.
In
other words, by design, there is a long delay before LTP gives up
on a session. Thus any such adversary listening particular, we can mandate that values for certain fields in on the LTP
transmissions has
the potential to create severe DoS conditions header (session numbers, for an LTP receiver.

To give example) be chosen randomly.

The Datalink layer (below-LTP)

The lower layers can clearly provide confidentiality and
integrity services, although such security may result in
unnecessary overhead (if a terrestrial example - were service provided is not required for
all LTP to sessions, for example) and loss of flexibility.
However, the lower layers may well be used in a sparse
sensor network, then denial the optimal place to do
compression and encryption.

13.2 Denial of service Service Considerations

Implementers SHOULD consider the likelihood of the following DoS
attacks :

A fake Cx could be mounted
which would result in nodes missing critical information, e.g.
communications schedule updates. In such cases, inserted, thus bringing down a single DoS
attack success session.

Various acknowledgment segments (RA, RS, etc.) could take a node entirely off the network until
the node is physically visited be
deleted, causing timers to expire, and reset.

Even in has the deep space cases, we do need potential to consider some
terrestrial based attacks, in particular those involving insertion
of
disable communication altogether if done with a message into an on-going session (usually without having seen
the exact bytes knowledge of
the previous messages in the session). communications schedule. This could arise due to firewall failures at various points or due to
Trojan software running on an authorized host.

Such attacks may depend on the attacker correctly "guessing" about be achieved either by

Burleigh et al. Expires - November 2004 January 2005 [Page 50] 60]
Internet Draft Licklider Transmission Protocol May July 2004

the state of LTP nodes, but it is worth noting that patterns of
deep space communication may well be considered guessable from the
Earth (e.g.

mounting a session to DoS attack on a Mars rover is only going lower layer service in order to happen
while that rover is visible
prevent it from sending an acknowledgment segment, or by simply
jamming the Earthstation -- all public
information) and the delay-tolerance inherent in LTP transmission (all of which are more likely for
terrestrial applications of LTP).

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

An attacker may decrease
the required accuracy of such guesses. Most of flood a node with segments for the attacks
concerned here are DoS attacks.

12.1 Mechanisms internal
operations queue [Sec 6.2] and Layering Considerations

There is thus a real need to consider security prevent transmission of LTP
transmissions, so we need
legitimate data segments.

An attacker could attempt to consider (to the extent possible) fill up the
appropriate layer(s) at which security mechanisms can best be
deployed.

The Application layer (above-LTP)

This seems like storage in a reasonable approach node by
sending many large messages to protect it. In terrestrial LTP data, but
would leave
applications this may be much more serious since spotting the
additional traffic may not be possible from any network
management point.

<<More TBD>>

LTP headers open. The headers carry information
on where includes the transmission is coming from, which could following anti-DoS mechanisms:

Session numbers MUST be
valuable in itself. Further, this approach provides little partly random making it harder to
insert valid segments.

A node which suspects that either it or
no protection against its peer is under DoS type attacks against LTP.

The LTP layer

Security at this layer offers nice authentication
possibilities. For example, an authentication header (like
that in IPSEC [AH]) can help to protect against replay attacks
and bogus packets. However, an adversary can still see the LTP
header of
attack could frequently checkpoint its data segments passing by in (if it
were the ether. This approach also
requires some key management infrastructure be in place in
order to provide strong authentication.

The Datalink layer (below-LTP)

Providing encryption/authentication in sender) or send asynchronous RSs (if it were the layer(s) below LTP
has some nice properties, like being able
receiver), thus eliciting an earlier response from its peer or
timing out earlier due to do encryption on-
chip in hardware, making it fast. However, depending on the
datalink we may be forced failure of an attacker to use encryption /
respond.

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

An authentication on
all header as defined in Section 13.3.

Replay handling as defined in Section 13.5.

13.3 LTP sessions which may not Authentication

The LTP Authentication mechanism MAY be required. A more flexible
scheme might enable us used to do encryption / provide
cryptographic authentication on
only critical information sessions. For example we might want
it only for commands that ask a rover to reinstall a new OS
image and reboot; and may be not so much when we are
transmitting a picture (though this can be hard to achieve
without layering violations). Security provided by the
datalink may result in unnecessary overhead and lessens
flexibility, but may well be of the optimal place to include segment.

Implementations MAY support this extension field. If they do not

Burleigh et al. Expires - November 2004 January 2005 [Page 51] 61]
Internet Draft Licklider Transmission Protocol May July 2004

compression and encryption.

12.2 Denial

support this header then they MUST ignore it.

The LTP authentication extension field has extension tag value
0x00.

<<Check that ignoring is ok for all cases of Service Considerations

Potential DoS attack points

Implementers SHOULD consider response
generation.>>

LTP authentication requires three new fields, the following DoS attacks :

A fake C segment could be inserted thus bringing down a
session.

Various ACK messages may be deleted causing timers to expire
which could deny service if done with knowledge first two of
which are carried in the
communications schedule. One possible way to achieve this would
be to mount a denial extensions field of service attack on a lower layer device
in order to prevent it sending an ACK, or perhaps to simply jam the transmission (all of which are more likely for terrestrial
applications LTP header, and
the third of LTP). An attacker might also flip some bits, which is (hopefully!) tantamount to deleting that message. carried in the segment trailer.

The fields which are carried in the header extensions field are:

Ciphersuite: an eight bit integer value with values defined
below.

KeyID: An attacker may flood SDNV-8 whose value MUST contain a node with "internal" messages (using key identifier, the terminology
interpretation of section 6.2) which require processing, thus
preventing "real" data segments is out of scope for this specification
(that is, implementers MUST treat these KeyID fields as raw
octets, even if they contained an ASN.1 DER encoding of an
X.509 IssuerSerial construct [PKIXPROF], for example.

The fields MUST be present in the first segment from being transmitted.

An attacker could attempt to fill up the storage in some node
by sending many large messages to it. In terrestrial LTP
applications this may
session which uses LTP authentication, but MAY be much more serious since spotting the omitted from
subsequent segments in that session. To guard against additional traffic may not be possible
problems arising from any network
management point.

- <<More TBD>>

Anti-DoS measures

<<We are considering including some or all (or none!) of the
following anti-DoS measures lost segments, implementations SHOULD, where
bandwidth allows, include these fields in future versions a number of this
specification:

A value in C segments that increases the likelihood that in
the
message is genuine -- possibly using LTP session.

The field carried as a hash over some previous
data that trailer extension is assumed to have gotten through.

Providing a mechanism whereby a node the AuthVal field. It
contains the authentication value, which considers that it is
under DoS attack can use frequent checkpoints hopefully
eliciting an earlier response from the real receiver either a MAC or else
timing out earlier due to the failure of a
digital signature. This is itself a structured field whose length
and formatting depends on the attacker ciphersuite.

We define three ciphersuites in this specification. Our approach
here is to
respond. "hardcode" all algorithm options in a single
ciphersuite value - 255 potential ciphersuites are supported by
this version of LTP.

Ciphersuite Value
----------- -----
OriginAuth 0
Signature 1
NULL 255

1. OriginAuth Ciphersuite

Burleigh et al. Expires - November 2004 January 2005 [Page 52] 62]
Internet Draft Licklider Transmission Protocol May July 2004

Mandating that serial numbers (checkpoint serial numbers,
report serial numbers) begin each session anew using random
numbers rather than from 0. Maintaining serial number ordering
across multiple sessions as

The OriginAuth ciphersuite involves generating a further option (two sides both
knowing this trick can get message
authentication code (MAC) over the benefit, without hurting a node
that doesn't maintain this cross-session state.)

Add a Destination Engine ID LTP segment and appending
the resulting AuthVal field in segments for to provide
some simple protection against replay attacks (the
effectiveness the end of this countermeasure will depend upon lower
layer data integrity.)

A node might provide an interface to its higher layers which
allows the higher layers to indicate segment. There is
only one MACing algorithm defined for this which traffic has highest
priority. In is HMAC-
SHA1-80 [HMAC]. The AuthVal field in this case contains just
the event output of the HMAC-SHA1-80 algorithm which is a resource scarcity (e.g. nearly full
storage) a node could drop all other traffic. (This would
depend fixed width
field (10 octets).

<<Need to check if this is still the best HMAC variant to pick
- and whether to truncate and so allow the extra bits for effectiveness upon some lower layer authentication
and/or integrity mechanisms.)
>>

12.3 Authentication header

An key
mgt. later on.>>

2. Signature Ciphersuite

The Signature ciphersuite involves generating a digital
signature of the LTP Authentication Header (LTP-AH) MAY be used segment and appending the resulting
AuthVal field to provide
cryptographic authentication the end of the segment.

Implementations MAY support this header. If they do not support
this header then they MUST ignore it. <<Check that ignoring There is ok only one
signature algorithm defined for all cases this which is RSA with SHA1
[RSA]. Since the length of an RSA signature depends on the
signing key and is often longer than the maximum value
supported by the SDNV data-type, we also include a two octet
length field which contains the length of response generation.>>

The LTP-AH uses the LTP expansion digital signature
in bits. So the AuthVal field <<Exactly how in this case is TBD>> and
contains as follows (where
the following fields <<Only abstract definitions for
now.>>

- Ciphersuite: an eight bit integer signature value <<probably want two
initially -- an AES-MAC and RSA-SIG>>
- KeyID: An SDNV <<with some mapping to relevant ID formats, occupies the minimum number of octets, e.g. OCTET STRING for AES-MAC, IssuerAndSerial
128 octets for RSA-SIG>>
- AuthVal: An SDNV-16 a 1024 bit signature).

Clearly, the authentication
value <<Either a MAC KeyID field in this case MUST be sufficient to
securely identify the public key usable to verify the
signature.

3. NULL Ciphersuite

<<It is probably debatable whether it is better to include this
or signature -- check not. A purist crypto position would probably be "just allow
a CRC if SDNV-16 allows
long enough signatures for futureproofing>>

<<Have that's what you want", a more code-centric position
might be "I have working HMAC code, why not use that?". So this
ciphersuite may well change or disappear as the document
progresses.>>

The NULL ciphersuite is basically the same as the OriginAuth
ciphersuite, but with a hardcoded key. This ciphersuite
effectively provides only data integrity without
authentication, and thus is subject to say something about key management!!!>>

12.4 Implementation Considerations

SDNV

Implementations SHOULD make sanity checks on SDNV length fields active attacks and is

Burleigh et al. Expires - November 2004 January 2005 [Page 53] 63]
Internet Draft Licklider Transmission Protocol May July 2004

the equivalent of providing a CRC.

The hardcoded key to be used with this ciphersuite is the
following:

HMAC_KEY : c37b7e64 92584340
: bed12207 80894115
: 5068f738
<<The above is the test vector from RFC 3537, but who cares
anyway?>>

In each case the bytes which are input to the cryptographic
algorithm consist of the entire LTP segment except the AuthVal. In
particular the header extensions field which may contain the
ciphersuite number and the KeyID field are part of the input.

The output bytes of the cryptographic operation are the payload of
the AuthVal field.

13.4 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, e.g. <<TBD>>

Byte ranges

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

Randomness

Various fields these are consistent
and sane.

Randomness

Various fields in LTP (e.g. serial numbers) should be
initialized using random values. Good sources of randomness
which are not easily guessable SHOULD be used [ECS94]. 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.

Burleigh et al. Expires - January 2005 [Page 64]
Internet Draft Licklider Transmission Protocol July 2004

13.5 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 DS the response RS gets
stored as pre-cooked;

(b) when the incoming packet is an RS the RA is stored as
precooked, and,

4. Occasionally clean out the replay cache - how frequently this
happens in 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 (e.g. serial numbers) should be
initialised using random values. Good sources of randomness
which are
decode operation. Its not easily guessable SHOULD be used [ECS94].

<<More TBD>>

12.5 Miscellaneous

An clear that it is possible to do much
better though, since all an attacker could modify a message or insert a new message with would have to do to get past
the aim of making replay cache would be to tweak a session which should use reliable transport
into one single bit in the inbound
segment each time, which uses unreliable transport and could is certainly cheaper than the
hash+lookup+decode combination, though also switch
from normal to accelerated delivery. certainly more
expensive than simply sending the same octets many times.

The end result could be
that real data arrives out benefit of order. Higher layer processing
SHOULD take doing this into account if is that implementers no longer need to
analyze many bugs/attacks based on replaying packets, which in
combination with the use of LTP or lower layers do not
preclude such authentication should defeat many
attempted DoS attacks.

<<Other stuff that crops up.>>

13.

14. Tracing LTP back to CFDP

Burleigh et al. Expires - January 2005 [Page 65]
Internet Draft Licklider Transmission Protocol July 2004

LTP in effect implements most of the "core procedures" of the
CCSDS File Delivery Protocol (CFDP) specification, minus all
features that are specific to operations on files and filestores
(file systems); in the IPN architecture we expect that file and
filestore operations will be conducted by file transfer
application protocols -- notably CFDP itself -- operating on top
of the DTN Bundling protocol. (Bundling in effect implements the
CFDP "extended procedures" in a more robust and scalable manner
than is prescribed by the CFDP standard.) The fundamental
difference is that, while CFDP delivers named files end-to-end,
LTP is used to transmit arbitrary, unnamed blocks of data point-
to-point.

Some differences between LTP and CFDP are simply matters of

Burleigh et al. Expires - November 2004 [Page 54]

Internet Draft Licklider Transmission Protocol May 2004
terminology; the following table summarizes the correspondences in
language between the two.

--------------LTP------------- ------------CFDP------------- ------------CFDP-----------

LTP engine CFDP entity

Segment Protocol Data Unit (PDU)

Reception Report NAK

Client service request Service request

Client service notice Service indication

CFDP specifies four mechanisms for initiating data retransmission,
called "lost segment detection modes". LTP effectively supports
all four:

"Deferred" mode is implemented in LTP by the Request flag in
the EOB data segment, which triggers reception reporting upon
receipt of the EOB.

"Prompted" mode is implemented in LTP by turning on Request
flags in data segments that precede the EOB; these additional
checkpoints trigger interim reception reporting under the
control of the source LTP engine.

"Asynchronous" mode is implemented in LTP by the autonomous
production, under locally specified conditions, of additional
reception reports prior to arrival of the EOB.

"Immediate" mode is simply a special case of asynchronous mode,
where the condition that triggers autonomous reception

Burleigh et al. Expires - January 2005 [Page 66]
Internet Draft Licklider Transmission Protocol July 2004

reporting is detection of a gap in the incoming data.

CFDP uses a cyclic timer to iterate reception reporting until
reception is complete. Because choosing a suitable interval for
such a timer is potentially quite difficult, LTP instead flags the
last data segment of each retransmission as a checkpoint, sent
reliably; the cascading reliable transmission of checkpoint and RS
segments assures the continuous progress of the transmission
session.

CFDP's Suspend and Resume PDUs are functionally displaced in LTP
by deferred transmission and automated bandwidth management.

As the following table indicates, most of the functions of CFDP

Burleigh et al. Expires - November 2004 [Page 55]

Internet Draft Licklider Transmission Protocol May 2004
PDUs are accomplished in some way by LTP segments.

--------------LTP------------- -------------CFDP------------ -------------CFDP----------

Data segments File data and metadata PDUs

Closure flag on data segment EOF (Complete)

Request flag on data segment EOF (Complete), Prompt (NAK),
Prompt (Keep Alive)

Report segment ACK (EOF Complete), NAK,
Keep Alive, Finished (Complete)

Report acknowledgment

Report-acknowledgment ACK (Finished Complete)

Cancel segment EOF (Cancel, Protocol Error)
Finished (Cancel, Protocol Error)

Cancellation Acknowledgment ACK (EOF (Cancel, Protocol Error),
Finished (Cancel, Protocol Error))

But some CFDP PDUs have no LTP equivalent because in an IPN
architecture they will likely be implemented elsewhere. CFDP's
EOF (Filestore error) and Finished (Filestore error) PDUs would be
implemented in an IPN application-layer file transfer protocol,
e.g., CFDP itself. CFDP's Finished [End System] PDU is a feature
of the Extended Procedures, which would in effect be implemented
by the Bundling protocol.

14.

15. IANA Considerations

At present there are none known. However if someone wanted to run
LTP over IP (or even TCP or UDP), then we would want to allocate a

Burleigh et al. Expires - January 2005 [Page 67]
Internet Draft Licklider Transmission Protocol July 2004

port number. <<Considering this is TBD>>

15.

16. 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

Burleigh et al. Expires - November 2004 [Page 56]

Internet Draft Licklider Transmission Protocol May 2004
H870; and NASA Contract NAS7-1407. 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. NASA Contract NAS7-1407.

Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel
Myers at Ohio University for their suggestions and advice in
making various design decisions.

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.

16.

17. References

[IPN] InterPlanetary

17.1 Normative References

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

[HMAC] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.

[RSA] Kaliski, B, Staddon J, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.

17.2 Informative References

[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.

[ASN1] Abstract Syntax Notation One (ASN.1). Specification of
Basic Notation. ITU-T Rec. X.680 (2002) | ISO/IEC 8824-1:2002.

[BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification",

Burleigh et al. Expires - January 2005 [Page 68]
Internet Special Interest Group web page,
"http://www.ipnsig.org". Draft Licklider Transmission Protocol July 2004

Work in Progress, October 2003.

[CCSDS] Consultative Committee for Space Data Systems web page,
"http://www.ccsds.org".

[CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for
Space Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1,
October 2002.

[BP] K. Scott,

[DDJ] I. Goldberg and S. Burleigh, "Bundle Protocol Specification",
Work in Progress, October E. Wagner, "Randomness and the Netscape
Browser", Dr. Dobb's Journal, 1996, (pages 66-70).

[DSN] Deep Space Mission Systems Telecommunications Link Design
Handbook (810-005) web-page,
"http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/"

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

[DTNRG] Delay Tolerant Networking Research

[IPN] InterPlanetary Internet Special Interest Group web page,
"http://www.dtnrg.org".

[MSM97]
"http://www.ipnsig.org".

[TFRC] M. Mathis, Handley, S. Floyd, J. Semke, Padhye, and J. Mahdavi, "The Macroscopic
Behavior of the TCP Congestion Avoidance Algorithm", Computer
Communications Review Vol.27(3), 1997.

[P97] V. Paxson, "Measurements and Analysis of End-to-End Internet
Dynamics", Ph.D. Thesis., Computer Science Divisions, University
of California, Berkeley, 1997. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", RFC 3448,
January 2003.

[PKIXPROF] Housley, R. et al, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.

[TM] Packet Telemetry Specification. Recommendation for Space Data
System Standards, CCSDS 103.0-B-2 BLUE BOOK Issue 2, June 2001.

[TC] Telecommand Part 2 - Data Routing Service. Recommendation for
Space Data System Standards, CCSDS 202.0-B-3 BLUE BOOK Issue 3,
June 2001.

[ASN1] Abstract Syntax Notation One (ASN.1). Specification of
Basic Notation. ITU-T Rec. X.680 (2002) | ISO/IEC 8824-1:2002.

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

[ECS94] D. Eastlake, S. Crocker, and J. Schiller, "Randomness

Burleigh et al. Expires - November 2004 [Page 57]

Internet Draft Licklider Transmission Protocol May 2004
Recommendations for Security", RFC 1750, December 1994.

17.

18. Author's Addresses

Scott C. Burleigh
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 179-206
Pasadena, CA 91109-8099

Burleigh et al. Expires - January 2005 [Page 69]
Internet Draft Licklider Transmission Protocol July 2004

Telephone +1 (818) 393-3353
FAX +1 (818) 354-1075
Email Scott.Burleigh@jpl.nasa.gov

Manikantan Ramadas
Internetworking Research Group
301 Stocker Center
Ohio University
Athens, OH 45701
Telephone +1 (740) 593-1562
Email mramadas@irg.cs.ohiou.edu

Stephen Farrell
Distributed Systems Group
Computer Science Department
Trinity College Dublin
Ireland
Telephone +353-1-608-3070
Email stephen.farrell@cs.tcd.ie

19. Copyright Statement

Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, 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 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.

Burleigh et al. Expires - November 2004 January 2005 [Page 58] 70]
----