WDIFF

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

Delay Tolerant Networking Research Group S. Burleigh M. Ramadas
Internet Draft Ohio University
<draft-irtf-dtnrg-ltp-02.txt> S. Burleigh
December 2004 NASA/Jet Propulsion Laboratory
<draft-irtf-dtnrg-ltp-01.txt> M. Ramadas
July 2004 Ohio University
Expires January June 2005 S. Farrell
Trinity College Dublin

Licklider Transmission Protocol - Specification

Status of this Memo

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 any of which we become aware will be
disclosed, in accordance with 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 a "work in progress."

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

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

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

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 in
challenged internet environments exhibiting
characterized by extremely long message round-trip times (RTTs), (RTTs)

Ramadas et al. Expires - June 2005 [Page 1]
Internet Draft LTP - Specification December 2004

and/or frequent interruptions in connectivity, and
high bit error rates. connectivity. Since communication
across interplanetary space is the most prominent example of this
sort of environment, LTP is principally aimed at supporting "long-haul" "long-
haul" reliable transmission

Burleigh et al. Expires - January 2005 [Page 1]
Internet Draft Licklider Transmission Protocol July 2004 in interplanetary space, but might have has
applications in other 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, reports. It is stateful, and has
no negotiation or handshakes, and supports out-of-transmission-order
data delivery. handshakes.

Table of Contents

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

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

7.2.1 13
3.2.1 Data Segment ........................................ 34
7.2.2 13
3.2.2 Report Segment ...................................... 35
7.2.3 14
3.2.3 Report Acknowledgment Segment ....................... 37
7.2.4 16
3.2.4 Session Management Segments ......................... 37
8. 16
3.3 Segment Trailer .......................................... 17
4. Requests from Client Service ................................. 38
8.1 17
4.1 Transmission Request ..................................... 38
8.2 17
4.2 Cancellation Request ..................................... 39
9. 18
5. Internal Procedures .......................................... 40
9.1 19
5.1 Start Transmission ....................................... 41
9.2 19
5.2 Start Checkpoint Timer ................................... 41
9.3 19
5.3 Start RS Timer ........................................... 41
9.4 20
5.4 Stop Transmission ........................................ 41
9.5 20
5.5 Suspend Timers ........................................... 41
9.6 20
5.6 Resume Timers ............................................ 42
9.7 21
5.7 Retransmit Checkpoint .................................... 43
9.8 21
5.8 Retransmit RS ............................................ 43
9.9 22
5.9 Signify Red-Part Reception ............................... 22
5.10 Signify Green-Part Segment Arrival .................................. 44
9.10 Signify Block Reception ................................. 44
9.11 ...................... 22
5.11 Send Reception Report ................................... 44
9.12 23
5.12 Signify Transmission Completion ......................... 45
9.13 24
5.13 Retransmit Data ......................................... 45
9.14 25
5.14 Stop RS Timer ........................................... 46
9.15 26
5.15 Start Cancel Timer ...................................... 46
9.16 26

Ramadas et al. Expires - June 2005 [Page 2]
Internet Draft LTP - Specification December 2004

5.16 Retransmit Cancellation Segment ......................... 47
9.17 26
5.17 Acknowledge Cancellation ................................ 47
9.18 26
5.18 Stop Cancellation Cancel Timer ................................. 48
9.19 ....................................... 27
5.19 Cancel Session .......................................... 48
9.20 27
5.20 Close Session ........................................... 48
10. 27
5.21 Handle Miscolored Segment ............................... 27
6. Notices to Client Service ................................... 48
10.1 .................................... 28
6.1 Session Start ............................................ 48
10.2 Data ............................................. 28
6.2 Green-Part Segment Arrival ..................................... 49
10.3 Block ................................ 28
6.3 Red-Part Reception .......................................... 49
10.4 ........................................ 29
6.4 Transmission Completion .................................. 49
10.5 ................................... 29
6.5 Transmission Cancellation ................................ 50
10.6 ................................. 29
6.6 Reception Cancellation ................................... 50
11. .................................... 30
7. State Transition Diagrams .................................... 50
11.1 ..................................... 30
7.1 Sender ................................................... 52
11.2 .................................................... 32
7.2 Receiver ................................................. 55
12. .................................................. 37
8. Requirements from the Operating Environment .................. 58
13. ................... 41
9. Security Considerations ...................................... 58
13.1 ....................................... 42
9.1 Security Mechanisms and Layering Considerations ................... 59
13.2 ........... 43
9.2 Denial of Service Considerations ......................... 60
13.3 LTP Authentication ....................................... 61
13.4 Implementation Considerations ............................ 64
13.5 .......................... 44
9.3 Replay Handling .......................................... 65
14. Tracing LTP back to CFDP ..................................... 65
15. ........................................... 45
9.4 Implementation Considerations ............................. 46
10. IANA Considerations .......................................... 67
16. 46
11. Acknowledgments .............................................. 68

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

17. 47
12. References ................................................... 68
17.1 Informative References ................................... 68
17.2 47
12.1 Normative References ..................................... 68
18. 47
12.2 Informative References ................................... 47
13. Author's Addresses ........................................... 69
19. 48
14. Copyright Statement .......................................... 70 48

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, frequent
interruptions in connectivity,

This document serves as the main protocol specification of LTP, and high bit error rates.
Communication in interplanetary space
is the most prominent example part of this sort a series of environment, documents describing LTP. Other documents in
this series include the motivation document [LTPMOTIVE] and LTP is principally aimed at
supporting "long-haul" reliable transmission over deep-space RF
links.

Since 1982 the principal source of standards for space communications
has been
protocol extensions document [LTPEXT] respectively. We strongly
recommend reading the protocol motivation document before reading the Consultative Committee
following document to establish sufficient background and motivation
for Space Data Systems (CCSDS)
[CCSDS]. Engineers of CCSDS member agencies have developed
communication protocols that function within the constraints imposed
by operations contents that follow in deep space. These constraints differ sharply from
those this document.

2. Terminology

(1) Engine ID

A number that uniquely identifies a given LTP engine, 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 some
closed set 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 communicating LTP engines. Note that when LTP 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 underneath the DTN Bundling protocol [BP]
defined for Delay-Tolerant 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 [BP][DTN], the
convergence layer adapter mediating between the two will be

Ramadas et al. Expires - January June 2005 [Page 4] 3]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

Its design notions are directly descended from the retransmission
procedures defined

responsible for CFDP.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", translating between DTN endpoint IDs and "OPTIONAL" LTP engine
IDs in this
document are an implementation-specific manner.

(2) Block

An array of contiguous octets of application data handed down by the
upper layer protocol (typically Bundling) to be interpreted as described in [B97].

2. Motivation

2.1 IPN Operating Environment

There are transmitted via LTP
from one client service instance to another.

Any subset of a number block comprising contiguous octets that begins at the
start of fundamental differences between the environment
for terrestrial communications and block is termed a "block prefix" and any such subset of
the operating environments
envisioned for block that ends with the end of the IPN. block is termed a "block
suffix".

(3) Red-Part

The most challenging difference between communication among points on
Earth and communication among planets block prefix that is round-trip delay, of which
there are two main sources, both relatively intractable: natural law to be transmitted reliably, i.e., subject to
acknowledgement and economics. retransmission.

(4) Green-Part

The more obvious type of delay imposed by nature block suffix that is signal
propagation time. Our inability to transmit data at speeds higher
than be transmitted unreliably, i.e., not
subject to acknowledgments or retransmissions. If present, the speed green-
part of light means 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 block begins at 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 octet following the delay imposed by occultation.
Communication between planets must be by radiant transmission, which
is usually possible only when end of the communicating entities are in line red-
part.

(5) Session

A thread of sight LTP protocol activity conducted for the purpose of each other. An entity residing on
transmitting a planetary surface
will be periodically taken out block.

(6) Segment

The unit of sight by the planet's rotation (it
will be "on LTP data transmission activity. It is the other side of" data structure
transmitted from one LTP engine to another in the planet); an entity that orbits course of a
planet will be periodically taken out
session. An LTP segment is either a data segment, a report segment,
a report-acknowledgment segment, a cancel segment, or a cancel-
acknowledgment segment.

(7) Reception Claim

An assertion of reception of some number of contiguous octets of
application data (a subset of sight a block) characterized by orbital motion (it
will be "behind" the planet); and planets themselves lose mutual
visibility when their trajectories take them to opposite sides offset of
the
Sun. During the time that communication is impossible, delivery is
impaired first received octet and messages must wait in a queue for later transmission.

Round-trip times and occultations can at least be readily computed
given the ephemerides number 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 contiguous octets
received.

(8) Scope

Ramadas et al. Expires - January June 2005 [Page 5] 4]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

provided by NASA's Deep Space Network (DSN) [DSN]. The communication
resources

Scope identifies a subset of the DSN are currently oversubscribed a block and will probably
remain so for the foreseeable future. While studies have been done
as to comprises two numbers -
upper bound and lower bound.

For a data segment, lower bound is the feasibility offset of upgrading or replacing the current DSN, segment's
application data from the
number start of deep space missions will probably continue to grow faster
than the terrestrial infrastructure that supports them, making over-
subscription a persistent problem. Radio contact via the DSN must
therefore be carefully scheduled and block (in octets), while upper
bound 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 sum of the scheduling offset and queuing delays imposed by
management length of Earth-based resources: packets to be sent to the segment's
application data (in octets). For example, a given
destination may segment with block
offset 1000 and length 500 would have to be queued until a lower bound 1000 and upper
bound 1500.

For a report segment, upper bound is the next scheduled contact
period, end of the block prefix to
which may be hours, days, or even weeks away. While queuing
and scheduling delays are generally known well the reception claims in advance except when
missions need emergency service (such as during landings and
maneuvers), the long and highly variable delays make report apply, while lower bound is
the design end of
timers, and retransmission timers the (smaller) interior block prefix to which the reception
claims in particular, quite difficult.

Another significant difference between deep space 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 and terrestrial
communication is bandwidth availability. The combined effects not designated as "received" by any of
large distances (resulting in signal attenuation), the expense report's
reception claims must be assumed not received and therefore eligible
for retransmission. For example, if a report segment carried a lower
bound of 1000 and
difficulty an upper bound of deploying large antennas to distant planets, 5000, and the
difficulty reception claims
indicated reception of generating electric power in space all mean that data within offsets 1000-1999 and 3000-4999,
data within the
available bandwidth block offsets 2000-2999 can be considered eligible
for communication retransmission.

Reception reports (which may comprise multiple report segments) also
have scope, as defined in the IPN will likely remain
modest compared to terrestrial systems. Maximum Section 5.11.

(9) End of Block (EOB)

The last data rates on segment transmitted as part of the
order original
transmission of a few tens of megabits per second will probably be block. This data segment also indicates that the norm
for
segment's upper bound is the next few decades.

Moreover, total length of the available bandwidths are highly asymmetrical: data are
typically block (in octets).

(10) End of Red-Part (EORP)

That segment transmitted at different rates in different directions on as part of the same link. Current missions are usually designed with original transmission of a much
higher data "return" rate (from spacecraft to Earth) than "command"
rate (from Earth to spacecraft). The reason for
block which contains 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. last octet of the block's red-part. This design choice has led to
data rate
asymmetries in excess segment also indicates that the segment's upper bound is the
length of 100:1, sometimes approaching 1000:1. the block's red-part (in octets).

(11) Checkpoint

A
strong desire for data segment soliciting a very robust command channel will probably remain,
so any transport protocol designed for use in reception report from the IPN will need to
function with a relatively low-bandwidth outbound channel to
spacecraft and landers. receiving LTP
engine. 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 EORP segment must be flagged as a checkpoint, as must
the order last segment of 10^(-1), or one error in ten bits; heavy

Burleigh any retransmission; these are "mandatory
checkpoints". All other checkpoints are "discretionary checkpoints".

(12) Reception Report

Ramadas et al. Expires - January June 2005 [Page 6] 5]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

coding is used to reduce these rates, and

A sequence of course this coding
further reduces the residual bandwidth available for one or more report segments reporting on all block data
transmission.

Signal propagation delay
reception within some scope.

(13) Synchronous Reception Report

A reception report that is the only truly immutable characteristic issued in response to a checkpoint.

(14) Asynchronous Reception Report

A reception report that distinguishes is issued in response to some implementation-
defined event other than the IPN from terrestrial communications (unless
and until we find arrival of a way checkpoint.

(15) Primary Reception Report

A reception report that is issued in response to transmit information faster some event other
than the speed arrival of light). Queuing and scheduling delays, low data rates,
intermittent connectivity, a checkpoint segment that was itself issued in
response to a reception report. Primary reception reports include
all asynchronous reception reports and high bit error rates can all be
mitigated synchronous reception
reports that are sent in response to discretionary checkpoints 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 EORP segment for a "fringe" session.

(16) Secondary Reception Report

A reception report that is issued in response to the fabric arrival 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 rates
- make using unmodified TCP for end to end communications
checkpoint segment that was itself issued in the IPN
infeasible. Using the TCP throughput equation from [TFRC] we can
calculate the loss event rate (p) required response to achieve a given steady-
state throughput. Assuming the closest RTT reception
report.

(17) Self-Delimiting Numeric Value (SDNV)

The design of LTP attempts to Mars from planet Earth reconcile minimal consumption of 8 minutes,
transmission bandwidth with

(a) extensibility to satisfy requirements not yet identified and
(b) scalability across a packet size very wide range of 1500 bytes, assuming the receiver to
acknowledge every other packet, network sizes and ignoring negligible higher order
terms
transmission payload sizes.

A key strategic element in p (i.e., ignoring the second additive term in design is the
denominator use of self-delimiting
numeric values (SDNVs) that are similar in design to the throughput equation from [TFRC]), we obtain the
following table Abstract
Syntax Notation One [ASN1] encoding of loss event rates required data structures. SDNVs are of
two basic types, SDNV-8 and SDNV-16. An SDNV-8 can be used to achieve various
throughput values.

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

Note that multiple losses encountered in encode
a single RTT are counted variable length number from 1 to 128 octets in length; an SDNV-16
can be part of used to encode a single loss event in the TCP throughput equation.
However, such loss event rates are still too high variable length number from 2 to realize in deep
space links where typical raw bit error rates are 128 octets
in length. The first octet of an SDNV - the order "discriminant" - fully
characterizes the SDNV's value.

SDNV-8

If the most significant bit of
10^(-1).

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

Burleigh the discriminant is zero, the

Ramadas et al. Expires - January June 2005 [Page 7] 6]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

the number

length 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 SDNV-8 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 1 octet and reset the connection after 5 minutes contents of inactivity,
a conformant standard FTP server could be unusable for communicating
even with the closest planets.

3. Features

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 remaining
7 bits 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 discriminant viewed as an unsigned integer is the communication resources available on
value of the link between them.

Certainly SDNV. An integer in many cases the computational resources available range of 0 to a
given LTP engine - such as one on board a small robotic spacecraft
will not 127 can be ample by
encoded this way.

Otherwise (if the standards most significant bit of the Internet. But in those
cases we expect that discriminant is 1),
the associated communication resources
(transmitter power, antenna size) will be even less ample, preserving remaining 7 bits encode the expected disproportion between length of the two.

Second, we note that establishing a communication link across
interplanetary distance entails enacting several hardware
configuration measures based on SDNV's value. If the presumed operational state
content 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 remaining 7 bits viewed as an unsigned integer has
the transponder at value N, the

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

last possible moment, encoded number is N+1 octets long and for has the minimum necessary length
value found by concatenating octets 2 through N+2 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 SDNV-8,
viewed as an unsigned integer. For example, if N were 0, 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 Massive State Retention

Like any reliable transport service employing ARQ, LTP is "stateful".
In order to assure
following single octet would contain 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 value 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.

Long round-trip times mean substantial delay between SDNV-8; if N
were 127, the transmission following 128 octets would contain the encoded
unsigned number.

SDNV-16

If the most significant bit of a block the discriminant is zero, then the
length of data the SDNV-16 is 2 octets and the reception contents of an acknowledgment from the
block's destination, signaling arrival
remaining 7 bits of the block. If LTP
postponed transmission of additional blocks of data until it received
acknowledgment of discriminant concatenated with the arrival
following octet, viewed as a 15-bit unsigned integer, is the value
encoded. An integer in the range of all prior blocks, valuable
opportunities 0 to utilize what little deep space transmission
bandwidth is available would 32767 can be forever lost.

For encoded this reason, LTP is based in part on a notion
way.

Otherwise (if the most significant bit of massive state
retention. Any number the discriminant is 1),
the encoding is similar to SDNV-8. If the content of requested transmissions may be concurrently
"in flight" at various displacements along the link between two LTP
engines, and remaining
7 bits viewed as an unsigned integer has the LTP engines must necessarily retain transmission
status value N, the encoded
number is N+1 octets long and retransmission resources for all of them. Moreover, if
any of has the data value found by concatenating
octets 2 through N+2 of a given block are lost en route, it will the SDNV-16, viewed as an unsigned
integer.

An SDNV can therefore be
necessary used to retain represent both very large and very
small integer values. For example, the state maximum size of that transmission during an
additional round trip SDNV - a
1024-bit number - is large enough to contain a fairly safe encryption
key, while any whole-degree Celsius temperature in the lost data are retransmitted; even
multiple retransmission cycles may be necessary.

In sum, LTP transmission state information persists for a long time
because range in which
water is a long time must pass before LTP liquid can be assured of
transmission success - so LTP must retain represented in a great deal of state
information.

Since single-octet SDNV-8.

In the LTP header specification that follows, various fields in the alternatives
header are non-reliability defined to be of types SDNV-8 or SDNV-16 depending on the one hand and severe
under-utilization
typical range of transmission opportunities on values expected for 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 field. If a field in all applications).

3.1.1 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 the
header carries a
variety of higher-layer services or applications: LTP's "client
service IDs" correspond number that typically requires 16 bits to TCP's port numbers. Also, both TCP encode,
but under certain infrequent conditions may grow longer and
LTP implement devices for encapsulating threads of retransmission
protocol (protocol state machines): LTP's "sessions" functionally
correspond require,
say, 32 bits 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 encode, it might be optimal to another.

However, a single TCP association (local host address, local port
number, foreign host address, foreign port number) can accommodate at
most one connection at any one time. In contrast, a single LTP
association (local engine ID, local client service ID, foreign engine
ID, foreign client service ID) can accommodate multiple concurrent
sessions.

3.1.2 Session IDs

In TCP, specify it as an
SDNV-16 instead of specifying the fact that any single association field as a fixed 32 bit integer.

However, SDNV is occupied by at most
one connection at any time enables clearly not the protocol to use host addresses
and port numbers to demultiplex arriving data best way to represent every numeric
value. When the appropriate
protocol state machines. LTP's maximum possible multiplicity value of sessions per
association makes it necessary for each segment a number is known without
question, the cost of application data
to include an additional demultiplexing token, 8 bits of discriminant may not be

Ramadas et al. Expires - June 2005 [Page 7]
Internet Draft LTP - Specification December 2004

justified. For example, an SDNV-8 is a "session ID" that
uniquely identifies the session poor way to represent an
integer whose value typically falls in which the segment was issued.

3.1.3 Use of Non-volatile Storage

Another important implication of massive statefulness is range 128 to 255.

In general, though, we believe that
implementations SDNV representation of LTP should consider retaining transmission state
information selected
numeric values in non-volatile storage of some kind, LTP segments yields the smallest segment sizes
without sacrificing scalability.

(18) Client Service Instance

A software entity, such as magnetic
disk an application or flash memory. Transport protocols such as TCP typically
retain transmission state a higher-layer protocol
implementation, that is using LTP to transfer data.

3. Segment Structure

Each LTP segment comprises

(a) a "header" in dynamic RAM; if the computer on which
the software resides is rebooted format defined below.

(b) zero or powered down, then all
transmissions currently more octets of "content".

(c) zero or more octets of "trailer" as indicated by information in progress are aborted but
the resulting
degree "extensions field" of communication disruption is limited, because the number header.

LTP segments are of
concurrent connections is limited. Rebooting or power-cycling a
computer 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.

A report segment carries data reception claims together with the
upper and lower bounds of the data block scope to which an LTP engine resides could abort a much larger the claims
pertain.

A report-acknowledgment segment carries only the serial number of transmission sessions in various stages
the report being acknowledged.

Session management segments are of completion, at two general subtypes:
Cancellation and Cancellation-acknowledgment. A Cancellation
segment carries a
much larger total cost.

Burleigh single byte reason-code to indicate the reason
for the cancellation. Cancellation-acknowledgment segments have no
content.

The overall segment structure is illustrated below :

Ramadas et al. Expires - January June 2005 [Page 10] 8]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

3.2 Absence of Negotiation

In the IPN, round-trip times may be so long and communication
opportunities so brief that a negotiation exchange, such as an
adjustment of transmission rate, might not be completed before
connectivity 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

Bit 0 1 2 3 4 5 6 7
^ +-----+-----+-----+-----+-----+-----+-----+-----+
| | Version number | Segment Type Flags |
| +-----------------------+-----------------------+
| | |
| / Session ID \
| \ /
Header +-----------------------+-----------------------+
| | Header Extension Cnt. | Trailer Extension Cnt.|
| +-----------------------+-----------------------+
| | |
| / Header Extensions \
| \ /
V +-----------------------------------------------+
| |
| |
| |
| Segment Content |
/ \
\ /
| |
| |
| |
^ +-----------------------------------------------+
| | |
Trailer / Trailer Extensions \
| \ /
V +-----------------------------------------------+

3.1 Segment Header

An LTP communication segment header comprises three data items: a single-octet
control byte, a session parameters are
asserted unilaterally, subject ID, and an extensions field.

Control byte comprises the following:

Version number (4 bits): MUST be set to application-level network
management activity that may not take effect the binary value 0000 for hours, days, or
weeks.

3.3 Laconic Acknowledgment

Another respect in which LTP differs from TCP is that, while TCP
connections are bidirectional (blocks
this version of application data may be
flowing in both directions on any single connection), LTP sessions
are unidirectional. This design decision derives from the fact that protocol.

Segment type flags (4 bits): described below.

Session ID uniquely identifies, among all transmissions between the flow of data in deep space flight missions is usually
unidirectional. (Long round trip times make interactive spacecraft
operation infeasible, so spacecrafts are largely autonomous
segment's sender 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 receiver, the new
block's destination; transmission session of which 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 is
one contains a comprehensive report of all data
received within some specified range of offsets from token. It comprises the start following:

Session originator: the engine ID of the
transmitted block. The expectation is LTP engine that most data segments will
arrive safely, so individual acknowledgment of each one would be
expensive in information-theoretical terms: initiated
the real information

Burleigh session, in SDNV-8 representation.

Ramadas et al. Expires - January June 2005 [Page 11] 9]
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" LTP - Specification December 2004

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

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

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

o "Retransmissions" matters that are sequences of data segments issued in
response
private to the arrival of report segments that indicate
incomplete reception.

Checkpoints are mandatory only at session-originating engine; the end of each such sequence. For
applications only requirement
imposed by LTP is 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 every session initiated by an original transmission, and additional
reception reports may optionally LTP engine
MUST be sent on an asynchronous 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 uniquely identified by entirely different
routes to reach the same destination. session ID.

The underlying IP network-
layer protocol accomplishes this routing. Although TCP always
delivers data segments to any single port extensions field is described in order and without gaps, Section 3.1.4.

3.1.1 Segment Type Flags

The last four bits of the IP datagrams delivered to TCP itself may not arrive control byte in the order
in which they were transmitted.

In contrast, LTP is a protocol for "point to 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 segment header are
flags that indicate the nature of deep space communication, which is simply the
exchange segment. In order (most
significant bit first), these flags are CTRL, EXC, Flag 1 and Flag 0.

A value of radiation between two mutually visible antennae. No
underlying network infrastructure is presumed, so no underlying
network-layer protocol activity is expected; 0 in the underlying
communication service is assumed to be a point-to-point link-layer
protocol such CTRL (Control) flag identifies the segment as CCSDS Telemetry/Telecommand [TM][TC] (or, for
terrestrial applications, PPP). The contents a
data segment while a value of link-layer frames
delivered 1 identifies it as a control segment. A
data segment with the EXC (Exception) flag set to LTP are always expected 0 is a red-part
segment; a data segment with EXC set to arrive in 1 is a green-part segment.
For a control segment, having the order in which
they were transmitted, though possibly with any number of gaps due EXC flag set to
data loss or corruption.

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

Note 1 indicates that building an interplanetary network infrastructure - the
DTN-based architecture of
the IPN - *on top of* LTP does not conflict segment pertains to session cancellation activity. Any data
segment (whether red-part or green-part) with LTP design principles. The Bundling protocol functions at a new
hyper-network level, both Flag 1 and LTP bears essentially the same relationship Flag 0
set to Bundling that a reliable link protocol (for example, the ARQ
capabilities 1 indicates end of LLC) would bear block. Any data segment (whether red-part
or green-part) with both Flag 1 and Flag 0 set 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 0 indicates data
without any additional protocol significance. Any red-part data
segment with either Flag bit non-zero is a checkpoint. Any red-part
data segment with Flag 1 set to reach the same destination, then 1 indicates the assumption end of rough determinism in timeout interval computation discussed below
would not hold. Our inability to estimate timeout intervals with any
accuracy would severely compromise performance.

If data arrived at an LTP engine out the red-part
of transmission order, then the
assumptions on which block.

3.1.2 Segment Type Codes

Combinations of 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:

Since multiple sessions can be conducted on any single
association, retardation settings of transmission on any single session
while awaiting a timeout need not degrade communication
performance on the association segment type flags CTRL, EXC,
Flag 1 and Flag 0 constitute segment type codes which serve as a whole. Timeout intervals that
would be intolerably optimistic in TCP don't necessarily degrade
LTP's bandwidth utilization.

But the reciprocal half-duplex nature
concise representations of LTP communication makes
it infeasible to use statistical analysis detailed segment nature.

CTRL EXC Flag 1 Flag 0 Code Nature of round-trip history as
a means of predicting round-trip time. The round-trip time for
transmitted segment N could easily be orders of magnitude greater
than that for segment N-1 if there happened to be a transient loss
of connectivity between the segment transmissions.

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
---- --- ------ ------ ---- -----------------------------------------
0 0 0 0 0 Red data, NOT {Checkpoint or EORP or EOB}
0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB}
0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB
0 0 1 1 3 Red data, Checkpoint, EORP, EOB

0 1 0 0 4 Green data, NOT EOB
0 1 0 1 5 Undefined
0 1 1 0 6 Undefined
0 1 1 1 7 Green data, EOB

Ramadas et al. Expires - January June 2005 [Page 13] 10]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

This computation is performed in two stages.

We calculate a first approximation of RTT by simply doubling the
known one-way light time

1 0 0 0 8 Report segment
1 0 0 1 9 Report-acknowledgment segment
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 segment
to the destination and adding an arbitrary
margin for any additional anticipated latency, such as queuing and
processing delay at both ends of the transmission. block sender

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

3.1.3 Segment Class Masks

For deep space
operations, the margin value is typically a small number purposes 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, this specification, some bit patterns in preference to premature retransmission,
which will unnecessarily consume precious bandwidth and thereby
degrade overall performance.

Then, to account for the additional delay imposed
segment type flags field correspond to "segment classes" that are
designated by interrupted
connectivity, we dynamically suspend timers during periods when the
relevant remote LTP engines mnemonics. The mnemonics are known to be unable to transmit
responses. This knowledge of the operational state of remote
entities is assumed intended to be provided by link state cues from evoke 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
characteristics shared 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 all types of two-way connectivity. It is always
possible for LTP to be generating outbound segments characterized by
these flag bit patterns.

CTRL EXC Flag 1 Flag 0 Mnemonic Description
---- --- ------ ------ -------- ---------------------------
0 0 - in response to
received segments, timeouts, 1
-- or requests from client services --
0 0 1 - 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 CP Checkpoint

0 0 1 - EORP End of communicating LTP engines. Note 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 red-part;
red-part size = offset + length

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

1 0 0 0 RS Report segment;
carries reception claims

1 0 0 1 RA Report-acknowledgment segment

1 1 0 0 CS Cancel segment from block sender

1 1 0 1 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

Ramadas et al. Expires - January June 2005 [Page 14] 11]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

(2) Block

An array of contiguous octets of application data handed down by the
upper layer (typically

1 1 - 0 Cx Cancel segment (generic)

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

3.1.4 Extensions field

The extension field enables the bundling layer) inclusion of zero or more functional
extensions to be transmitted via the basic LTP
from one client service instance to another.

(3) Block Prefix

Any subset segment, each in type-length-value (TLV)
representation as explained below.

The first octet of a block that begins at the start of extensions field indicates the block.

(4) Session

A thread number of LTP protocol activity conducted for
extensions present in the purpose of
transmitting a block.

(5) Segment

The unit of LTP data transmission activity. It is segment: the data structure
transmitted from one LTP engine to another high-order 4 bits indicate the
number of extension TLVs in the course header (immediately following the
extensions count octet and preceding the segment's content) while the
low-order 4 bits indicate the number 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) Reception Claim

An assertion of reception of some number of contiguous octets of
application data (a subset of a block) characterized by extension TLVs in the offset of trailer
(immediately following the first received octet segment's content). That is, each segment
may have from 0 to 15 extension TLVs in its header and from 0 to 15
extension TLVs in its trailer. In the number of contiguous octets
received.

(7) Scope

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

For a data segment, lower bound is the offset any extension TLVs,
all bits of the segment's
application data from the start this extensions count octet MUST be set to zero.

Each extension consists of a one-octet tag identifying the block (in octets), while upper
bound is the sum type of the offset and length
extension (the "T" of the segment's
application data (in octets). For example, a segment with block
offset 1000 and length 500 would have extension TLV), followed by an extension
specification in SDNV-8 format. [Since an SDNV-8 comprises both a lower bound 1000
numeric data value and upper
bound 1500.

For a report segment, upper bound is the end length of that value, the block prefix extension
specification serves to
which the reception claims in supply both the report apply, while lower bound is "L" and the end "V" of the (smaller) interior block prefix to which
extension TLV.]

The diagram below illustrates the reception
claims extension TLVs as they may occur in
the report do *not* apply. That is, data at any offset
equal to header or greater than the report's lower bound but less than its
upper bound and not designated as "received" by any of the report's

Burleigh trailer.

One extension type is defined at this time.

Extension tag Meaning
------------- -------
0x00 LTP authentication extension [LTPEXT]
0x01 LTP cookie estension [LTPEXT]
0x02-0xff Reserved

Ramadas et al. Expires - January June 2005 [Page 15] 12]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

reception claims must be assumed not received and therefore eligible
for retransmission. For example, if

3.2 Segment Content

3.2.1 Data Segment (DS)

The content of a report data segment carried a lower
bound of 1000 and an upper bound of 5000, and the reception claims
indicated reception of includes client service data within offsets 1000-1999 and 3000-4999,
data within
metadata enabling 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 Sec 5.2.1.

(8) End receiving client service instance to receive
and make use of Block (EOB) that data.

Client service ID [SDNV-8]

The last data client service ID number identifies the upper-level service to
which the segment transmitted as part 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 original
transmission client service are present
at the destination, multiplexing must be done by the client
service itself on the basis of a information encoded within the
transmitted block. This data segment also

Offset [SDNV-16]

Offset indicates that the location of the segment's upper bound client service data
within the session's transmitted block. It is the total length number of bytes
in the block (in octets).

(9) Checkpoint

A prior to the byte from which the first octet of the
segment's client service data was copied.

Length [SDNV-16]

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

If the data segment soliciting is a reception report from the receiving LTP
engine. All checkpoints other than checkpoint, the EOB segment MUST additionally
include the following two serial numbers (Checkpoint serial number
and Report serial number) to support efficient retransmission. Data
segments that are not checkpoints MUST NOT
themselves issued have these two fields in response to a reception report, are
discretionary checkpoints, sent unreliably. The EOB segment
the header and all
checkpoints issued in response to reception reports are mandatory
checkpoints, sent reliably.

(10) Reception Report

A sequence of one or more report segments reporting MUST continue on all block data
reception (within some scope) since directly with the start of client service
data.

Checkpoint serial number [SDNV-8]

The checkpoint serial number uniquely identifies the block's
transmission session.

(11) Synchronous Reception Report

A reception report that is checkpoint
among all checkpoints issued by the block sender in response to a checkpoint.

(12) Asynchronous Reception Report

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

(13) Primary Reception Report

A reception report that sender MUST have this serial
number chosen randomly for security reasons, and it is issued RECOMMENDED
that the sender use the guidelines in response to some event other
than [ECS94] for this. Any
subsequent checkpoints issued by the arrival of sender MUST have the serial
number value found by incrementing the prior checkpoint serial
number by 1. When 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 is retransmitted, however,
its serial number MUST be the EOB for a session.

Burleigh same as when it was originally

Ramadas et al. Expires - January June 2005 [Page 16] 13]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

(14) Secondary Reception

transmitted.

Report

A reception report that is issued in response to serial number [SDNV-8]

If the arrival of a checkpoint segment that was itself issued queued for transmission in response to a the
reception
report.

(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 an RS [Sec 5.13], then its value MUST be the use report
serial number value of self-delimiting
numeric values (SDNVs) the RS that are similar in design to caused the Abstract
Syntax Notation One [ASN1] encoding. An SDNV can be used data segment to encode a
variable length be
queued for transmission.

Otherwise, the value of report serial number from 1 to 128 bytes long, and is MUST be zero.

Client service data [array of two basic
types, SDNV-8 and SDNV-16. octets]

The first octet of an SDNV - the "discriminant" - fully characterizes
the SDNV's value.

SDNV-8

If the most significant bit of client service data carried in the discriminant segment is zero, the
length a copy of the SDNV-8 is 1 octet and the contents a
subset of the remaining
7 bits of the discriminant viewed as an unsigned integer is the
value encoded. An integer bytes in the range of 0 to 127 can be encoded
this way.

Otherwise (if original client service data block,
starting at the most significant bit indicated offset.

3.2.2 Report Segment (RS)

The content of an RS comprises one or more data reception claims,
together with the discriminant is 1),
the remaining 7 bits encode the length upper and lower bounds of the encoded number. If scope within the content of data
block to which the remaining 7 bits viewed as an unsigned integer
has claims pertain. It also includes two serial
numbers to support efficient retransmission.

Report serial number [SDNV-8]

The report serial number uniquely identifies the value N, report among all
reports issued by the encoded block receiver in a session. The first
report issued by the receiver MUST have this serial number is N+1 octets long chosen
randomly for security reasons, and has it is RECOMMENDED that the
receiver use the guidelines in [ECS94] for this. Any subsequent RS
issued by the receiver MUST have the serial number value found by concatenating octets 2 through N+2 of
incrementing the SDNV-8,
viewed as last report serial number by 1. When an unsigned integer. For example, if N were 0, the
following single octet would have 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 the SDNV-8; checkpoint serial number MUST be zero if N
were 127, the following 128 octets would have the encoded unsigned
number.

SDNV-16

If the most significant bit of the discriminant report
segment is zero, then the
length NOT a response to reception of a checkpoint, i.e., the SDNV-16
reception report is asynchronous; otherwise it is 2 octets and the contents of the
remaining 7 bits checkpoint
serial number of the discriminant concatenated with checkpoint that caused the
following octet, viewed as RS to be issued.

Upper bound [SDNV-16]

The upper bound of a 15-bit unsigned integer, report segment is the value

Burleigh size of the block
prefix to which the segment's reception claims pertain.

Ramadas et al. Expires - January June 2005 [Page 17] 14]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

encoded. An integer in the range

Lower bound [SDNV-16]

The lower bound of 0 to 32767 can be encoded this
way.

Otherwise (if a report segment is the most significant bit size of the discriminant is 1),
the encoding is similar (interior)
block prefix to SDNV-8. If which the content segment's reception claims do NOT
pertain.

Reception claim count [SDNV-8]

The number of data reception claims in this report segment.

Reception claims

Each reception claim comprises two elements: offset and length.

Offset [SDNV-16]

The offset indicates the remaining
7 bits viewed as an unsigned integer has the value N, successful reception of data beginning
at the encoded
number is N+1 octets long, and has indicated offset from the value found by
concatenating octets 2 through N+2 lower bound of the SDNV-16, viewed as an
unsigned integer.

An SDNV RS. The
offset within the entire block can therefore be used to represent both very large and very
small integer values. For example, calculated by summing
this offset with the maximum size lower bound of the RS.

Length [SDNV-16]

The length of an SDNV - a
1024-bit reception claim indicates the number - is large enough to contain a fairly safe encryption
key, while any whole-degree Celsius temperature in of
contiguous octets of block data starting at the range in which
water is a liquid can be represented in a single-octet SDNV-8.

In indicated
offset (within the LTP header specification that follows, various fields in scope of the
header are defined report) that have been
successfully received so far.

Reception claims MUST conform to be of types SDNV-8 or SDNV-16 depending on the
typical range of values expected for following rules:

A reception claim's length shall never be less than 1 and shall
never exceed the field. If a field in difference between the
header carries a number that typically requires 16 bits to encode,
but under certain infrequent conditions may grow longer upper and require,
say, 32 bits to encode, it might be optimal to specify it as an
SDNV-16 instead lower bounds
of specifying the field as report segment.

The offset of a fixed 32 bit integer.

However, SDNV is clearly not the best way to represent every numeric
value. When reception claim shall always be greater than
the maximum possible value sum of a number is known without
question, the cost offset and length of an additional 8 bits the prior claim, if any.

The sum of discriminant may not be
justified. For example, an SDNV-8 is a poor way to represent an
integer whose value typically falls in reception claim's offset and length and the range 128 to 255.

In general, though, we believe that SDNV representation lower
bound of selected
numeric values in LTP segments yields the smallest report 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 shall never exceed the upper bound
of the report segment.

Implied requests for retransmission of events in an LTP transmission session is as
follows.

Operation begins when a client service instance asks data can be
inferred from an LTP engine to
transmit a 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 remote client service instance. The sending

Burleigh report segment has lower bound 0 and

Ramadas et al. Expires - January June 2005 [Page 18] 15]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

engine opens a Sending State Record (SSR) for a new session, thereby
starting the session,

upper bound 6000, and 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 as a
checkpoint, indicating that the receiving engine must issue report contains a single data reception report upon receiving the segment,
claim with offset 0 and as an EOB,
indicating that length 6000, then the receiving engine can calculate report signifies
successful reception of the size first 6000 bytes of the
block by summing block. If the offset and
total length of the data in the segment.

At block is 6000, then the next opportunity, subject to allocation report additionally
signifies successful reception of bandwidth to the
queue into which the block data segments were written, the enqueued
segments are transmitted to the LTP engine serving entire block.

If on the remote client
service instance. A timer is started for other hand, the EOB, so that it can be
retransmitted automatically if no response is received.

On reception scope of the first data a report segment for the block, has lower bound
1000 and upper bound 6000, and the receiving
engine opens a Receiving State Record (RSR) for report contains two data reception
claims, one with offset 0 and length 2000 and the new session other with offset
3000 and
notifies length 500, then the local instance report signifies successful reception
only of bytes 1000-2999 and 4000-4499 of the relevant client service block. From this we
can infer that the
session has been started. In the nominal case it receives all
segments bytes 3000-3999 and 4500-5999 of the original transmission without error. Therefore on block need to be
retransmitted, but we cannot infer anything about reception of the EOB data segment it responds by (a) queuing for
transmission to
first 1000 bytes.

3.2.3 Report Acknowledgment Segment

The content of an RA is simply the sending engine a report segment indicating
complete reception and (b) delivering the received block to the local
instance serial number of the client service.

At the next opportunity, the enqueued report segment is immediately
transmitted RS in
response to which 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 was generated.

Report serial number [SDNV-8]

This field returns the report segment, turns off serial number of the timer
for RS being
acknowledged.

3.2.4 Session Management Segments

Note: the EOB, enqueues reason we use different cancel segment types for transmission to the receiving engine a
report-acknowledgment segment, notifies the local client service
instance that the block has been successfully transmitted,
originator and closes
the SSR for the session.

At the next opportunity, the enqueued report-acknowledgment segment recipient 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 allow a session terminates loopback mode to work without
disturbing any replay protection mechanism in use.

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

Reason-Code Mnemonic Semantics
----------- -------- ---------------------------------------
00 CNCLD Client Service canceled session.

Burleigh

01 UNREACH Unreachable Client Service.

02 RLEXC Retransmission limit exceeded.

03 MISCOLORED Received either a red-part data segment
at block offset above any green-part
data segment offset or a green-part
data segment at block offset below any
red-part data segment offset.

Ramadas et al. Expires - January June 2005 [Page 19] 16]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

5.2 Retransmission

Loss or corruption of transmitted segments causes the operation

04-FF Undefined

The Cancel-acknowledgments (CAx) have no content.

3.3 Segment Trailer

The segment trailer consists of
LTP to deviate from the nominal a sequence of events from zero to 15
extension TLVs as described in Section 3.1.4 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,

4. Requests from Client Service

In all cases the receiving engine returns representation of request parameters is a reception report comprising
as many report segments local
implementation matter, as are needed in order to report validation of parameter values and
notification of the client service in detail on
all data reception for this session (other than data reception the event that
was previously reported in response a request is
found 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 be invalid.

4.1 Transmission Request

In order to request transmission of a block data are lost.] A timer is started for each
report segment.

On reception of each report segment client service data,
the sending client service MUST provide the following parameters to LTP:

Client service ID

Destination LTP engine responds ID

Client service data to send, as
follows:

It turns off the timer for the checkpoint referenced by an array of bytes.

Length of the report
segment, if any.

It enqueues a reception-acknowledgment segment acknowledging data to be sent. This value MUST NOT exceed the
report segment (to turn off
largest numeric value that can be represented in an SDNV-8.

Length of the report retransmission timer at red-part of the
receiving engine). data. This segment is sent immediately at the next
transmission opportunity.

If the reception claims value MUST be in the report segment indicate that not
all data within
range from zero to the scope have been received, it normally
initiates a retransmission by enqueuing all total length of data segments not yet
received. The last such segment is marked to be sent.

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

First the report serial number array of the report segment data to which
the retransmission is a response. These segments are likewise be sent at is subdivided as necessary, with
each subdivision serving as the next transmission opportunity, but subject to
allocation client service data of bandwidth to the queue into which the retransmission a single new
LTP data segments were written. A timer is started segment. The algorithm used for subdividing the
checkpoint, so that data is a
local implementation matter; it can be retransmitted automatically if no
responsive report segment is received.

However, expected that data size
constraints imposed by the underlying communication service, if any,
will be accommodated in this algorithm.

The last (and only the number last) of checkpoints issued for this session
has reached the resulting data segments must be
marked as the EOB.

Note that segment type indicates that the client service data in a predefined limit (established by network
management), then
given LTP segment either is or is not in the receiving engine instead cancels red-part of the
session as described later.

Burleigh block.

Ramadas et al. Expires - January June 2005 [Page 20] 17]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

On the other hand, if the reception claims in the report

To prevent segment
indicate that all type ambiguity, each data within segment MUST contain
either only red-part data or only green-part data. Note that this
implies that, when the scope length of the report segment have
been received, block's red-part is N and the union
total length 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 M, and closes the SSR for N is not equal to M, the session.

On reception (N+1)st
byte of a checkpoint segment with a non-zero report serial
number, the receiving engine first turns off the timer for block MUST be the
referenced report segment. Then it returns a reception report
comprising as many report segments as are needed in order to report first byte of client service data in detail on all
some green-part data reception within segment.

If the scope length of the referenced
report segment, within block's red-part is greater than zero, then the constraints on maximum
last data segment containing red-part data must be marked as the EORP
segment size
imposed by setting the underlying communication service; a timer appropriate segment type flag bits [Sec
3.1.2]. Zero or more preceding data segments containing red-part data
(selected according to an algorithm that is started
for each report segment. If at this point all a local implementation
matter) MAY additionally be marked to serve as additional
discretionary checkpoints [Sec 3.1.2].

All data in segments are appended to the block have
been received, (conceptual) application data
queue for transmission.

Finally, a session start notice [Sec 6.1] is sent back to the receiving engine delivers client
service that requested the received block transmission.

4.2 Cancellation Request

In order to
the local instance request cancellation of a session, either as sender or as
receiver of the associated data block, the client service and closes must
provide to LTP the RSR for session ID of the
session; otherwise session to be canceled.

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

First the data retransmission cycle continues.

However, internal "Cancel session" procedure [Sec 5.19] is invoked.

Next, if the number of reception reports issued for this session has reached a predefined limit (established is being canceled by network
management), then the receiving engine instead cancels block sender (i.e., the
session
as described later.

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

Loss of an EOB or other checkpoint segment, or originator part of the responsive
report segment causes session ID supplied in the checkpoint timer to expire. When this
occurs,
cancellation request is the sending local LTP engine normally retransmits the checkpoint
segment. However, if ID):

If none of the number data segments previously queued for transmission as
part of times this checkpoint has session have yet 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, de-queued and radiated - i.e.,
if the number destination engine cannot possibly be aware of times this report segment
has been retransmitted has reached a predefined limit (established by
network management), session
- then the receiving agent instead cancels session is simply closed; the
session.

Reception of "Close session" procedure
[Sec 5.20] is invoked.

Otherwise, a previously received report segment that was
retransmitted due to loss of an report-acknowledgment segment causes
another responsive report-acknowledgment segment to CS with reason-code CNCLD MUST be transmitted,
but is otherwise ignored; if any of queued for
transmission to the data retransmitted destination LTP engine specified in
response to the previously received report segment were lost, further

Burleigh
transmission request that started this session.

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

Ramadas et al. Expires - January June 2005 [Page 21] 18]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 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

If there is suppressed.

5.2.1 Reception Reporting Rules

The upper no transmission queue-set bound of a synchronous reception report is for the upper bound
of block sender
(possibly because the checkpoint segment to which it responds.

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

The lower bound of running on a primary reception report receive-
only device), then the session is simply closed; the upper bound of
the previously issued primary reception report for the same session,
if any; otherwise it "Close
session" procedure [Sec 5.20] is zero.

The lower bound of invoked.

Otherwise, a secondary reception report is the lower bound of
the report segment CR with reason-code CNCLD MUST be queued for
transmission to which the triggering checkpoint was itself a
response.

Asynchronous reception reports are never issued after the arrival of block sender.

5. Internal Procedures

This section describes the EOB segment for a session.

A reception report comprises as many reception segments as internal procedures that are
necessary to report on all data reception in triggered by
the scope occurrence of various events during the
reception report, within life-time of the constraints on maximum segment size
imposed by LTP
session.

Whenever the underlying communication service. [Again, a reception
report normally comprises only a single reception segment; multiple
report segments are needed only when a large number of segments for
non-contiguous intervals content of block data are lost.] The lower bound any of the first report segment fields of a reception report is the reception
report's lower bound; the upper bound header of any
received LTP segment does not conform to this specification document,
the last report segment is assumed to be corrupt and MUST be discarded
immediately and processed no further. This procedure supersedes all
other procedures described below.

All internal procedures described below that are triggered by the
arrival of a
reception report is data segment are superseded by the reception report's upper bound.

5.2.2 Design Rationale

Note following procedure
in the event that the responsibility for responding to client service identified by the data segment loss in
does not exist at the local LTP engine:

If there is
shared between no transmission queue-set bound for the block sender and receiver of
(possibly because the local LTP engine is running on a block: receive-
only device), then the sender
retransmits checkpoint segments in response to checkpoint timeouts,
and it retransmits non-checkpoint received data segments in response to
reception reports indicating incomplete reception, while segment is simply discarded.

Otherwise, if the receiver
additionally retransmits report segments in response data segment contains data from the red-part of
the block, a CR with reason-code UNREACH MUST be enqueued for
transmission to timeouts. An
alternative design would have been the block sender. A CR with reason-code UNREACH
SHOULD be similarly enqueued for transmission to make the data sender responsible for
all retransmission,
even if the data segment contained data from the green-part of the
block; note however that (for example) in which the case where the block
receiver would knows that the sender of this green-part data is
functioning in a "beacon" (transmit-only) fashion, a CR need not expect
report-acknowledgment segments
be sent. In either case the received data segment is discarded.

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

Response: the de-queuing and would not retransmit report
segments. There are two disadvantages delivery of segments to this approach:

Burleigh the LTP engine
specified in the link state cue begins.

5.2 Start Checkpoint Timer

Ramadas et al. Expires - January June 2005 [Page 22] 19]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

First, because of constraints on segment size that might be imposed

This procedure is triggered by arrival of a link state cue indicating
the underlying communication service, it is at least remotely
possible that de-queuing (for transmission) of a CP segment.

Response: 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 expected arrival time of
those reception reports would the RS that will be needed. We believe 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 current
design
remote LTP engine has ceased transmission [Sec 5.5], then this timer
is simpler.

Second, immediately suspended, because the computed expected arrival time
may require an engine adjustment that receives a block needs a way to determine when
the session can cannot yet be closed. In the absence computed.

5.3 Start RS Timer

This procedure is triggered by arrival of explicit final report
acknowledgment (which entails retransmission a link state cue indicating
the de-queuing (for transmission) of an RS.

Response: the report in case expected arrival time of the loss RA that will be produced
on reception of this RS is computed, and a countdown timer for this
arrival time is started. However, if it is known that the report acknowledgment), remote LTP
engine has ceased transmission [Sec 5.5], then this timer is
immediately suspended, because the alternatives are (a) to
close computed expected arrival time may
require an adjustment that cannot yet be computed.

5.4 Stop Transmission

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

Response: the report segment
that signifies complete reception de-queuing and (b) delivery to close the session on
receipt underlying communication
system of an explicit authorization segments from traffic queues bound for the sender. In case (a),
loss of the final report segment would cause retransmission of a
checkpoint by LTP engine
specified in 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 link state cue ceases.

5.5 Suspend Timers

This procedure is triggered by arrival of a new block,
most of which was lost in transit, and link state cue indicating
the result would be redundant
retransmission cessation of transmission from a specified remote LTP engine to
the entire block. In case (b), local LTP engine. Normally, this event is inferred from advance
knowledge of the explicit
session termination segment and remote engine's planned transmission schedule.

Response: countdown timers for the responsive acknowledgment by acknowledging segments that the
receiver (needed in order
remote engine is expected to turn off return are suspended as necessary based
on the timer for following procedure.

The nominal acknowledge transmission time is computed as the termination
segment, which in turn would be needed in case of in- transit loss or
corruption sum of that segment) would somewhat complicate
the protocol,
increase bandwidth consumption, and retard the release transmission time of session
state resources at the sender. Again we believe original segment (to which the current design
is simpler
acknowledging segment will respond) and more efficient.

5.3 Accelerated Delivery

The receiving engine normally delivers block data content to the
client service only at one-way light time to the moment when reception
remote engine, plus N seconds of the block "additional anticipated latency"
(AAL) encompassing anticipated transmission delays other than signal
propagation time. N is
completed determined in an implementation-specific

Ramadas et al. Expires - that is, on reception of June 2005 [Page 20]
Internet Draft LTP - Specification December 2004

manner. For example, when LTP is deployed in deep space vehicles,
the last not-yet-received
segment of one-way light time to the block. For some applications however, it remote engine may be
desirable to deliver block data content incrementally, upon arrival,
because portions of the block may very large while N
normally need only reflect processing and queuing delay margin; it
can be individually useful a network management parameter, for which 2 seconds seems to the
client service.

When the client service requests accelerated delivery of
be a block, the
arrival reasonable default value. As another example, when LTP is
deployed in a terrestrial "data mule" environment, one-way light time
latency is effectively zero while N may need to be some dynamically
computed function of each new the data segment causes mule circulation schedule.

If the receiving engine to
deliver nominal acknowledge transmission time is greater than or equal
to the client service the data content of current time (i.e., the acknowledging segment
together with the segment's offset within the block. The client
service assumes all responsibility may be presented
for reassembling transmission during the block; upon
completion of reception, time that transmission at the receiving remote
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 suspended), then the countdown timer for this acknowledging
segment retransmission occurs only on receipt is suspended.

5.6 Resume Timers

This procedure is triggered by arrival of a report
segment link state cue indicating incomplete reception; report segments are normally
transmitted only at
the end start of an original transmission or
retransmission. For some applications it may be desirable from a specified remote LTP engine to trigger
data segment retransmission incrementally during the course
local LTP engine. Normally, this event is inferred from advance
knowledge of an
original transmission so that the retransmitted segments arrive
sooner. This can be accomplished in two ways:

Any data remote engine's planned transmission schedule.

Response: expected arrival time is adjusted for every acknowledging
segment prior to that the last one in 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 can
additionally be flagged delay interval that is calculated
as a checkpoint. Reception follows:

The nominal acknowledge transmission time is computed as the sum
of each
checkpoint causes the receiving engine to issue a reception
report.

At any transmission time during of the original transmission of a session (that
is, prior to reception of segment (to which the EOB),
acknowledging segment will respond) and the receiving engine can
unilaterally issue additional "asynchronous" reception reports.
Note that one-way light time to
the CFDP protocol's "Immediate" mode is an example of
this sort remote engine, plus N seconds of asynchronous reception reporting; see Sec 12. The
reception reports generated for accelerated retransmission are
processed in exactly AAL [Sec 5.5].

If the same way as nominal acknowledge transmission time is greater than 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
current time i.e., the remote engine resumed transmission prior to
retransmit them automatically later.

5.5 Session Cancellation

A transmission session may be canceled by either
presentation of the sending or acknowledging segment for transmission, then
the
receiving engine, in response either to a request from transmission delay interval is zero.

Otherwise, the local
client service instance or to an LTP operational failure as noted
earlier. Session cancellation transmission delay interval is accomplished computed as follows.

The canceling engine deletes all currently queued segments for the
session and notifies the local instance of
current time less the affected client
service that nominal acknowledge transmission time.

After adjustment of expected arrival time, each of the session suspended
countdown timers 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 resumed.

5.7 Retransmit Checkpoint

This procedure is complete.
Otherwise, the canceling engine queues for transmission to triggered by the
corresponding engine expiration of a session cancellation countdown timer
associated with a CP 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

Ramadas et al. Expires - January June 2005 [Page 24] 21]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

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

Response: if no response is
received.

The corresponding engine receives the cancellation segment, enqueues number of times this CP segment has been queued for
transmission to exceeds the canceling engine a cancellation-
acknowledgment segment, deletes all other currently queued segments checkpoint retransmission limit established
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 LTP engine by network management, then the next opportunity, session of
which the enqueued cancellation-acknowledgment segment is immediately transmitted to the canceling engine.

The canceling engine receives the cancellation-acknowledgment, turns
off one token is canceled: the timer for "Cancel session"
procedure [Sec 5.19] is invoked, a CS with reason-code RLEXC is
appended to the cancellation segment, (conceptual) application data queue, and closes its state
record for the session.

Loss of a
transmission cancellation segment or of the responsive cancellation-
acknowledgment causes notice [Sec 6.5] is sent back to the cancellation client
service that requested the transmission.

Otherwise, a new copy of the CP segment timer is appended to expire. When
this occurs, the canceling engine normally retransmits
(conceptual) application data queue.

5.8 Retransmit RS

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

Response: if the number of times this
cancellation segment any affected RS has been retransmitted has reached a predefined queued for
transmission exceeds the report retransmission limit (established established for
the local LTP engine by network management), management, then the canceling agent
instead simply closes its state record for the session.

5.6 Unreliable Transmission

For operational conditions in session of which
the massive statefulness of LTP
reliability segment 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 and reassembly, deferred transmission, bandwidth
management, and interface to one token is canceled: the underlying communication service may
still make it useful to client services.

The nominal sequence of events in an unreliable transmission session "Cancel session" procedure
[Sec 5.19] is much simplified.

Operation begins when invoked, a client service instance asks an CR with reason-code RLEXC is queued for
transmission to the LTP engine to
transmit that originated the session, and a block unreliably
reception cancellation notice [Sec 6.6] is sent to a remote the client service instance. The
sending engine queues for transmission as many
identified in each of the data segments as are
necessary received in this session.

Otherwise, a new copy of each affected RS is queued for transmission
to transmit the entire block, within the constraints on
maximum segment size imposed by LTP engine that originated the underlying communication service.
The last such segment session.

5.9 Signify Red-Part Reception

This procedure is marked an EOB signifying that triggered by the receiving
engine can calculate arrival of a CP segment when the
EORP for this session has been received (ensuring that the size of
the block by summing data block's red-part is known; this includes the offset case where the
CP segment itself is the EORP segment) and
length all data in the red-part
of the data block being transmitted in this segment. Note that this session have been received.

Response: a red-part reception notice [Sec 6.3] is sent to the
specified client service.

5.10 Signify Green-Part Segment Arrival

This procedure is triggered by the arrival of a data segment whose
content is an EOB
but not a checkpoint.

Burleigh portion of the green-part of a block.

Ramadas et al. Expires - January June 2005 [Page 25] 22]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

Response: a green-part segment arrival notice [Sec 6.2] is sent to
the next opportunity, subject specified client service.

5.11 Send Reception Report

This procedure is triggered by either (a) reception of a CP segment
whose checkpoint serial number is not equal to allocation that of bandwidth any previously
issued RS or (b) an implementation-specific circumstance pertaining
to the
queue into which the a particular block data segments were written, reception session for which no EORP has yet
been received ("asynchronous" reception reporting).

Response: if the enqueued
segments are transmitted to number of reception problems detected for this
session exceeds a limit established for the local LTP engine serving by
network management, then the remote client
service instance.

The arrival of each data segment causes affected session is canceled: the receiving engine to
deliver
"Cancel session" procedure [Sec 5.19] is invoked, a CR with reason-
code RLEXC is issued and is, in concept, appended to the client service the data content queue of the segment
together with the segment's offset within the block. The client
service assumes all responsibility
internal operations traffic bound for reassembling the block.

Upon arrival of the EOB segment, the receiving LTP engine just delivers that final data segment's content originated
the session, and offset a reception cancellation notice [Sec 6.6] is sent 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 identified in
this mode. Loss each of the EOB is particularly troublesome: the
receiving client service instance cannot readily distinguish between
actual data loss and very severe queuing delay segments received
in this case, and session. One possible limit on reception problems would be
the
total size maximum number of the block reception reports which can never be known. But issued for some
applications (e.g., continuous telemetry streaming), or in deployment
over any
single session.

If such limit is not reached, a reliable link-layer protocol, this deficiency may be
unimportant.

6. Functional Model

The functional model underlying the specification of LTP reception report is one issued as
follows.

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

6.1 Deferred Transmission

Every outbound LTP segment is appended to one reception report was triggered by reception of several conceptual
queues -- forming a "queue set" -- of traffic
checkpoint:

The upper bound for of the LTP
engine that is that segment's destination. One such conceptual
traffic queue is designated report SHOULD be the "internal operations queue" upper bound (the sum
of that
queue set, the offset and length) of the queue set includes at least one additional
conceptual queue for application checkpoint data transmission.

The production and enqueuing segment, to
minimize unnecessary retransmission. Note: For deployments where
bandwidth economy is not critical, the upper bound of a segment and
synchronous reception report MAY be the subsequent actual
transmission of that segment are maximum upper bound value
among all red-part data segments received so far in principle wholly asynchronous.

In the event that (a) a transmission link to affected
session.

If the destination checkpoint was itself issued in response to a report
segment, then this report is
currently active and (b) a "secondary" reception report. In
that case the queue lower bound of the report SHOULD be the lower bound
of the report segment to which the triggering checkpoint was
itself a given outbound segment
is appended response, to minimize unnecessary retransmission. Note:
For deployments where bandwidth economy is otherwise empty and (c) not critical, the lower
bound of the report MAY instead be zero.

If the checkpoint was not issued in response to a report segment,
this queue report is determined to
have a "primary" reception report. The lower bound of
the highest transmission priority among all outbound traffic

Burleigh first primary reception report issued for any session MUST be

Ramadas et al. Expires - January June 2005 [Page 26] 23]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

queues associated with that destination,

zero. The lower bound of each subsequent primary reception report
issued for the segment will same session SHOULD be
transmitted immediately upon production. Transmission of a newly
queued segment is necessarily deferred in all other circumstances.

Conceptually, the de-queuing of segments from traffic queues upper 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., prior
primary reception report issued for the link session, to that destination minimize
unnecessary retransmission. Note: For deployments where bandwidth
economy is now active. It ceases upon not critical, the lower bound of every primary
reception report MAY be zero.

If production of a link state cue
indicating that the underlying communication system reception report is no longer
transmitting to that destination, i.e., the link to that destination
is no longer active.

Note: in "asynchronous" as noted
above:

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

The lower bound of a segment always
implies delivering it to the underlying communication system for
immediate transmission.

6.2 Bandwidth Management

We believe it is necessary first asynchronous reception report issued
for LTP to provide a mechanism any session for
apportioning access to which no other primary reception reports have
yet been issued MUST be zero. The lower bound of each subsequent
asynchronous reception report SHOULD be the active transmission link, possibly
unevenly, among multiple classes upper bound of client service data traffic, and
at the same time to provide a minimum-latency control channel
prior primary reception report issued for
acknowledgment traffic.

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 the session, to minimize
unnecessary retransmission. Note: For deployments 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
economy is not critical, the choice lower bound of bandwidth
management mechanism may have an impact on protocol performance, it
will not affect interoperability; an LTP implementation using a
different bandwidth management model or none at all may still every asynchronous
reception report MAY be
deemed compliant with this specification. zero.

In all cases, if the proposed model, one physical traffic queue for each
destination is strictly reserved for applicable lower bound of the conceptual internal
operations queue: it contains only scope of a report and acknowledgment segments
(collectively, "acknowledging segments"), which must
is determined to be transmitted
promptly greater than or equal to protect timer accuracy. A second physical queue for each
destination is reserved for segments the applicable upper
bound (e.g., due to out-of-order arrival of discretionary
checkpoints) then the reception report MUST NOT be issued. Otherwise:

As many RSs must be produced in sessions designated as "priority" sessions. Other physical traffic queues supported by a
given LTP engine are for segments produced needed in non-priority sessions,
typically of varying levels order to report on all
data reception within the scope of urgency. the report, given whatever data
size constraints are imposed by the underlying communication service.
The client service specifies RSs are, in concept, appended to the queue to be used of internal operations
traffic bound for transmitting a given block - either the
priority session queue or one LTP engine that originated the indicated
session. The lower bound of the non- priority session queues -

Burleigh et al. Expires - January 2005 [Page 27]
Internet Draft Licklider first RS of the report MUST be the
reception report's lower bound. The upper bound of the last RS of
the report MUST be the reception report's upper bound.

5.12 Signify Transmission Protocol July 2004 Completion

This procedure is triggered at the earliest time transmission at which (a) all
data in the block are known to have been transmitted *and* (b) the
entire red-part of the block - if of non-zero length - is requested.

While the link known to a given destination
have been successfully received. Condition (a) is active, continuous iteration signaled by
arrival of the following algorithm governs a link state cue indicating the de-queuing (for
transmission) of segments from the physical traffic queues bound EOB segment for that destination:

If any segments are currently in the internal operations queue,
then de-queue block. Condition (b) is
signaled by reception of an RS whose reception claims, taken together
with the oldest such segment.

Otherwise, if any segments are currently reception claims of all other RSs previously received 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
course of this session, indicate complete reception of the next queue to
transmit from and then de-queue red-part
of the oldest segment in that queue.

6.3 Timers block.

Ramadas et al. Expires - June 2005 [Page 24]
Internet Draft LTP relies on accurate calculation of expected arrival times for
report and acknowledgment segments in order to know when proactive
retransmission is required. If - Specification December 2004

Response: a calculated time were even slightly
early, transmission completion notice [Sec 6.4] is sent to the result would be costly unnecessary retransmission. On
client service that requested the
other hand, calculated arrival times may safely be several seconds
late: transmission identified in the only penalties for late timeout and retransmission are
slightly delayed data delivery
segment header and slightly delayed release of the session resources.

The following discussion is closed: 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 "Close session"
procedure [Sec 5.20] is invoked.

5.13 Retransmit Data

This procedure is triggered by transmission and reception of an RS.

Response: first, an RA with the acknowledging segment) has same report serial number as the following components:

Protocol processing time consumed RS
is issued and is, in issuing concept, appended to the original segment,
receiving queue of internal
operations traffic bound for the original segment, generating and issuing LTP engine that originated the
acknowledging segment, and receiving
indicated session. If the acknowledging segment.

Outbound queuing delay: delay at RS is redundant -- i.e., either the sender of
indicated session is unknown (for example, the original
segment while that segment RS is in a queue waiting for transmission,
and delay at received after
the sender of session has been completed or canceled), or the acknowledging segment while that
segment RS's report
serial number is in equal to that of a queue waiting for transmission.

Radiation time: previously received report
segment for this session -- then no further action is taken.
Otherwise the time that passes while all bits of procedure below is followed.

If the
original segment are being radiated, and report's checkpoint serial number is not zero, then the time that passes
while all bits of
countdown timer associated with the acknowledging indicated checkpoint segment are being radiated.
(This is significant only at extremely low
deleted.

Note: All retransmission buffer space occupied by data transmission
rates.)

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

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

Inbound queuing delay: delay at the receiver report segment can be released.

If the segment's reception claims indicate incomplete data reception
within the scope of the original
segment while that segment is in report segment:

If the number of transmission problems for this session exceeds a reception queue, and delay at
limit established for the receiver local LTP engine by network management,
then the session of which the acknowledging segment while that segment is in one token is canceled:
the "Cancel session" procedure [Sec 5.19] is invoked, a reception queue.

Delay in CS with
reason-code RLEXC is appended to the transmission of queue specified
in the acknowledging segment due to loss of
connectivity - transmission request that is, interruption in outbound link activity at started this session, and a
transmission cancellation notice [Sec 6.5] is sent back to the sender of
client service that requested the acknowledging segment due to occultation,
scheduled end of tracking pass, etc.

In this context, where errors transmission. One possible
limit on transmission problems would be the order maximum number of seconds or even minutes
retransmission CP segments which 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 issued for any single
session.

If the underlying communication system
notifies LTP that radiation number of the original segment has begun.
All outbound queuing delay transmission problems for the original segment this session has already
been incurred at that point.

The bandwidth management mechanism [Sec 6.2] is expected to
minimize latency in the delivery of acknowledging not
exceeded any limit, new data segments
(reports and acknowledgments) to the underlying communication
system. For example, in encapsulating all block data
whose non-reception is implied by the example bandwidth management model
described in Sec 6.2, acknowledging segments reception claims 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 and radiate all other acknowledging segments that are
currently transmission queue specified in the transmission
request that queue. Since acknowledging segments are sent
infrequently started this session. The last - and are normally very small, outbound queuing delay
for a given acknowledging only the last -
such segment is likely to must be minimal.

Radiation delay at each end of the session is simply marked as a CP segment size
divided by transmission data rate. It is insignificant except when
data rate is extremely low (e.g., 10 bps), in which case and must contain the use
report serial number 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 received RS.

Ramadas et al. Expires - January June 2005 [Page 29] 25]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

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

So the initial expected arrival time for each acknowledging segment

5.14 Stop RS Timer

This procedure is typically computed as simply the current time at the moment that
radiation triggered by reception of an RA.

Response: the countdown timer associated with the original segment begins, plus twice RS
(identified by the one-way
light time, plus 2*N seconds report serial number of margin to account for processing and
queuing delays and for radiation time at both ends. N the RA segment) is a parameter
set by network management
deleted. If no other countdown timers associated with RSs exist
for which 2 seconds seem to be a reasonable
default value.

This leaves only one unknown, this session, then the additional round trip time
introduced session is closed: the "Close session"
procedure [Sec 5.20] is invoked.

5.15 Start Cancel Timer

This procedure is triggered by loss arrival of connectivity. To account for this, we again
rely on external a link state cues. Whenever interruption cue
indicating the de-queuing (for transmission) of
transmission at a remote LTP engine is signaled by a link state cue,
we suspend Cx.

Response: the countdown timers for all acknowledging segments expected from arrival time of the CAx that engine. Upon will be
produced on reception of this Cx is computed and a signal countdown timer
for this arrival time is started. However, if it is known that transmission
the remote LTP engine has
resumed at that engine, we resume those timers after (in effect)
adding to each ceased transmission [Sec 5.5] then this
timer is immediately suspended, because the computed expected
arrival time may require an adjustment that cannot yet be
computed.

5.16 Retransmit Cancellation Segment

This procedure is triggered by the length expiration of the timer
suspension interval.

7. Segment Structure

Each LTP segment comprises (a) a "header" in countdown timer
associated with a standard format, (b)
zero or more octets of "content", (c) zero or more octets of
"trailer" as indicated by information in Cx.

Response: if the "extensions field" number of times this Cx has been queued for
transmission exceeds the header. cancellation retransmission limit
established for the local LTP segments are of four general types, depending on engine by network management, then
the
nature session of which 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.

A report segment carries data reception claims together with is one token is simply closed:
the
upper and lower bounds "Close session" procedure [Sec 5.20] is invoked.

Otherwise, a copy of the data block scope cancellation segment (retaining the same
reason-code) is queued for transmission to which the claims
pertain.

A report-acknowledgment segment carries only appropriate LTP
engine.

5.17 Acknowledge Cancellation

This procedure is triggered by the serial number reception of a Cx.

Response: in the report being acknowledged.

Session management segments are case of two general subtypes:
Cancellation and Cancellation-acknowledgment. A Cancellation
segment carries a single byte reason-code to indicate the reason CS where there is no transmission
queue-set bound for the cancellation. Cancellation-acknowledgment segments have engine that originated the segment's
session (possibly because the local LTP engine is running on a
receive-only device), then no
content.

7.1 Segment Header

<< Recommendations of SDNV-8 / SDNV-16 for fields in action is taken. Otherwise:

If the received segment

Burleigh is a CS, a CAS is issued and is, in

Ramadas et al. Expires - January June 2005 [Page 30] 26]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

header as recommended in this section are under discussion. Future
versions of the draft may recommend fields

concept, appended to be of one SDNV type
instead of the other (SDNV-8 in place queue of SDNV-16, internal operations traffic
bound for example), if
found to be more appropriate. >>

An the LTP engine that sent the CS.

If the received segment header comprises three data items: is a single-octet
control byte, CR, a session ID, CAR is issued and an extensions field.

Control byte comprises the following:

Version number (4 bits): MUST be set is, in
concept appended to the binary value 0000 for
this version queue of internal operations traffic
bound for the protocol.

Segment type flags (4 bits): described below.

Session ID uniquely identifies, among all transmissions between LTP engine that sent the
segment's sender and receiver, CR.

It is possible that the Cx has been retransmitted because a
previous 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. It comprises If so, no further action is taken.

Otherwise: the following:

Session originator: "Cancel session" procedure [Sec 5.19] is invoked
and a reception cancellation notice [Sec 6.6] is sent to the engine ID
client service identified in each of the LTP engine that initiated
the session, in SDNV-8 representation.

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

The format and resolution of session number are matters that are
private to the session-originating engine; is closed: the only requirement
imposed by LTP "Close session"
procedure [Sec 5.20] is that every session initiated by an LTP engine
MUST be uniquely identified invoked.

5.18 Stop Cancel Timer

This procedure is triggered by reception of a CAx.

Response: the session ID.

The extensions field of which the segment is described in section 7.1.4 below.

7.1.1 Segment Type Flags

The last four bits one token is closed,
i.e., the "Close session" procedure [Sec 5.20] is invoked.

5.19 Cancel Session

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

Response: all segments of the segment header are
flags affected session that indicate are currently
queued for transmission can be deleted from the nature of outbound traffic
queues. All countdown timers currently associated with the segment. In order (most
significant bit first), these flags
session are as follows.

Control flag (CTRL)

A value of 0 indicates that deleted. Note: If the segment local LTP engine is a data segment, while a
value the
originator of 1 indicates that the segment session, then all remaining data retransmission
buffer space allocated to the session can be released.

5.20 Close Session

This procedure is a control segment.

Exception flag (EXC)

A value triggered internally by one of 1 in the other
procedures described above.

Response: any remaining countdown timers associated with the
session (such as the timer associated with a data segment indicates that Cx) are deleted. The
session state record (SSR|RSR) for the segment session is being
transmitted unreliably. In a control segment (CTRL flag set), this

Burleigh deleted;
existence of the session is no longer recognized.

5.21 Handle Miscolored Segment

Ramadas et al. Expires - January June 2005 [Page 31] 27]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

indicates that

This procedure is triggered by the segment pertains to session cancellation
activity.

Request flag (REQ)

If set, this flag signifies arrival of either (a) a request for some specific response
from the receiver, depending on red-
part data segment whose block offset begins at an offset higher
than the values offset of any green-part data segment previously received
for the other flags as
described below.

Closure flag (CLOS)

When set, this flag signifies same session or (b) a green-part data segment whose block
offset begins at an offset lower than the termination of some element offset of
protocol activity. any red-part
data segment previously received for the same session.

Response: the received data segment is simply discarded.

The nature of Cancel Session procedure [Sec 5.19] is invoked and a CR with
reason-code MISCOLORED SHOULD be enqueued for transmission to the activity being terminated
again depends
data sender. Note : If there is no transmission queue-set bound
for the block sender (possibly because the local LTP engine is
running on a receive-only device), or if the values block receiver knows
that the sender of this green-part data is functioning in a
"beacon" (transmit-only) fashion, a CR need not be sent. A
Reception Cancellation Notice [Sec 6.6] is sent to the other flags as described below.

7.1.2 Segment Type Codes

Combinations client
service.

6. Notices to Client Service

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

6.1 Session Start

The LTP engine returns the settings session ID of the segment type flags CTRL, EXC, REQ
and CLOS constitute segment type codes which serve as concise
representations new transmission
session when a session start notice is delivered.

A session start notice informs the client service of detailed segment nature.

CTRL EXC REQ CLOS Code Nature the
initiation 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
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 segment transmission session in response to block sender

1 1 1 0 14 Cancel segment a transmission
request from block receiver
1 1 1 1 15 Cancel-acknowledgment segment that client service. On receiving this notice the
client service may, for example, release resources of its own that
are allocated to the block receiver

7.1.3 being transmitted, or remember the
session ID so that the session can be canceled in the future if
necessary.

6.2 Green-Part Segment Class Masks

Burleigh Arrival

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

Session ID of the transmission session.

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

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

Ramadas et al. Expires - January June 2005 [Page 32] 28]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

For

block.

Length of the purposes data segment's content.

Indication as to whether or not the last byte of this specification, some bit patterns in data
segment's content is also the
segment type flags field correspond to "segment classes" that are
designated by mnemonics. end of the block.

Source LTP engine ID.

6.3 Red-Part Reception

The mnemonics following parameters are intended to evoke the
characteristics shared provided by all types the LTP engine when a
red-part reception notice is delivered:

Session ID of segments characterized by
these flag bit patterns.

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

0 - - 1 EOB End the transmission session.

Array of block;
block size = offset + length

1 0 0 0 RS Report segment;
carries reception claims

1 0 0 1 RA Report-acknowledgment segment

1 1 0 0 CS Cancel segment from block sender

1 1 0 1 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 client service data bytes that constitute the red-part
of zero or more extensions to the basic segment header.

The first octet block.

Length of the extensions field contains red-part of the number block.

Indication as to whether or not the last byte of
extensions present (thus 255 the red-part
is also the maximum number end of extensions for the block.

Source LTP engine ID.

6.4 Transmission Completion

The sole parameter provided by the LTP engine when a single segment). In transmission
completion notice is delivered is the absence session ID of any extensions, this octet MUST
contain zero.

Each extension consists the
transmission session.

A transmission completion notice informs the client service that
all bytes of a one-octet tag identifying the type indicated data block have been transmitted and
the destination LTP engine has received the red-part of
extension, followed by an extension specification in SDNV-8 format. the block.

6.5 Transmission Cancellation

The diagram below shows how parameters provided by the expansion zone LTP engine when a transmission
cancellation notice is constructed.

Burleigh delivered are:

Session ID of the transmission session.

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

A transmission cancellation notice informs the client service that
the indicated session was terminated, either by decision of the

Ramadas et al. Expires - January June 2005 [Page 33] 29]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

For each extension present, the segment will have a sequence of zero

destination client service instance or more octets due to violation of trailer information. Trailer information sequences
appear a
retransmission limit 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 local 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 engine. There is no
assurance that the receiving destination client service instance to receive
and make use of that data.

Client service ID [SDNV-8]

The client service ID number identifies received
the upper-level service to
which critical part of the segment is to be delivered data block.

6.6 Reception Cancellation

The parameters provided by the destination LTP
engine. It is functionally analogous to engine when a well-known TCP port
number. If multiple instances reception
cancellation notice is delivered are:

Session ID of the transmission session.

The reason-code explaining the cancellation.

A reception cancellation notice informs the client service are present
at that
the destination, multiplexing must be done indicated session was terminated, either by decision of the
source client service itself on instance or due to error conditions at the basis of information encoded within
local LTP engine. No subsequent delivery notices will be issued
for this session.

7. State Transition Diagrams

The following mnemonics have been used in the
transmitted block.

Offset [SDNV-16]

Offset indicates sender and
receiver LTP state transition diagrams that follow :

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

Both the location diagrams have been specified in two parts such that
sequence of state transitions that occur multiple times in the segment's client service data
within the session's transmitted block. It is
main diagram have been presented in the number of bytes second part. Note that
blocks represented in rectangles as in

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

specify actual states in the block prior state-transition diagrams, while
blocks represented as in

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

are not actual states but merely pointers to the byte from which the first octet a state or a sequence
of state transitions represented elsewhere in the

Burleigh state transition

Ramadas et al. Expires - January June 2005 [Page 34] 30]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

segment's client service data was copied.

Length [SDNV-16]

The length

diagram (to avoid having multiple copies of the following client service data, in octets.

If the data segment is a checkpoint, the segment MUST additionally
include the following two serial numbers (Checkpoint serial number
and Report serial number) to support efficient retransmission. 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 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 found by incrementing the prior checkpoint serial
number by 1. When a checkpoint segment is retransmitted however,
its serial number MUST be the same as when it was originally
transmitted.

Report serial number [SDNV-8]

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

Otherwise, the value of 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 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 sequence of the scope within the data
block to which the claims pertain. It also includes two serial
numbers to support efficient retransmission.

Burleigh state
transitions, thus accomodating space constraints).

Ramadas et al. Expires - January June 2005 [Page 35] 31]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 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.

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 RS. The
offset within the entire block can be calculated by summing
this offset with the lower bound of the 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.

Reception claims MUST conform to the following rules:

A reception claim's 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 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 is simply the report serial number of the RS in
response to which the segment was generated.

Report serial number [SDNV-8]

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

7.2.4 Session Management Segments

Burleigh et al. Expires - January 2005 [Page 37]
Internet Draft Licklider Transmission Protocol 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 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 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].

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
indicate additional checkpoints.

On the other hand, if the requested quality of service is unreliable
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 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 - 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 CS with reason-code value 00 [Sec 7.2.4] MUST be
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
(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 CR with reason-code value 00 [Sec 7.2.4] MUST be
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 be transmitted reliably (segment type code value less
than 4) or unreliably (segment type code value greater than 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 device), then the data segment is simply discarded.
Otherwise, if the data segment was transmitted reliably, a CR with
reason-code UNREACH MUST be enqueued for transmission to the block
sender; a CR with reason-code UNREACH SHOULD be similarly enqueued
for transmission to the data sender if the data segment was
transmitted unreliably. [For example, in the case where the block
receiver knows that the sender is functioning in a "beacon"
(transmit-only) fashion, a 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.

Response: the de-queuing and delivery of segments 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) of a CP segment, provided that this
segment either is the EOB for a session or else was issued in
response to an RS -- i.e., the segment's report serial number is non-
zero.

Response: the expected arrival time of the 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 RS.

Response: the expected arrival time of the RA that will be produced
on reception of this 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
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 "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 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:

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.

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 CS with reason-code 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 RS or (b) reception of a CP segment whose
checkpoint serial number is equal to that of one or more previously
issued RSs for the same session -- an unnecessarily retransmitted
checkpoint.

Response: if the number of times any affected 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 CR with reason-code RLEXC is 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 RS is 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.

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 (ensuring that the data block's size is known; this
includes the case where this segment itself is the EOB 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 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 errors detected for this session exceeds a
limit established for the local LTP engine by network management,
then the affected session is canceled: the "Cancel session" procedure
[Sec 9.19] is invoked, a CR with 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 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
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 RS whose
reception claims taken together with the reception claims of all
other 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 RS.

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

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

example, the RS is received after the session has been completed or
canceled), or the 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.

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

If the number of errors for this session exceeds a limit
established for the local LTP engine by network management, then
the session of which the segment is one token is canceled: the
"Cancel session" procedure [Sec 9.19] is invoked, a CO with
reason-code 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 be marked as a CP segment and must contain the report serial
number of the received RS.

9.14 Stop RS Timer

This procedure is triggered by reception of an RA.

Response: the countdown timer associated with the original RS
(identified by the report serial number of the RA segment) is
deleted. If no other countdown timers associated with 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 Cx.

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

Response: the expected arrival time of the CAx that will be
produced on reception of this 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 Cx.

Response: if the number of times this 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 copy of the cancellation segment (retaining the same
reason-code) is queued for transmission to the appropriate LTP
engine.

9.17 Acknowledge Cancellation

This procedure is triggered by the reception of a Cx.

Response: in the case of a CS where there is no transmission
queue-set bound for the engine that originated the segment's
session (possibly because the local LTP engine is running on a
receive-only device), then no action is taken. Otherwise:
If the received segment is a 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 CR.

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

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
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. State Transition Diagrams

The state transition diagrams for a reliable block delivery
session are described in this section. The terms "sender" and
"receiver" are here used to refer to the sending and receiving
lobes of this single session state machine; note that any LTP
engine might at any moment comprise any number of session state
machine nodes of both types.

The diagrams do not include the behavior of the sender and
receiver under accelerated delivery or accelerated retransmission,
nor in the case where a reception report must comprise multiple
report segments.

<<We propose to update the diagrams with the accelerated features

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

in subsequent versions of this draft.>>

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

11.1 Sender
LTP 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

7.1 Sender
LTP Receiver Sender State Transition Diagram
+----+ +--------------------------+--+

/\/\/\/\
| Cncld |
\/\/\/\/
+--------+ | +------+
Rcv CS; CR; | V V ^ ^ V | Rcv RS;
Snd CAS CAR | +-------------+ Rcv CAR| | CR TE,
+--+ Snd RA
+-------+ CLOSED +----+
+---------------------------->+------+------+
| | Blk. Trans. Req
| RL EXC
+-------------->+------+------+ | |
| | Clnt svc. doesn't exist; | |
| Rcv DS; | Snd CR, Start CR Tmr Zero RP +
| Xmit ________________________/ \ Non-Zero RP
| GDS; / \
| Start Session +---+ | +------------------+ | +------+
| +-----+ | V / V | | /\/\ Rcv RS V V V |
| +----------------+ +-----+--+----+ |
| | FIRST_DS_REC |==> | CANCEL_SENT |==>| +---------+ +<-| RX |<---+ +---------+ | +------+-------+-+ +-----------+-+
| +<-+ FG_XMIT | Rcv DS (EOB, CP) | \/\/ +---+ +--->+ Xmit RDS;
| Rcv DS ^ |_____| +----+----+ | | RP_XMIT | (NOT CP) +------+ | CR TE,
| | V V | /\/\ +---+ +--->+ Xmit {RDS, CP};
+<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr
| RL NOT EXC; Xmit \/\/ CP TE | \
| +--------------+ {GDS, EOB}; | | Rxmt CR,
| Xmit {RDS, CP, EORP}; | +-------+
| PRI_BLK_REC |==> Start CP Tmr | | Restart CR Tmr
| | +------------+-+ |
| +------------------+ | +---+ | / |______| +-----------------+ Xmit {RDS,
| | / /\/\ Rcv DS Rcv DS RS V V V | | +------------+ CP, EORP,
| +<-| RX |<---+ +---------+ | (EOB, CP) (NOT CP) RS TE, | EOB};
| | V V V RL NOT EXC; \/\/ +---+ | | | +-------------+ Rcv CP; Rxmt RS, Start
| | | |CHK_BLK_RCVD |==> Rxmt RS Restart RS GP_XMIT +->+ | CP Tmr
| | /\/\ +---+ | Xmit | +-+-----------+ Blk rcvd fully; +--+ +------+
| +<-| CP |<---+ +-----+---+ GDS; |
| \/\/ CP TE | | Snd RS,
| V V | |
| Xmit {GDS, EOB}; | +---------+
| | Start RS Tmr +-+----------+ |
| +------------------+ | |
| | /\/\ Rcv CP; RS V V V
| +------------------>+ CLOSE_WAIT |==> +<-| RX |<---+ +-------------+
| | \/\/ +---+ |
| Rxmt RS | Blk NOT rcvd +-+--+-----+-+ | WAIT_RP_ACK |
| | /\/\ +---+ |
| +<-| CP |<---+ +-----+-------+
| \/\/ CP TE | RP acknowledged fully; Snd RS, Rcv RA;
| V
+----------------------------------------+

Ramadas et al. Expires - June 2005 [Page 32]
Internet Draft LTP - Specification December 2004

LTP Sender State Transition Diagram (contd.)

/\/\ /\/\
| |______| CP | | CX |
\/\/ \/\/
| | | Start RS Tmr Stop RS Tmr Snd CS,
| | RL EXC; | Start CS Tmr;
| | | V V
| | /\/\ | +---+
| +------>| CX | V V | +-------------+<---+ RS TE,
| \/\/ +---------+ | RS CS TE,
| | CS_SENT | +--+ RPT_SENT |==> | RL NOT EXC; | |
V RL NOT EXC; |
| | +----+---+--+-+ +-+--+--+-+ | Rxmt RS, | CS,
Rxmt CP, | Snd CR, | | | Restart
Start CP Tmr; CS TE, | | |______| Restart RS +---+ CS Tmr /
RL EXC; | Start CR Tmr |
| | Rcv DS | | CAS;
V V
/\/\/\/\
| Cncld |
\/\/\/\/

/\/\
| RX | |(NOT CP)
\/\/
| +---------------------------|----+------------------+ Cncl CP Tmr (if any)
V Snd RA
+---------+ +----+
| CHK_RPT | +---+ | Rcv RA; RS TE, |
+-+--+----+ RP in scope V |
| | V V Stop RS Tmr RL EXC; \ KEY NOT rcvd. fully +---------+ | Rxmt
Redundant | | +-------------+ Snd CR, RP +--------------------->| RP_RXMT | --- | missing
RS rcvd; | +--+ SEC_BLK_REC |==> Start CR Tmr | ==>: Async Cncl Req in scope +----+--+-+ | RDS;
| +------+------+ | RL : Retrans. limit rcvd. fully | | | Rcv DS (CP)
V V Rxmt last | EXC: Exceeded +----+
missing RDS | +------------+
(marked CP) | TE : Timer Expiry
+-----------------------------------------------+

Burleigh
Start CP Tmr; |
V

Ramadas et al. Expires - January June 2005 [Page 55] 33]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

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

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

Similarly, from the arrival RP_XMIT state multiple red data segments
are queued for transmission. The sender LTP may optionally mark
some of the
session's first DS. At that time, the receiver enters red data segments as asynchronous checkpoints; 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
internal procedure Start Checkpoint Timer [Sec 5.2] is followed
upon exceeding receiving a retransmission limit, while in any
state other than CLOSED. After entering CLOSED state in this
way, link-state cue indicating the receiver can no longer move to any other state. If a
CS arrives at actual beginning of
transmission of such segments. The sender LTP marks the receiver when last red-
data segment of the block as both CP and EORP, and after queuing
it is in this condition
(possibly due for transmission moves to retransmission by the sender, in the event
that either Green Part Transmission (GP_XMIT)
state. If the CAS block transmission was corrupted or the corresponding count-
down timer expired prematurely), the receiver retransmits fully red however, the
relevant CAS but remains in last
red-data segment is marked as CP, EORP, and EOB and the CLOSED state.

FIRST_DS_REC (First Data Segment Received)

In this state, sender LTP
moves to the receiver considers Wait-for-Red-Part-Acknowledgment (WAIT_RP_ACK) state
instead. For both the DS received and
checks to see if above state-transitions, the referenced client service internal
procedure Start Checkpoint Timer [Sec 5.2] is reachable. If
not, the receiver schedules a CR with reason-code UNREACH for
transmission, starts a CR timer followed upon transmission, and then
enters
receiving a link-state cue indicating the CANCEL_SENT state.

Otherwise (if beginning of
transmission of the client service exists): if queued CP segments. If the DS is marked
EOB and CP, (a single-segment block transmission), sender LTP entered
the receiver
enters GP_XMIT state, the CHK_BLK_RCVD state; if not, it enters remaining green-part of the block is
segmented as green data segments and queued for transmission to
the
PRI_BLK_REC state.

PRI_BLK_REC (Primary Block Reception)

The receiver stays in this state until receiving LTP; the last green segment of primary block transmission, marked with EOB, CP.
When the EOB, CP marked DS block is received,
additionally marked as EOB and the receiver enters sender LTP moves to the
CHK_BLK_RCVD
WAIT_RP_ACK state.

CHK_BLK_RCVD (Check Block Received)

In this state

While the receiver checks to see if sender LTP is at any of the block has been
received fully. If so, RP_XMIT, GP_XMIT, or
WAIT_RP_ACK states, it queues an might be interrupted by the following two
events asynchronously:

1. An RS claiming successful
reception might be received from the receiver LTP (either in
response to a previously transmitted CP segment or sent
asynchronously for transmission, starts an RS timer upon
transmission, and accelerated retransmission). The sender LTP
then enters moves to perform the CLOSE_WAIT state.

Otherwise, sequence of state transitions
beginning at the RX marker (second-part of the diagram), and
retransmits data if there are still holes in necessary, illustrating the block transmitted, internal
procedure Retransmit Data [Sec 5.13]:

First, if the receiver queues for transmission an RS selectively

Burleigh had a non-zero CP serial number, the

Ramadas et al. Expires - January June 2005 [Page 56] 34]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

corresponding CP timer is canceled. Then, an RA segment
acknowledging the received segments of data, starts an RS timer
upon is queued for transmission of to the
receiver LTP and the sender LTP moves to the Check Report state
(CHK_RPT). If the RS was redundantly transmitted by the
receiver LTP (possibly because either the last transmitted RA
got lost or the RS timer expired prematurely at the receiver),
the RS, sender LTP does nothing more and then enters returns back to the RPT_SENT
interrupted state.

CLOSE_WAIT

In this state, the receiver expects Similarly, if all red-data within the arrival scope
of an RA
acknowledging the RS most recently sent. Upon arrival of is reported as received, there is no work to be done
and the
RS, it sender LTP returns to the CLOSED interrupted state.

If However,
if the RS timer expires before the arrival indicated incomplete reception of the RA, data within its
scope, the sender checks LTP moves 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 Red-part Retransmit state
(RP_RXMT) where missing red data-segments within scope are
queued for transmission, starts transmission. The last such segment is marked as a
CP, and the CR timer sender LTP returns to the interrupted state. The
internal procedure [Sec 5.2] is followed upon receiving a
link-state cue indicating beginning of transmission of the CR, and enters CP
segment.

2. A previously set CP timer might expire. Now the CANCEL_SENT state. If sender LTP
follows the RL value was not exceeded, states beginning at the receiver queues a duplicate
RS for transmission, starts CP marker (second-part of
the RS timer upon transmission, diagram), and
stays in CLOSE_WAIT state.

RPT_SENT (Report Sent)

Much like the CLOSE_WAIT state, follows the receiver expects an RA in
this state. Upon reception of internal procedure Retransmit
Checkpoint [Sec 5.7]:

If the RA, CP Retransmission Limit set by network management for
the receiver stops session has been exceeded, the RS
timer, and enters sender LTP proceeds towards
canceling the SEC_BLK_REC state.

If session (with reason-code RLEXC) as indicated by
the RS timer expires before arrival sequence of state transitions following the RA and CX marker.
Otherwise (if the RL Retransmission Limit is not exceeded by yet),
the number of times this RS has been
retransmitted, the receiver queues a duplicate RS CP segment is queued for
transmission retransmission and starts an RS timer upon transmission of the
RS. If the RL has been reached, sender LTP
returns to the receiver queues a CR with
reason-code RLEXC, starts a CR timer interrupted state. The Start Checkpoint Timer
internal procedure [Sec 5.2] is started again upon its transmission, and
then enters receiving a
link-state cue indicating the CANCEL_SENT state.

SEC_BLK_REC beginning of transmission of the
segment.

The receiver sender LTP stays in this Secondary Block Reception State
while continuing to receive non-checkpoint DSs constituting
recovery of at the segments reported missing. When a checkpoint DS WAIT_RP_ACK state after reaching it
until the red-part data is received, fully acknowledged as received by the
receiver goes back LTP, and then returns to the CHK_BLK_RCVD CLOSED state
to see if following the block reception is complete.

CANCEL_SENT

In this state,
internal procedure Close Session [Sec 5.20].

<<Talk about 2 MSL here??>> Note that while at the receiver waits for CLOSED state,
the CAR acknowledging sender LTP might receive an RS (if the last transmitted CR. Upon receiving RA
before session close got lost or if the receiver LTP retransmitted
the CAR, RS prematurely), in which case it returns to retransmits an acknowledging
RA and stays in 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 session was canceled by
the RL
is not exceeded, Receiver by issuing a duplicate CR (with the same reason-code
value sent last) is queued for transmission and segment, the CR timer is
restarted upon transmission. However, if receiver may retransmit
the CR timer expires
and the RL value has been exceeded by (either prematurely or because the number of times acknowledging CAR got
lost). In this
CR has been retransmitted, case, the receiver returns to sender LTP retransmits the acknowledging

Ramadas et al. Expires - June 2005 [Page 35]
Internet Draft LTP - Specification December 2004

CAR and stays in the CLOSED state.

Async Cncl Req (Asynchronous Cancel Request)

An asynchronous

Asynchronous cancel request might may be received by an LTP
receiver in any state. If the request is received locally from the local client
service in a Cancel Request while the sender LTP was in any of the states mentioned.
If it was not already in the sequence of state other
than CLOSED or CANCEL_SENT, a CR transitions
beginning at the CX marker, the internal procedure Cancel Session
[Sec 5.19] is followed, and the sender LTP moves from its current
state into the sequence beginning at the CX marker initiating
session cancellation with reason-code CNCLD CNCLD. From the CX marker,
the CS segment with appropriate reason-code (CNCLD or RLEXC
depending on how the CX sequence was entered) is queued for
transmission to the sender receiver LTP and the receiver sender enters the CANCEL_SENT Cancel-
from-Sender Sent(CS_SENT) state. On the other hand, if The internal procedure Start
Cancel Timer [Sec 5.15] is started upon receiving a link-state cue
indicating the cancel
request was received from beginning of transmission of the sender in a CS segment, a segment. Upon
receiving the acknowledging CAS
segment is queued for transmission in response and from the receiver
returns receiver, the sender LTP
moves to the CLOSED state.

12. Requirements from state (via the Operating Environment

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

The local data-link layer needs to inform LTP whenever CS Timer
expires, the link to
a specific LTP destination internal procedure Retransmit Cancellation Segment
[Sec 5.16] is brought up or torn down. Similarly,
the operating environment needs to inform followed:

If the local LTP engine
whenever it is known that a remote LTP engine is network management set to begin
communication with retransmission limit is exceeded,
the local engine based on session is simply closed and the operating
schedules. sender LTP also needs to be able to query follows the current
distance (in light seconds) to any peer engine in order
Cncld marker to
calculate timeout intervals in a typical deep-space environment.

A MIB (Management Information Base), with the above parameters
filled in by CLOSED state. If the local data-link layer and retransmission limit
is not exceeded however, the operating
environment periodically, should be made available CS segment is queued for a
retransmission and the sender LTP
engine for its operations. stays in the CS_SENT state.
The exact details CS Timer is started upon receiving a link-state cue
indicating the beginning of actual transmission according to
the MIB are,
however, beyond internal procedure Start Cancel Timer [Sec 5.15].

Asynchronous cancel request may also be received from the scope of this document.

In receiver
LTP in the absence form of a CR segment when the use sender LTP is in any of
the states. Upon receiving such a CR segment, the internal
procedure Acknowledge Cancellation [Sec 5.17] is invoked: The
sender LTP sends a CAR segment in response and returns to the
CLOSED state.

Ramadas et al. Expires - June 2005 [Page 36]
Internet Draft LTP - Specification December 2004

7.2 Receiver
LTP Receiver State Transition Diagram

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

Ramadas et al. Expires - June 2005 [Page 37]
Internet Draft LTP authentication [Sec 13.3] - Specification December 2004

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 Receiver State Transition Diagram (contd.)

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

Ramadas et al. Expires - January June 2005 [Page 58] 38]
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 - Specification December 2004

The receiver LTP segments begins 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 the CLOSED state for long periods, and has very high time-out values.
Further, it could enters the Data
Segment Reception (DS_REC) state upon receiving the first data
segment. If the client service ID referenced in the data segment
was non-existent, a CX segment with reason-code UNREACH SHOULD be difficult
sent to reset the sender LTP nodes with the Cancellation sequence beginning
with the CX marker (second part of the diagram). If the received
segment was found to recover from be miscolored (a red-part data segment whose
block offset begins at an attack. Thus offset higher than the offset of any adversary who can actively attack
green-part data segment previously received, or a green-part data
segment whose block offset begins at an LTP
transmission has offset lower than the potential
offset of any red-part data segment previously received), the
internal procedure Handle Miscolored Segment [Sec 5.21] is
followed; a CX segment with reason-code MISCOLORED SHOULD be sent
to create severe DoS conditions for the sender LTP receiver.

To give a terrestrial example - were with the Cancellation sequence beginning with
the CX marker.

Otherwise, the receiver LTP to be used in a sparse
sensor network, DoS attacks could be mounted resulting in nodes
missing critical information, for example, communications schedule
updates. enters the Receive Red-Part state
(RCV_RP) or the Receive Green-Part state (RCV_GP) depending on
whether the segment received was red or green respectively.

In such cases, the RCV_RP state, a single successful DoS attack could take check is made of the nature of the received
red DS. If the segment was a node entirely off regular red data segment, the network until
receiver LTP just returns to the node is physically
visited DS_REC state. For red data
segments marked also as CP and reset.

Even as CP & EORP, a responding RS is
queued for deep space applications of LTP, we do need transmission to consider
certain terrestrial attacks, the sender following either the
internal procedure Retransmit RS [Sec 5.8] or Send Reception
Report [Sec 5.11] depending on whether the CP segment was a
retransmission (An RS corresponding to the Checkpoint Serial
Number in particular those involving
insertion of messages into an on-going session (usually without
having seen the exact bytes CP was previously issued) or not, respectively.
The receiver LTP then returns to the DS_REC state. If the block
transmission was fully red and the segment was marked as CP, EORP,
and EOB, the receiver LTP enters the Wait-for-Red-Part-Reception
state (WAIT_RP_REC). In all cases the internal procedure Start RS
Timer [Sec 5.3] is followed upon receiving link-state cues
indicating beginning of transmission of the previous messages in RS segments.

In the
session). Such attacks are likely in RCV_GP state, if the presence of firewall
failures at various nodes in received green data segment was not
marked EOB, the network, or due receiver LTP returns to Trojan
software running on an authorized host.

Many message insertion attacks will depend on the attacker
correctly "guessing" something about DS_REC state.
Otherwise it enters the WAIT_RP_REC state to receive the red-part
of the block fully.

A previously set RS timer may expire asynchronously while the
receiver LTP peers,
but experience shows that successful guesses are easier than might
be thought [DDJ].

13.1 Security Mechanisms and Layering Considerations

In this section we consider was in the appropriate layer(s) DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC
states. If so, the internal procedure Retransmit RS [Sec 5.8] is
followed as illustrated in the states beginning at which
security mechanisms can best be deployed to increase the security
properties RX marker
(shown in the second part 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 the diagram) before returning to the
interrupted state:

Ramadas et al. Expires - January June 2005 [Page 59] 39]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

well provide sufficient data integrity and ought

A check is made here to see if the retransmission limit set by
the network management has been exceeded in the number of RSs
sent in the session. If so, a CR segment with reason-code RLEXC
SHOULD be able to
provide data confidentiality.

The LTP layer

An authentication header (similar sent to IPSEC [AH]) can help
protect against replay attacks and other bogus packets.
However, an adversary may still see the sender LTP header and the sequence following the
CX marker is followed. Otherwise, the RS is queued for
retransmission and the associated RS timer is started following
the internal procedure Start RS Timer [Sec 5.3] upon receiving
a link-state cue indicating the beginning of its transmission.

The receiver LTP may also receive RA segments
passing by from the sender in
response to the ether. This approach also requires some key
management infrastructure RSs sent while in the DS_REC state. If so, then
the RS timer corresponding to be the report serial number mentioned
in place the RA segment is canceled following the internal procedure
Stop RS Timer [Sec 5.14].

The receiver LTP stays in order the WAIT_RP_REC state until the entire
red-part of the block is received, and moves to provide
strong authentication, which may not always be an acceptable
overhead. Such an authentication header could mitigate against
many DoS attacks.

Similarly, the CLOSED state
upon full red-part reception. In this state, a confidentiality service could be defined for LTP
payload check is made upon
reception of every red-part DS to see if it is at a block offset
higher than any green-part DS received. If so, the Handle
Miscolored Segment internal procedure [Sec 5.21] is invoked and (some) header fields. However, this seems less
attractive since (a) confidentiality
the sequence of state transitions beginning with the CX marker is arguably better
provided either above
followed; a CX segment with reason-code MISCOLORED SHOULD be sent
to the sender LTP with the Cancellation sequence beginning with
the CX marker.

Note that if there were no red data segments received in the
session yet, including the case where the session was indeed fully
green or below the LTP layer, (b) key
management for such a service pathological case where the entire red-part of the
block gets lost but at least the green data segment marked EOB is harder (in a high-delay
context) than for an integrity service, and (c) forcing
received (the receiver LTP
engines to attempt decryption has no indication of incoming segments can in
itself provide whether the
session had a DoS opportunity.

Further, within red-part transmission), the receiver LTP layer we can make various design
decisions assumes the
"RP rcvd. fully" condition to be true and moves to reduce the probability of successful DoS attacks. CLOSED
state from the WAIT_RP_REC state.

In particular, we can mandate that values for certain fields in the header (session numbers, for 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 service provided is not required for
all WAIT_RP_REC state, the receiver LTP sessions, may receive the
retransmitted red data segments. Upon receiving red data segments
marked CP, it queues the responding RS for example) and loss of flexibility.
However, transmission based on
either internal procedure Retransmit RS [Sec 5.8] or Send
Reception Report [Sec 5.11] depending on whether the lower layers may well CP was found
to be a retransmission or not, respectively. The Start RS Timer
internal procedure is invoked upon receiving a link-state cue
indicating the optimal place to do
compression and encryption.

13.2 Denial beginning of Service Considerations

Implementers SHOULD consider the likelihood transmission of the following DoS
attacks :

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

Various acknowledgment segments (RA, RS, etc.) could be
deleted, causing timers RS. If an RA
segment is received, the RS timer corresponding to expire, the report
segment mentioned is canceled and has the potential to
disable communication altogether if done with a knowledge receiver LTP stays in the
state until the entire red-part is received.

In the sequence of state transitions beginning at the communications schedule. This could be achieved either by

Burleigh CX marker,

Ramadas et al. Expires - January June 2005 [Page 60] 40]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

mounting a DoS attack

the CR segment with the given reason-code (depending on a lower layer service in order to
prevent it how the
sequence is entered) is queued for transmission, and the CR timer
is started upon reception of the link-state cue indicating actual
transmission following internal procedure Start Cancel Timer [Sec
5.15]. If the CAR is received from sending an acknowledgment segment, or the sender LTP, the receiver
LTP returns to the CLOSED state (via the Cncld marker) following
the Stop Cancel Timer internal procedure [Sec 5.18]. If the CR
timer expires asynchronously, the internal procedure Retransmit
Cancellation Segment [Sec 5.16] is followed :
A check is made to see if the retransmission limit set by simply
jamming the transmission (all
network management for the number of which are more likely CRs per session has been
exceeded. If so, the receiver LTP returns to the CLOSED state
following the Cncld marker. Otherwise, a CR segment is
scheduled for
terrestrial applications retransmission with the CR timer being started
following the internal procedure Start Cancel Timer [Sec 5.15]
upon reception of LTP).

An attacker a link-state cue indicating actual
transmission.

<<Talk about 2 MSL here??>> The receiver LTP might also flip some bits, which receive a
retransmitted CS at the CLOSED state (either if the CAS segment
previously transmitted was lost or if the CS timer expired
prematurely at the sender LTP). In such a case the CAS is tantamount
scheduled for retransmission.

Asynchronous cancel requests are handled similar to
deleting that segment.

An attacker may flood the way they
are handled in the sender LTP. If the cancel request was made from
the local client service instance and the receiver LTP was not
already in the CR_SENT state, a node CR with segments for reason-code CNCLD SHOULD
be sent to the internal
operations queue [Sec 6.2] and prevent transmission sender LTP following the sequence of
legitimate data segments.

An attacker could attempt to fill up state
transitions beginning at the storage in CX marker as described above. If the
asynchronous cancel request is received from the sender LTP, a node by
sending many large messages CAS
segment is sent and the receiver LTP moves to it. In terrestrial the CLOSED state
(independent of the state the receiver LTP
applications this may be much more serious since spotting in).

8. Requirements from the
additional traffic may not be possible Operating Environment

LTP requires support from any its operating environment (which
includes network management point.

<<More TBD>> activities) and link-state cues from
the data-link layer for its operations.

The local data-link layer needs to inform LTP includes whenever the following anti-DoS mechanisms:

Session numbers MUST be partly random making it harder link to
insert valid segments.

A node which suspects that either it or its peer
a specific LTP destination is under DoS
attack could frequently checkpoint its data segments (if it
were the sender) brought up or send asynchronous RSs (if torn down. Similarly,
the operating environment needs to inform the local LTP engine
whenever it were is known that a remote LTP engine is set to begin or
stop communication with the local engine based on the
receiver), thus eliciting an earlier response operating
schedules. LTP requires link state cues from its peer or
timing out earlier due to the failure datalink layer
upon transmission of an attacker to
respond.

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

An authentication header as defined in Section 13.3.

Replay handling as defined in Section 13.5.

13.3 LTP Authentication

The the CP, RS, EORP, EOB, and Cx segments. LTP Authentication mechanism MAY
also needs to be used able to provide
cryptographic authentication of query the segment.

Implementations MAY support this extension field. If they do not

Burleigh current distance (in light

Ramadas et al. Expires - January June 2005 [Page 61] 41]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

support

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 to the LTP
engine for its operations. The exact details of the MIB are,
however, beyond the scope of this header then they MUST ignore it. document.

The underlying data-link layer is required to never deliver
incompletely received LTP segments to LTP. In the absence of the
use of LTP authentication extension field has extension tag value
0x00.

<<Check [LTPEXT] 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.

9. Security Considerations

<<Note : The LTP-Auth security mechanism defined in [LTPEXT] may
be moved back into this section if there was community consensus
in having it as a critical feature that ignoring is ok for ought to be implemented in
all cases implementations of response
generation.>>

LTP authentication requires three new fields, the first two of
which are carried protocol.>>

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

Hence there is 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 SDNV-8 whose value MUST contain a key identifier, the
interpretation of which is out of scope potential requirement for this specification
(that is, implementers MUST treat these KeyID fields as raw
octets, even if they contained an ASN.1 DER encoding confidentiality,
integrity and anti-DoS (Denial of an
X.509 IssuerSerial construct [PKIXPROF], Service) security services and
mechanisms.

In particular, DoS problems are more severe for example.

The fields MUST 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 present in the first segment 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
session which uses receiver.

To give a terrestrial example - were LTP authentication, but MAY to be omitted from
subsequent segments used in that session. To guard against additional
problems arising from lost segments, implementations SHOULD, where
bandwidth allows, include these fields a sparse
sensor network, DoS attacks could be mounted resulting in nodes
missing critical information, for example, communications schedule
updates. In such cases, a number of segments in
the LTP session.

The field carried as single successful DoS attack could take
a trailer extension is node entirely off the AuthVal field. It
contains network until the authentication value, which is either a MAC or a
digital signature. This node is itself a structured field whose length physically
visited and formatting depends on the ciphersuite.

We define three ciphersuites in this specification. Our approach
here is to "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 reset.

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

The OriginAuth ciphersuite involves generating a message
authentication code (MAC) over the LTP segment and appending
the resulting AuthVal field to the end of the segment. There is
only one MACing algorithm defined - Specification December 2004

Even for this which is HMAC-
SHA1-80 [HMAC]. The AuthVal field in this case contains just
the output deep space applications of the HMAC-SHA1-80 algorithm which is a fixed width
field (10 octets).

<<Need to check if this is still the best HMAC variant to pick
- and whether LTP, we do need to truncate and so allow consider
certain terrestrial attacks, in particular those involving
insertion of messages into an on-going session (usually without
having seen the extra bits for key
mgt. later on.>>

2. Signature Ciphersuite

The Signature ciphersuite involves generating a digital
signature exact bytes of the LTP segment and appending previous messages in the resulting
AuthVal field to
session). Such attacks are likely in the end presence of firewall
failures at various nodes in the segment. There is only one
signature algorithm defined for this which is RSA with SHA1
[RSA]. Since the length of an RSA signature depends network, or due to Trojan
software running on an authorized host.

Many message insertion attacks will depend 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 attacker
correctly "guessing" something about the digital signature
in bits. So state of the AuthVal field in LTP peers,
but experience shows that successful guesses are easier than might
be thought [DDJ].

9.1 Security Mechanisms and Layering Considerations

In this case is as follows (where section we consider the signature value occupies appropriate layer(s) at which
security mechanisms can best be deployed to increase the minimum number security
properties of octets, e.g.
128 octets for a 1024 bit signature).

Clearly, the KeyID field in this case MUST be 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
well provide sufficient data integrity and ought to be able to
provide data confidentiality.

The LTP layer

An authentication header (similar to
securely identify IPSEC [AH]) can help
protect against replay attacks and other bogus packets.
However, an adversary may still see the LTP header of segments
passing by in the public ether. This approach also requires some key usable
management infrastructure to verify the
signature.

3. NULL Ciphersuite

<<It is probably debatable whether it is better be in place in order to include this
or not. A purist crypto position would probably provide
strong authentication, which may not always be "just allow
a CRC if that's what you want", an acceptable
overhead. Such an authentication header could mitigate many DoS
attacks.

Similarly, a more code-centric position
might confidentiality service could be "I have working HMAC code, why not use that?". So defined for LTP
payload and (some) header fields. However, this
ciphersuite may well change seems less
attractive since (a) confidentiality is arguably better
provided either above or disappear as below the document
progresses.>>

The NULL ciphersuite LTP layer, (b) key
management for such a service is basically the same as the OriginAuth
ciphersuite, but with harder (in a hardcoded key. This ciphersuite
effectively provides only data high-delay
context) than for an integrity without
authentication, service, and thus is subject (c) forcing LTP
engines to active attacks and is

Burleigh attempt decryption of incoming segments can in
itself provide a DoS opportunity.

Further, within the LTP layer we can make various design

Ramadas et al. Expires - January June 2005 [Page 63] 43]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

decisions to reduce the equivalent probability of providing a CRC.

The hardcoded key to be used with this ciphersuite is successful DoS attacks.
In particular, we can mandate that values for certain fields in
the
following:

HMAC_KEY : c37b7e64 92584340
: bed12207 80894115
: 5068f738
<<The above header (session numbers, for example) be chosen randomly.

The Datalink layer (below-LTP)

In each case lower layers may well be the bytes which are input optimal place to the cryptographic
algorithm consist do
compression and encryption.

9.2 Denial of Service Considerations

Implementers SHOULD consider the entire LTP segment except the AuthVal. In
particular the header extensions field which may contain likelihood of the
ciphersuite number following DoS
attacks :

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

Various acknowledgment segments (RA, RS, etc.) could be
deleted, causing timers to expire, and has the KeyID field are part potential to
disable communication altogether if done with a knowledge of
the input.

The output bytes communications schedule. This could be achieved either by
mounting a DoS attack on a lower layer service in order to
prevent it from sending an acknowledgment segment, or by simply
jamming the transmission (all of the cryptographic operation which are the payload more likely for
terrestrial applications 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 LTP).

An attacker might also flip some bits, which is too long when compared
with the overall segment length.

Implementations SHOULD check tantamount to
deleting that SDNV values are within
suitable ranges where possible, e.g. <<TBD>>

Byte ranges

Various report and other segment.

An attacker may flood a node with segments contain offset and length
fields. Implementations MUST ensure that these are consistent for the internal
operations queue and sane.

Randomness

Various fields prevent transmission of legitimate data
segments.

An attacker could attempt to fill up the storage in a node by
sending many large messages to it. In terrestrial LTP (e.g. serial numbers) should
applications this may be
initialized using random values. Good sources of randomness
which are much more serious since spotting the
additional traffic may not easily guessable SHOULD be used [ECS94]. The
collision of possible from any network
management point.

<<More TBD>>

LTP includes the following anti-DoS mechanisms:

Session numbers MUST be partly random values is subject making it harder to the birthday paradox,

Ramadas et al. Expires - June 2005 [Page 44]
Internet Draft LTP - Specification December 2004

insert valid segments.

A node which means suspects that a collision either it or its peer is likely after roughly under DoS
attack could frequently checkpoint its data segments (if it
were the
square-root of sender) or send asynchronous RSs (if it were the space has been seen (e.g. 2^16 in
receiver), thus eliciting an earlier response from its peer or
timing out earlier due to the case failure of a 32-bit random value). Implementers an attacker to
respond.

Serial numbers (checkpoint serial numbers, report serial
numbers) MUST ensure that they
use sufficiently long begin each session anew using 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 numbers
rather than from 0.

The authentication header [LTPEXT].

9.3 Replay handling 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 against a cache for replay.
If this algorithm is that receiving a totally bogus
segment still results in a replay cache search segment and attempted LTP
decode operation. Its not clear that it is possible to do much
better though, since all an attacker would have to do to get past
the replay cache would be to tweak if a single bit in the inbound
segment each time, which pre-cooked response is certainly cheaper than the
hash+lookup+decode combination, though also certainly more
expensive than simply sending
available (stored from the same octets many times.

The benefit of doing last time this segment was processed),
then send the pre-cooked response. If there is that implementers no longer need to
analyze many bugs/attacks based on replaying packets, which in
combination with the use of LTP authentication should defeat many
attempted DoS attacks.

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 pre-cooked
response then silently drop the
CCSDS File Delivery Protocol (CFDP) specification, minus inbound segment. This can all
features that are specific be
done without attempting to operations on files and filestores
(file systems); in decode 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 buffer.

2. If the DTN Bundling protocol. (Bundling in effect implements inbound segment does not decode correctly, then silently
drop the
CFDP "extended procedures" in a more robust and scalable manner
than is prescribed by segment. If the CFDP standard.) The fundamental
difference is that, while CFDP delivers named files end-to-end,
LTP is used segment decodes properly, then add its
hash to transmit arbitrary, unnamed blocks of data point-
to-point.

Some differences between LTP the replay cache and CFDP are simply matters of
terminology; return a handle to the entry.

3. For those cases where a pre-cooked response should be stored,
store the following table summarizes response using the correspondences in
language between handle received from the two.

--------------LTP------------- ------------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 previous
step. These cases include:

(a) when the inbound packet is implemented in LTP by a CP DS the Request flag in response RS gets
stored as pre-cooked;

(b) when the EOB data segment, which triggers reception reporting upon
receipt of incoming packet is an RS the EOB.

"Prompted" mode RA is implemented in LTP by turning on Request
flags in data segments that precede stored as
precooked, and,

(c) when the EOB; these additional
checkpoints trigger interim reception reporting under incoming packet is a Cx the
control of CAx gets stored
precooked.

4. Occasionally clean out the source LTP engine.

"Asynchronous" mode is implemented replay cache - how frequently this
happens in LTP by the autonomous
production, under locally specified conditions, of additional
reception reports prior to arrival an implementation issue.

The downside of the EOB.

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

Burleigh receiving a totally bogus

Ramadas et al. Expires - January June 2005 [Page 66] 45]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

reporting is detection of a gap

segment still results in the incoming data.

CFDP uses a cyclic timer to iterate reception reporting until
reception replay cache search and attempted LTP
decode operation. It is complete. Because choosing a suitable interval for
such not clear that it is possible to do much
better though, since all an attacker would have to do to get past
the replay cache would be to tweak a timer single bit in the inbound
segment each time, which is potentially quite difficult, LTP instead flags certainly cheaper than the
last data segment of each retransmission as a checkpoint, sent
reliably;
hash+lookup+decode combination, though also certainly more
expensive than simply sending the cascading reliable transmission same octets many times.

The benefit of checkpoint and RS
segments assures doing this is that implementers no longer need to
analyze many bugs/attacks based on replaying packets, which in
combination with the continuous progress use of the transmission
session.

CFDP's Suspend and Resume PDUs are functionally displaced in LTP
by deferred transmission authentication should defeat many
attempted DoS attacks.

9.4 Implementation Considerations

SDNV

Implementations SHOULD make sanity checks on SDNV length fields
and automated bandwidth management.

As the following table indicates, most of SHOULD check that no SDNV field is too long when compared
with the functions of CFDP
PDUs overall segment length.

Implementations SHOULD check that SDNV values are accomplished in some way by LTP segments.

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

Data within
suitable ranges where possible, e.g. <<TBD>>

Byte ranges

Various report and other segments File data contain offset 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 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 length
fields. Implementations MUST ensure that these are consistent
and sane.

Randomness

Various fields in an IPN
architecture they will likely LTP (e.g. serial numbers) should be implemented elsewhere. CFDP's
EOF (Filestore error) and Finished (Filestore error) PDUs would
initialized using random values. Good sources of randomness
which are not easily guessable SHOULD be
implemented in an IPN application-layer file transfer protocol,
e.g., CFDP itself. CFDP's Finished [End System] PDU used [ECS94]. The
collision of random values is subject to the birthday paradox,
which means that a feature collision is likely after roughly the
square-root of the Extended Procedures, which would space has been seen (e.g. 2^16 in effect be implemented
by the Bundling protocol.

15. case
of a 32-bit random value). Implementers MUST ensure that they
use sufficiently long random values so that the birthday
paradox doesn't cause a problem in their environment.

10. IANA Considerations

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
port number. <<Considering this is TBD>>

Ramadas et al. Expires - January June 2005 [Page 67] 46]
Internet Draft Licklider Transmission Protocol July LTP - Specification December 2004

port number. <<Considering this is TBD>>

16.

11. Acknowledgments

Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian
Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss
for their thoughts on this protocol and its role in Delay-Tolerant
Networking architecture.

Part of the research described in this document was carried out at
the Jet Propulsion laboratory, California Institute of Technology,
under a contract with the National Aeronautics and Space
Administration. This work was performed under DOD Contract DAA-
B07- 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO
H870; and NASA Contract NAS7-1407. This work was performed under
DOD Contract DAA-B07-00-CC201, DARPA AO H912; JPL Task Plan No.
80-5045, DARPA AO H870; and NASA Contract NAS7-1407.

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

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.

17.

12. References

17.1

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

[LTPMOTIVE] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider
Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp-
motivation-00.txt (Work in Progress), December 2004.

[LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider
Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp-
extensions-00.txt (Work in Progress), December 2004.

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

[DDJ] I. Goldberg and E. Wagner, "Randomness and the Netscape
Browser", Dr. Dobb's Journal, 1996, (pages 66-70).

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

Ramadas et al. Expires - June 2005 [Page 47]
Internet Draft LTP - Specification December 2004

[BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification",
Work in Progress, October 2003.

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

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

[TFRC] M. Handley, S. Floyd, J. Padhye, and J. 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.

[ECS94] D. Eastlake, S. Crocker, and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.

18.

13. Author's Addresses

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

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.

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

Ramadas et al. Expires - June 2005 [Page 48]
Internet Draft LTP - Specification December 2004

"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

Ramadas et al. Expires - January June 2005 [Page 70] 49]
----