WDIFF

draft-irtf-dtnrg-ltp-05.txt --> draft-irtf-dtnrg-ltp-06.txt

Delay Tolerant Networking Research Group M. Ramadas
Internet Draft Ohio University
<draft-irtf-dtnrg-ltp-05.txt>
Intended Status: Experimental S. Burleigh
September 2006
<draft-irtf-dtnrg-ltp-06.txt> NASA/Jet Propulsion Laboratory
Expires March
April 2007 S. Farrell
Expires October 2007 Trinity College Dublin

Licklider Transmission Protocol - Specification

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

This Internet-Draft will expire on March October 1, 2007.

Abstract

This document describes the Licklider Transmission Protocol (LTP) (LTP),
designed to provide retransmission-based reliability over links
characterized by extremely long message round-trip times (RTTs)
and/or frequent interruptions in connectivity. Since communication
across interplanetary space is the most prominent example of this
sort of environment, LTP is principally aimed at supporting "long-

Ramadas et al. Expires - March October 2007 [Page 1]

Internet Draft LTP - Specification September 2006 April 2007

sort of environment, LTP is principally aimed at supporting "long-
haul" reliable transmission in interplanetary space, but it has
applications in other environments as well.

In an Interplanetary Internet setting deploying the Bundling Bundle 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. It is
stateful, and has no negotiation or handshakes.

This document is a product of the Delay Tolerant Networking Research
Group and has been reviewed by that group. No objections to its
publication as an RFC were raised.

Table of Contents

1. Introduction ................................................. 3
2. Terminology .................................................. 3
3. Segment Structure ............................................ 8
3.1 Segment Header ........................................... 9
3.1.1 Segment Type Flags .................................. 10
3.1.2 Segment Type Codes .................................. 10
3.1.3 Segment Class Masks ................................. 11
3.1.4 Extensions Field .................................... 12
3.2 Segment Content .......................................... 13
3.2.1 Data Segment ........................................ 13
3.2.2 Report Segment ...................................... 14
3.2.3 Report Acknowledgment Segment ....................... 16
3.2.4 Session Management Segments ......................... 16
3.3 Segment Trailer .......................................... 17
4. Requests from Client Service ................................. 17
4.1 Transmission Request ..................................... 17
4.2 Cancellation Request ..................................... 18
5. Requirements from the Operating Environment .................. 42
6. Internal Procedures .......................................... 19
5.1
6.1 Start Transmission ....................................... 19
5.2
6.2 Start Checkpoint Timer ................................... 20
5.3
6.3 Start RS Timer ........................................... 20
5.4
6.4 Stop Transmission ........................................ 20
5.5
6.5 Suspend Timers ........................................... 20
5.6
6.6 Resume Timers ............................................ 21
5.7
6.7 Retransmit Checkpoint .................................... 22
5.8
6.8 Retransmit RS ............................................ 22
5.9
6.9 Signify Red-Part Reception ............................... 23
5.10
6.10 Signify Green-Part Segment Arrival ...................... 23
5.11
6.11 Send Reception Report ................................... 23
5.12
6.12 Signify Transmission Completion ......................... 25
5.13 Retransmit Data ......................................... 25
5.14 Stop RS Timer ........................................... 26

Ramadas et al. Expires - March October 2007 [Page 2]

Internet Draft LTP - Specification September 2006

5.15 April 2007

6.13 Retransmit Data ......................................... 25
6.14 Stop RS Timer ........................................... 26
6.15 Start Cancel Timer ...................................... 26
5.16
6.16 Retransmit Cancellation Segment ......................... 26
5.17
6.17 Acknowledge Cancellation ................................ 27
5.18
6.18 Stop Cancel Timer ....................................... 27
5.19
6.19 Cancel Session .......................................... 28
5.20
6.20 Close Session ........................................... 28
5.21
6.21 Handle Miscolored Segment ............................... 28
5.22
6.22 Handling System Error Conditions ........................ 29
6.
7. Notices to Client Service .................................... 29
6.1
7.1 Session Start ............................................. 29
6.2
7.2 Green-Part Segment Arrival ................................ 29
6.3
7.3 Red-Part Reception ........................................ 30
6.4
7.4 Transmission-Session Completion ........................... 30
6.5
7.5 Transmission-Session Cancellation ......................... 30
6.6
7.6 Reception-Session Cancellation ............................ 31
6.7
7.7 Initial-Transmission Completion ........................... 31
7.
8. State Transition Diagrams ..................................... 31
7.1
8.1 Sender .................................................... 33
7.2
8.2 Receiver .................................................. 38
8. Requirements from the Operating Environment ................... 42
9. Security Considerations ....................................... 43
9.1 Security Mechanisms and Layering Considerations ........... 44
9.2 Denial of Service Considerations .......................... 45
9.3
9.2 Replay Handling ........................................... 46
9.4
9.3 Implementation Considerations ............................. 47
10. IANA Considerations .......................................... 47
11. Acknowledgments .............................................. 48
12. References ................................................... 48
12.1 Normative References ..................................... 48
12.2 Informative References ................................... 48
13. Author's Addresses ........................................... 49

1. Introduction

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

This document serves as the main protocol specification of LTP, LTP and is
part of a series of documents describing LTP. Other documents in
this series include the motivation document [LTPMTV] and the protocol
extensions document [LTPEXT] respectively. [LTPEXT]. We strongly recommend reading the
protocol motivation document before reading the following document,

Ramadas et al. Expires - March October 2007 [Page 3]

Internet Draft LTP - Specification September 2006

following document April 2007

to establish sufficient background and motivation for the contents that follow in this document.
specification.

2. Terminology

(1) Engine ID

A number that uniquely identifies a given LTP engine, within some
closed set of communicating LTP engines. Note that when LTP is
operating underneath the DTN Bundling Bundle protocol [BP][DTN], 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.

(2) Block

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

Any subset of a block comprising contiguous octets that begins beginning at the
start of the block is termed a "block prefix" and any such subset of
the block that ends ending with the end of the block is termed a "block
suffix".

(3) Red-Part

The block prefix that is to be transmitted reliably, i.e., subject to
acknowledgment and retransmission.

(4) Green-Part

The block suffix that is to be transmitted unreliably, i.e., not
subject to acknowledgments or retransmissions. If present, the green-
part
green-part of a block begins at the octet following the end of the red-
part.
red-part.

(5) Session

A thread of LTP protocol activity conducted between two peer engines
for the purpose of transmitting a block. Data flow in a Session is
uni-directional: data traffic flows from the sending peer to the
receiving peer, while data-acknowledgment traffic flows from the
receiving peer to the sending peer.

(6) Sender

The data sending peer of a Session.

Ramadas et al. Expires - October 2007 [Page 4]

Internet Draft LTP - Specification April 2007

(7) Receiver

The data receiving peer of a Session.

(8) Client Service Instance

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

(9) Segment

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

Ramadas et al. Expires - March 2007 [Page 4]

Internet Draft LTP - Specification September 2006

acknowledgment cancel-acknowledgment segment.

(7)

(10) Reception Claim

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

(8)
received (beginning at the offset).

(11) Scope

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

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

For a report segment, upper bound is the end of the block prefix to
which the reception claims in the report apply, while lower bound is
the end of the (smaller) interior block prefix to which the reception
claims in the report do *not* apply. That is, data at any offset
equal to or greater than the report's lower bound but less than its
upper bound and not designated as "received" by any of the 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 an upper bound of 5000, and the reception claims
indicated reception of data within offsets 1000-1999 and 3000-4999,
data within the block offsets 2000-2999 can be considered missing and
eligible for retransmission.

Reception reports (which may comprise multiple report segments)

Ramadas et al. Expires - October 2007 [Page 5]

Internet Draft LTP - Specification April 2007

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

(9) 6.11.

(12) End of Block (EOB)

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

(10)

(13) End of Red-Part (EORP)

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

Ramadas et al. Expires - March 2007 [Page 5]

Internet Draft LTP - Specification September 2006
of the block's red-part (in octets).

(11)

(14) Checkpoint

A data segment soliciting a reception report from the receiving LTP
engine. The EORP segment must be flagged as a checkpoint, as must
the last segment of any retransmission; these are "mandatory
checkpoints". All other checkpoints are "discretionary checkpoints".

(12)

(15) Reception Report

A sequence of one or more report segments reporting on all block data
reception within some scope.

(13)

(16) Synchronous Reception Report

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

(14)

(17) Asynchronous Reception Report

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

(15)

(18) Primary Reception Report

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

(16)

(19) Secondary Reception Report

Ramadas et al. Expires - October 2007 [Page 6]

Internet Draft LTP - Specification April 2007

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

(17)

(20) 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.

The SDNV encoding scheme is modeled after the Abstract Syntax

Ramadas et al. Expires - March 2007 [Page 6]

Internet Draft LTP - Specification September 2006
Notation One [ASN1] scheme for encoding Object Identifier Values. In
a data field encoded as an SDNV, the most significant bit (MSB) of
each octet of the SDNV serves to indicate whether the octet is the
last octet of the SDNV or not. The An octet with an MSB of 1 indicates
that it is either the first or a middle octet of the a multi-octet SDNV;
the octet with an MSB of 0 is the last octet of the SDNV. The value
encoded in an SDNV is found by concatenating the 7 least significant
bits of each octet of the SDNV, beginning at the first octet and
ending at the last octet.

The following examples illustrate the encoding scheme for various
hexadecimal values.

0xABC : 1010 1011 1100
is encoded as

{100 1010 1} {0 011 1100}
- -

= 10010101 00111100

0x1234 : 0001 0010 0011 0100
= 1 0010 0011 0100
is encoded as

{10 1 0010 0} {0 011 0100}
- -

= 10100100 00110100

0x4234 : 0100 0010 0011 0100
=100 0010 0011 0100
is encoded as

Ramadas et al. Expires - October 2007 [Page 7]

Internet Draft LTP - Specification April 2007

{1000000 1} {1 00 0010 0} {0 011 0100}
- - -

= 10000001 10000100 00110100

0x7F : 0111 1111
=111 1111
is encoded as

{0 111 1111}
-

= 01111111

Note :

Care must be taken to make sure that the value to be encoded is
padded with zeroes at the most significant bit end (NOT at the
least significant bit end) to make its bitwise length a multiple
of 7 before encoding.

While there is no theoretical limit on the size of an SDNV field,
we note that the overhead of the SDNV scheme is 1:7, i.e., one bit
of overhead for every 7 bits of actual data to be encoded. Thus a
7-octet value (a 56-bit quantity with no leading zeroes) would be
encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity

Ramadas et al. Expires - March 2007 [Page 7]

Internet Draft LTP - Specification September 2006
with no leading zeroes) would be encoded in a 10-octet SDNV. In
general, an N-bit quantity with no leading zeroes would be encoded
in a ceil(N/7) octet SDNV, where ceil is the integer ceiling
function. Clearly, for fields that typically carry larger values
such as RSA public keys, the SDNV overhead could become
unacceptable. Hence for when adopting the above SDNV scheme in for other
places
purposes related to this document document, such as any protocol
extensions, we RECOMMEND that if the typical data field value is
expected to be larger than 8 octets, octets then the data field should be
specified as a {LENGTH, VALUE} tuple tuple, with the LENGTH parameter
encoded as an SDNV, SDNV followed by LENGTH octets housing the VALUE parameter as is. of
the data field.

We also note that SDNV is clearly not the best way to represent
every numeric value. When the maximum possible value of a number
is known without question, the cost of additional bits may not be
justified. For example, an SDNV is a poor way to represent an
integer whose value typically falls in the range 128 to 255. In
general, though, we believe that the SDNV representation of
various protocol data fields in LTP segments yields the smallest
segment sizes without sacrificing scalability.

(18) Client Service Instance

A software entity, such as an application or a higher-layer protocol
implementation, that is using

Ramadas et al. Expires - October 2007 [Page 8]

Internet Draft LTP to transfer data. - Specification April 2007

3. Segment Structure

Each LTP segment comprises

(a) a "header" in the format defined below.

(b) zero or more octets of "content".

LTP segments are of four general types depending on the nature of the
content carried:

Data segments flow from the Sender to the Receiver and 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 flows from the Receiver to the Sender and carries
data reception claims together with the upper and lower bounds of
the data block scope to which the claims pertain.

Ramadas et al. Expires - March 2007 [Page 8]

Internet Draft LTP - Specification September 2006

A report-acknowledgment segment flows from the Sender to the
Receiver and acknowledges reception of a report segment. It
carries only the serial number of the report being acknowledged.

Session management segments may be generated by both the Sender
and the Receiver and are of two general subtypes: sub-types: Cancellation
and Cancellation-acknowledgment. A Cancellation segment carries a single byte reason-code to initiates
session cancellation procedures at the peer and carries a single
byte reason-code to indicate the reason for the session cancellation.
Cancellation-acknowledgment segments merely acknowledge reception
of a Cancellation segment and have no content.

The overall segment structure is illustrated below :

Ramadas et al. Expires - March October 2007 [Page 9]

Internet Draft LTP - Specification September 2006 April 2007

3.1 Segment Header

An LTP segment header comprises three data items: a single-octet
control byte, a session
Control-byte, the Session ID, and an extensions the Extensions field.

Control byte

Control-byte comprises the following:

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

Segment type flags (4 bits): described below. in Section 3.1.1.

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

Session originator (SDNV): the engine ID of the LTP engine that
initiated the session. Sender.

Session number (SDNV) : Typically a random number (for anti-DoS

Ramadas et al. Expires - March October 2007 [Page 10]

Internet Draft LTP - Specification September 2006

Session number (SDNV) : Typically a random number (for anti-DoS April 2007

reasons), generated by the LTP engine identified as the session
originator. Sender.

The format and resolution of session number are matters that are
private to the session-originating engine; Sender LTP node; the only requirement imposed by
LTP is that every session initiated by an LTP engine MUST be
uniquely identified by the session ID.

The extensions Extensions field is described in Section 3.1.4.

3.1.1 Segment Type Flags

The last four bits of the control byte in the segment header are
flags that indicate the nature of the segment. In order (most
significant bit first), these flags are CTRL, EXC, Flag 1 and Flag 0.

A value of 0 in the CTRL (Control) flag identifies the segment as a
data segment while a value of 1 identifies it as a control segment.
A data segment with the EXC (Exception) flag set to 0 is a red-part
segment; a data segment with EXC set to 1 is a green-part segment.
For a control segment, having the EXC flag set to 1 indicates that
the segment pertains to session cancellation activity. Any data
segment (whether red-part or green-part) with both Flag 1 and Flag 0
set to 1 indicates EOB. Any data segment (whether red-part or green-
part)
green-part) with both Flag 1 and Flag 0 set to 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 1 indicates the end of the red-part of the block. red-part.

3.1.2 Segment Type Codes

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

CTRL EXC Flag 1 Flag 0 Code Nature of segment
---- --- ------ ------ ---- ---------------------------------------
0 0 0 0 0 Red data, NOT {Checkpoint, 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 - March 2007 [Page 11]

Internet Draft LTP - Specification September 2006

1 0 0 0 8 Report segment
1 0 0 1 9 Report-acknowledgment segment

Ramadas et al. Expires - October 2007 [Page 11]

Internet Draft LTP - Specification April 2007

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 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 the purposes of this specification, some bit patterns in the
segment type flags field correspond to "segment classes" that are
designated by mnemonics. The mnemonics are intended to evoke the
characteristics shared by all types of segments characterized by
these flag bit patterns.

CTRL EXC Flag 1 Flag 0 Mnemonic Description
---- --- ------ ------ -------- ---------------------------
0 0 - 1
-- or --
0 0 1 - CP Checkpoint

0 0 1 - EORP End of 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

1 1 - 0 Cx Cancel segment (generic)

Ramadas et al. Expires - March October 2007 [Page 12]

Internet Draft LTP - Specification September 2006

1 1 - 0 Cx Cancel segment (generic) April 2007

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

3.1.4 Extensions field

The extension extensions field enables the inclusion of zero or more functional
extensions to the basic LTP segment, each in type-length-value (TLV)
representation as explained below.

The first octet of the extensions field indicates the number of
extensions present in the segment: the high-order 4 bits indicate the
number of extension TLVs in the header (immediately following the
extensions count octet and preceding the segment's content) while the
low-order 4 bits indicate the number of extension TLVs in the trailer
(immediately following the 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 absence of any extension TLVs,
all bits of this extensions count octet MUST be set to zero.

Note that it is valid to have for header extensions to be immediately
followed by trailer extensions; for example, since a CAx segments have segment has
no contents, if both it may have header and trailer extensions were in use in a
session being cancelled, trailer extensions would immediately follow
the header followed by
trailer extensions.

Each extension consists of a one-octet tag identifying the type of
the extension, followed by a length parameter in SDNV, SDNV form, followed
by the a value of the specified length.

The diagram below illustrates the extension TLVs as they may occur in
the header or trailer.

Extension tags are assigned as follows.

Extension tag Meaning
------------- -------
0x00 LTP authentication extension [LTPEXT]
0x01 LTP cookie extension [LTPEXT]
0x02-0xBF Reserved
0xC0-0xFF Private / Experimental Use

Ramadas et al. Expires - March October 2007 [Page 13]

Internet Draft LTP - Specification September 2006

0x02-0xBF Reserved
0xC0-0xFF Private / Experimental Use April 2007

Note that since the last quarter of the extension-tag space is
reserved for experimental use, implementations should be aware that
collisions for these tags are possible.

3.2 Segment Content

3.2.1 Data Segment (DS)

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

Client service ID [SDNV]

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

Offset [SDNV]

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

Length [SDNV]

The length of the ensuing 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]

The checkpoint serial number uniquely identifies the checkpoint
among all checkpoints issued by the block sender in a session.

Ramadas et al. Expires - March 2007 [Page 14]

Internet Draft LTP - Specification September 2006
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

Ramadas et al. Expires - October 2007 [Page 14]

Internet Draft LTP - Specification April 2007

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. The checkpoint serial number MUST NOT be zero.

Report serial number [SDNV]

If the checkpoint was queued for transmission in response to the
reception of an RS [Sec 5.13], 6.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.

3.2.2 Report Segment (RS)

The content of an RS comprises one or more data reception claims,
together with the upper and lower bounds of the scope within the data
block to which the claims pertain. It also includes two serial
numbers to support efficient retransmission.

Report serial number [SDNV]

The report serial number uniquely identifies the report among all
reports issued by the block receiver Receiver in a session. The first report
issued by the receiver 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
RS 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. The report serial number MUST NOT
be zero.

Checkpoint serial number [SDNV]

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 MUST be the
checkpoint

Ramadas et al. Expires - March 2007 [Page 15]

Internet Draft LTP - Specification September 2006 serial number of the checkpoint that caused the RS to
be issued.

Ramadas et al. Expires - October 2007 [Page 15]

Internet Draft LTP - Specification April 2007

Upper bound [SDNV]

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]

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]

The number of data reception claims in this report segment.

Reception claims

Each reception claim comprises two elements: offset and length.

Offset [SDNV]

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]

The length of a reception claim indicates the number of
contiguous octets of block data starting at the indicated
offset (within the scope of the report) that have been successfully received so far. received.

Reception claims MUST conform to the following rules:

A reception claim's length shall never be less than 1 and shall
never exceed the difference between the upper and lower bounds
of the report segment.

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 and the lower
bound of the report segment shall never exceed the upper bound
of the report segment.

Ramadas et al. Expires - March 2007 [Page 16]

Internet Draft LTP - Specification September 2006

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

Ramadas et al. Expires - October 2007 [Page 16]

Internet Draft LTP - Specification April 2007

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. bytes or of any subsequent data beginning at block offset
6000.

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

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

3.2.4 Session Management Segments

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

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

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 - March October 2007 [Page 17]

Internet Draft LTP - Specification September 2006

data segment at block offset below any
red-part data segment offset. April 2007

04 SYS_CNCLD A system error condition caused
unexpected session termination.

05 RXMTCYCEXC Exceeded the Retransmission-Cycles limit

06-FF Reserved

The Cancel-acknowledgments (CAx) have no content.

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

3.3 Segment Trailer

The segment trailer consists of a sequence of from zero to 15
extension TLVs as described in Section 3.1.4 above.

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

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

Destination client service ID

Destination LTP engine ID

Client service data to send, as an array of bytes.

Length of the data to be sent.

Length of the red-part of the data. This value MUST be in the
range from zero to the total length of data to be sent.

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

Ramadas et al. Expires - March 2007 [Page 18]

Internet Draft LTP - Specification September 2006
each subdivision serving as the client service data of a single new
LTP data segment. The algorithm used for subdividing the data is a

Ramadas et al. Expires - October 2007 [Page 18]

Internet Draft LTP - Specification April 2007

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 the EOB.

Note that segment type indicates that the client service data in a
given LTP segment either is or is not in the red-part of the block.
To prevent segment type ambiguity, each data segment MUST contain
either only red-part data or only green-part data. Therefore, when
the length of the block's red-part is N, the total length of the
block is M, and N is not equal to M, the (N+1)th byte of the block
SHOULD be the first byte of client service data in a green-part data
segment. Note that this means that at the red-part boundary, LTP may
send a segment of size lesser than the link MTU size; size. For bandwidth
efficiency reasons, implementations MAY choose to instead mark the
entire segment (within which the red-part boundary falls) as red-part red-
part, causing green-part data falling within the segment also be
treated as red-part.

If the length of the block's red-part is greater than zero, then the
last data segment containing red-part data must be marked as the EORP
segment by setting the 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 a local
implementation matter) MAY additionally be marked to as a CP, and serve
as additional discretionary checkpoints [Sec 3.1.2].

All data segments are appended to the (conceptual) application data
queue bound for the destination engine, for subsequent transmission.

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

4.2 Cancellation Request

In order to request cancellation of a session, either as the sender
or as the receiver of the associated data block, the client service
must provide the session ID identifying 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 5.19] 6.19] is invoked.

Ramadas et al. Expires - March 2007 [Page 19]

Internet Draft LTP - Specification September 2006

Next, if the session is being canceled by the block sender Sender (i.e., the
session originator part of the session ID supplied in the

Ramadas et al. Expires - October 2007 [Page 19]

Internet Draft LTP - Specification April 2007

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 transmitted -
i.e., if the destination engine cannot possibly be aware of this
session - then the session is simply closed; the "Close session"
procedure [Sec 5.20] 6.20] is invoked.

Otherwise, a CS segment with reason-code USR_CNCLD 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): Receiver):

If there is no transmission queue-set bound for the block sender 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 5.20] 6.20] is invoked.

Otherwise, a CR segment with reason-code USR_CNCLD MUST be queued
for transmission to the block sender.

5. Internal Procedures

This section describes the internal procedures that are triggered by Requirements from the occurrence of various events during Operating Environment

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

The local data-link layer needs to inform LTP whenever the link to a
specific LTP
session.

Whenever destination is brought up or torn down. Similarly, the content of any of
operating environment needs to inform the fields of local LTP engine whenever
it is known that a remote LTP engine is set to begin or stop
communication with the local engine based on the engines' operating
schedules. LTP requires link state cues from the datalink layer upon
transmission of the CP, RS, EORP, EOB, and Cx segments so that timers
can be started. LTP also needs to be able to query the current
distance (in light seconds) to any peer engine in order to calculate
timeout intervals in a typical deep-space environment.

A MIB (Management Information Base) with the above parameters,
updated periodically by the local data-link layer and the operating
environment, should be made available to the LTP engine for its
operations. The details of the MIB are, however, beyond the scope of
this 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 [LTPEXT], LTP also requires the underlying

Ramadas et al. Expires - October 2007 [Page 20]

Internet Draft LTP - Specification April 2007

data-link layer to perform data integrity checking of the segments
received. Specifically, the data-link layer is expected to detect
any corrupted segments received and to silently discard them.

6. Internal Procedures

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

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

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

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

Otherwise, if the data segment contains data from the red-part of
the block, a CR with reason-code UNREACH MUST be enqueued for

Ramadas et al. Expires - March 2007 [Page 20]

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

5.1

6.1 Start Transmission

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

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

5.2

6.2 Start Checkpoint Timer

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

Response: the expected arrival time of the RS segment that will be

Ramadas et al. Expires - October 2007 [Page 21]

Internet Draft LTP - Specification April 2007

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

5.3

6.3 Start RS Timer

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

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

5.4

6.4 Stop Transmission

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

Ramadas et al. Expires - March 2007 [Page 21]

Internet Draft LTP - Specification September 2006

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.

5.5

6.5 Suspend Timers

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

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

The nominal remote engine acknowledge transmission time is computed
as the sum of the transmission time of the original segment (to which
the acknowledging segment will respond) and the one-way light time to
the remote engine, plus N seconds of "additional anticipated latency"
(AAL) encompassing anticipated transmission delays other than signal
propagation time. N is determined in an implementation-specific

Ramadas et al. Expires - October 2007 [Page 22]

Internet Draft LTP - Specification April 2007

manner. For example, when LTP is deployed in deep space vehicles,
the one-way light time to the remote engine may be very large while N
normally need only reflect
may be relatively small, covering processing and queuing delay margin; it
can delays. N
may be a network management parameter, for which 2 seconds seems to
be like
a reasonable default value. As another example, when LTP is deployed
in a terrestrial "data mule" environment, one-way light time latency
is effectively zero while N may need to be some dynamically computed
function of the data mule circulation schedule.

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

5.6

6.6 Resume Timers

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

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

Ramadas et al. Expires - March 2007 [Page 22]

Internet Draft LTP - Specification September 2006
interval is calculated as follows :

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

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

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

5.7

6.7 Retransmit Checkpoint

Ramadas et al. Expires - October 2007 [Page 23]

Internet Draft LTP - Specification April 2007

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 5.19] 6.19] is invoked, a CS with reason-code RLEXC is
appended to the (conceptual) application data queue, and a
transmission-session cancellation notice [Sec 6.5] 7.5] is sent back to
the client service that requested the transmission.

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

5.8 queue for the destination LTP engine.

6.8 Retransmit RS

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

Response: if the number of times any affected RS segment has been
queued for transmission exceeds the report retransmission limit

Ramadas et al. Expires - March 2007 [Page 23]

Internet Draft LTP - Specification September 2006
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 5.19] 6.19] is invoked, a CR segment with reason-
code RLEXC is queued for transmission to the LTP engine that
originated the session, and a reception-session cancellation notice
[Sec 6.6] 7.6] is sent to the client service identified in each of the
data segments received in this session.

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

5.9

6.9 Signify Red-Part Reception

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

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

5.10

6.10 Signify Green-Part Segment Arrival

Ramadas et al. Expires - October 2007 [Page 24]

Internet Draft LTP - Specification April 2007

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

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

5.11

6.11 Send Reception Report

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

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

Ramadas et al. Expires - March 2007 [Page 24]

Internet Draft LTP - Specification September 2006
which can be issued for any single session.

If such a limit is not reached, a reception report is issued as
follows.

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

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

If the checkpoint was itself issued in response to a report
segment, then this report is a "secondary" reception report. In
that case the lower bound of the report SHOULD be the lower bound
of the report segment to which the triggering checkpoint was
itself a response, to minimize unnecessary retransmission. Note:

Ramadas et al. Expires - October 2007 [Page 25]

Internet Draft LTP - Specification April 2007

For deployments where bandwidth economy is not critical, the lower
bound of the report MAY instead be zero.

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

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

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

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

Ramadas et al. Expires - March 2007 [Page 25]

Internet Draft LTP - Specification September 2006
unnecessary retransmission. Note: For deployments where bandwidth
economy is not critical, the lower bound of every asynchronous
reception report MAY be zero.

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

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

5.12

6.12 Signify Transmission Completion

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

Ramadas et al. Expires - October 2007 [Page 26]

Internet Draft LTP - Specification April 2007

have been successfully received. Condition (a) is signaled by
arrival of a link state cue indicating the de-queuing (for
transmission) of the EOB segment for the block. Condition (b) is
signaled by reception of an RS segment whose reception claims, taken
together with the reception claims of all other RS segments
previously received in the course of this session, indicate complete
reception of the red-part of the block.

Response: a transmission-session completion notice [Sec 6.4] 7.4] is sent
to the local client service that requested the transmission identified in associated with the segment header session, and the
session is closed: the "Close session" procedure [Sec 5.20] 6.20] is
invoked.

5.13

6.13 Retransmit Data

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

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

Ramadas et al. Expires - March 2007 [Page 26]

Internet Draft LTP - Specification September 2006

received report an RS segment for this session that has already been received and
processed -- then no further action is taken. Otherwise the
procedure below is followed.

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

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

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

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

Ramadas et al. Expires - October 2007 [Page 27]

Internet Draft LTP - Specification April 2007

session.

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

5.14

6.14 Stop RS Timer

This procedure is triggered by the reception of an RA.

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

5.15

6.15 Start Cancel Timer

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

Ramadas et al. Expires - March 2007 [Page 27]

Internet Draft LTP - Specification September 2006

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

5.16

6.16 Retransmit Cancellation Segment

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

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

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

5.17

Ramadas et al. Expires - October 2007 [Page 28]

Internet Draft LTP - Specification April 2007

6.17 Acknowledge Cancellation

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

Response: in the case of a CS segment where there is no
transmission queue-set bound for the engine that originated the
segment's session Sender (possibly because the local LTP engine
Receiver is
running on a receive-only device), then no action is taken.
Otherwise:

If the received segment is a CS segment, a CAS segment is
issued and is, in concept, appended to the queue of internal
operations traffic bound for the LTP engine that sent the CS
segment. Sender.

If the received segment is a CR segment, a CAR segment is
issued and is, in concept appended to the queue of internal
operations traffic bound for the LTP engine that sent the CR
segment. Receiver.

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

Ramadas et al. Expires - March 2007 [Page 28]

Internet Draft LTP - Specification September 2006

Otherwise: the "Cancel session" procedure [Sec 5.19] 6.19] is invoked
and a reception-session cancellation notice [Sec 6.6] 7.6] is sent to
the client service identified in each of the data segments
received in this session. Finally, the session is closed: the
"Close session" procedure [Sec 5.20] 6.20] is invoked.

5.18

6.18 Stop Cancel Timer

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

Response: the timer associated with the Cx segment is deleted, and
the session of which the segment is one token is closed, i.e., the
"Close session" procedure [Sec 5.20] 6.20] is invoked.

5.19

6.19 Cancel Session

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

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

5.20

Ramadas et al. Expires - October 2007 [Page 29]

Internet Draft LTP - Specification April 2007

6.20 Close Session

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

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

5.21

6.21 Handle Miscolored Segment

This procedure is triggered by the arrival of either (a) a red-
part data segment whose block offset begins at an offset higher
than the block offset of any green-part data segment previously
received for the same session or (b) a green-part data segment
whose block offset begins at an offset is lower than the block offset of any red-part
data segment previously received for the same session. The
arrival of a segment matching either of the above checks is a
violation of the protocol requirement of having all red-part data
as the block prefix and all green-part data as the block suffix.

Response: the received data segment is simply discarded.

The Cancel Session procedure [Sec 5.19] 6.19] is invoked and a CR
segment with reason-code MISCOLORED SHOULD be enqueued for

Ramadas et al. Expires - March 2007 [Page 29]

Internet Draft LTP - Specification September 2006
transmission to the data sender.

Note :

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

A Reception-Session Cancellation Notice [Sec 6.6] 7.6] is sent to the
client service.

5.22

6.22 Handling System Error Conditions

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

Ramadas et al. Expires - October 2007 [Page 30]

Internet Draft LTP - Specification April 2007

Under any such irrecoverable system error condition, the following
response is to be initiated: The the Cancel Session procedure [Sec
5.19]
6.19] is invoked. If the session error condition is a local sender session, observed on the
Sender, a CS segment with reason-code SYS_CNCLD SHOULD be enqueued
for transmission to the receiver, Receiver, and a Transmission-Session
Cancellation Notice [Sec 6.5] 7.5] is sent to the client service. On service; on
the other hand, if it is a local receiver session, observed on the Receiver, a CR segment
with the same reason-code SYS_CNCLD SHOULD be enqueued for
transmission to the sender, Sender, and a Reception-Session Cancellation
Notice [Sec 6.6] 7.6] is sent to the client service.

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

There may be other implementation-specific limits which may cause
an LTP implementation to initiate session-cancellation procedures.
One such limit is the maximum number of retransmission-cycles
seen. A retransmission cycle at the LTP sender Sender comprises the two
related sets of events: the transmission of all outstanding CP segments
from the sender, Sender, and the reception of all related RS segments issued from
the receiver Receiver in response to those CP segments. Similar A similar
definition would apply at the LTP receiver Receiver but relate to the
reception of the CP segments and transmission of all

Ramadas et al. Expires - March 2007 [Page 30]

Internet Draft LTP - Specification September 2006 RS segments
in response. Note that the retransmitted CP, CP and RS segments
remain part of their original retransmission-cycle. Also, a
single CP segment may cause multiple RS segments to be generated
if a Reception Report would not fit in the a single datalink-MTU-sized
RS segment; All such all RS segments issued that are part of a Reception Report
belong to the same retransmission cycle to which the CP segment
belongs. In the presence of severe channel error conditions, many retransmission-
retransmission cycles may elapse before red-part transmission is
deemed successful; an implementation may therefore impose a
retransmission-cycle limit to shield itself from a resource-crunch
situation. If a sender LTP notices the retransmission-cycle limit
being crossed, exceeded, it SHOULD initiate the Cancel Session Procedure
[Sec 5.19] 6.19], queuing a CS segment with reason-code RXMTCYCEXC and
send
sending a Transmission-Session Cancellation Notice [Sec 6.5] 7.5] to
the
client-service.

6. client service.

7. Notices to Client Service

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

6.1

7.1 Session Start

The

Ramadas et al. Expires - October 2007 [Page 31]

Internet Draft LTP engine - Specification April 2007

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

A
newly created session.

At the Sender, the session start notice informs the client service
of the initiation of a transmission session in response to a the transmission
request from that client service. session. On receiving this
notice the client service may, for example, release resources of
its own that are allocated to the block being transmitted, or
remember the session ID so that the session can be canceled in the
future if necessary.

6.2 At the Receiver, this notice indicates the
beginning of a new reception session, and is delivered upon
arrival of the first data segment carrying a new Session ID.

7.2 Green-Part Segment Arrival

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

Session ID of the transmission session.

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

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

Length of the data segment's content.

Ramadas et al. Expires - March 2007 [Page 31]

Internet Draft LTP - Specification September 2006

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

Source LTP engine ID.

6.3

7.3 Red-Part Reception

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

Session ID of the transmission session.

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

Length of the red-part of the block.

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

Source LTP engine ID.

6.4

Ramadas et al. Expires - October 2007 [Page 32]

Internet Draft LTP - Specification April 2007

7.4 Transmission-Session Completion

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

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

6.5

7.5 Transmission-Session Cancellation

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

Session ID of the transmission session.

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

A transmission-session cancellation notice informs the client
service that the indicated session was terminated, either by
decision of the destination client service instance
Receiver or else due to
violation of an error or a retransmission limit resource quench condition in
the local LTP engine. There is no assurance that the destination
client service instance

Ramadas et al. Expires - March 2007 [Page 32]

Internet Draft LTP - Specification September 2006 received the critical part any portion of the data block.

6.6

7.6 Reception-Session Cancellation

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

Session ID of the transmission session.

The reason-code explaining the cancellation.

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

6.7

7.7 Initial-Transmission Completion

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

This notice informs the client service that all segments of a

Ramadas et al. Expires - October 2007 [Page 33]

Internet Draft LTP - Specification April 2007

block (both red-part and green-part) have been transmitted. This
notice only serves to indicate indicates that original transmission is complete; retransmissions
retransmission of any lost red-part data segments may still be
necessary.

8. State Transition Diagrams

The following mnemonics have been used in the sender and
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 diagrams have been specified in two parts such that
sequence of state transitions that occur multiple times in the
main diagram have been presented in the second part.
RP Red-Part
GP Green-Part
FG Fully-Green

Note that blocks represented in rectangles rectangles, as in

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

specify actual states in the state-transition diagrams, while

Ramadas et al. Expires - March 2007 [Page 33]

Internet Draft LTP - Specification September 2006
blocks represented with jagged edges, as in

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

are not actual states but merely either pointers to a state or a sequence
of state transitions represented elsewhere in the state transition
diagram (to avoid having multiple copies of a sequence place-holders for sequences of
state
transitions, thus accommodating space constraints). transitions.

Ramadas et al. Expires - March October 2007 [Page 34]

Internet Draft LTP - Specification September 2006

7.1 April 2007

8.1 Sender
LTP Sender State Transition Diagram

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

Ramadas et al. Expires - March October 2007 [Page 35]

Internet Draft LTP - Specification September 2006 April 2007

LTP Sender State Transition Diagram (contd.)

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

Ramadas et al. Expires - March October 2007 [Page 36]

Internet Draft LTP - Specification September 2006

The sender LTP stays in the CLOSED state until receiving a Block
Transmission Request (Blk. Trans. Req) April 2007

Asynchronous cancel request may be received from the local client
service
instance. Upon receiving the request it either moves to while the Fully
Green Transmission State (FG_XMIT) if no portion sender LTP is in any of the block states shown. If it
was
requested to be transmitted as red, or moves to not already in the Red-Part
Transmission State (RP_XMIT) sequence of 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 transitions beginning at the segments are
queued for transmission to
CX marker, the remote engine. The last such segment internal procedure Cancel Session [Sec 6.19] is marked as EOB
followed, and the sender LTP returns to the CLOSED state after
queuing it for transmission.

Similarly, moves from the RP_XMIT its current state multiple red data segments are into the
sequence beginning at the CX marker initiating session cancellation
with reason-code USR_CNCLD. From the CX marker, the CS segment with
appropriate reason-code (USR_CNCLD or RLEXC depending on how the CX
sequence was entered) is queued for transmission. The sender transmission to the receiver LTP may optionally mark some of
and the red data segments as asynchronous checkpoints; sender enters the Cancel-from-Sender Sent(CS_SENT) state.
The internal procedure Start Checkpoint Cancel Timer [Sec 5.2] 6.15] is followed started upon
receiving a link-state cue indicating the actual beginning of transmission
of
such segments. The the CS segment. Upon receiving the acknowledging CAS segment from
the receiver, the sender LTP marks moves to the last red-data segment of CLOSED state (via the
block as both CP and EORP,
'Cncld' pointer). If the CS Timer expires, the internal procedure
Retransmit Cancellation Segment [Sec 6.16] is followed:

If the network management set retransmission limit is exceeded,
the session is simply closed and after queuing it for transmission
moves the sender LTP follows the Cncld
marker to the Green Part Transmission (GP_XMIT) CLOSED state. If the block
transmission was fully red retransmission limit is not
exceeded however, the last red-data CS segment is
marked as CP, EORP, and EOB queued for a retransmission
and the sender LTP moves to the Wait-for-
Red-Part-Acknowledgment (WAIT_RP_ACK) state instead. For both the
above state-transitions, stays in the internal procedure Start Checkpoint CS_SENT state. The CS Timer [Sec 5.2] is followed
started upon receiving a link-state cue indicating the beginning
of actual transmission of according to the queued CP segments.
If internal procedure Start
Cancel Timer [Sec 6.15].

Asynchronous cancel request may also be received from the sender receiver
LTP entered the GP_XMIT state, in the remaining green-part form of the block is segmented as green data segments and queued for
transmission to the receiver LTP; the last green a CR segment of the block
is additionally marked as EOB and the sender LTP moves to the
WAIT_RP_ACK state.

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

1. An RS might be received from
states. Upon receiving such a CR segment, the receiver internal procedure
Acknowledge Cancellation [Sec 6.17] is invoked: The sender LTP (either sends
a CAR segment in response and returns to a previously transmitted CP segment or sent
asynchronously for accelerated retransmission). the CLOSED state.

The sender LTP
then moves to perform stays in the sequence of CLOSED state transitions beginning
at until receiving a Block
Transmission Request (Blk. Trans. Req) from the RX marker (second-part of client service
instance. Upon receiving the diagram), and retransmits
data if necessary, illustrating request it either moves to the internal procedure Retransmit
Data [Sec 5.13]:

First, Fully
Green Transmission State (FG_XMIT) if no portion of the RS segment had block was
requested to be transmitted as red, or to the Red-Part Transmission
State (RP_XMIT) state if a non-zero CP serial number, block-prefix was requested to be
transmitted red.

In the
corresponding CP timer FG_XMIT state, the block is canceled. Then, an RA segment

Ramadas et al. Expires - March 2007 [Page 37]

Internet Draft segmented as multiple green LTP - Specification September 2006

acknowledging
data segments respecting the received RS segment is link MTU size and the segments are
queued for transmission to the receiver LTP remote engine. The last such segment
is marked as EOB and the sender LTP moves returns to the Check Report CLOSED state (CHK_RPT). If the RS segment was redundantly transmitted by after
queuing it for transmission.

Similarly, from the receiver LTP (possibly because either the last transmitted RA
segment got lost or the RS segment timer expired prematurely at
the receiver), RP_XMIT state multiple red data segments are
queued for transmission, respecting the link MTU size. The sender

Ramadas et al. Expires - October 2007 [Page 37]

Internet Draft LTP does nothing more and returns back
to the interrupted state. Similarly, if all red-data within the
scope - Specification April 2007

LTP may optionally mark some of the RS segment is reported red data segments as received, there asynchronous
checkpoints; the internal procedure Start Checkpoint Timer [Sec 6.2]
is no work
to be done and followed upon receiving a link-state cue indicating the sender LTP returns to
transmission of the interrupted state.
However, if asynchronous checkpoints. If the RS segment indicated incomplete reception of data
within its scope, block
transmission request comprises a non-zero Green Part, the sender LTP
marks the last red-data segment as CP and EORP, and after queuing it
for transmission, moves to the Red-part Retransmit
state (RP_RXMT) where missing Green Part Transmission (GP_XMIT)
state. If the block transmission request was fully red data-segments within scope are
queued for transmission. The however, the
last such red-data segment is marked as a CP, EORP, and EOB and the sender
LTP returns moves directly to the interrupted Wait-for-Red-Part-Acknowledgment
(WAIT_RP_ACK) state. The In both the above state-transitions, the
internal procedure Start Checkpoint Timer [Sec 5.2] 6.2] is followed upon
receiving a link-state cue indicating the beginning of transmission
of the queued CP segment.

2. A previously set CP timer might expire. Now the sender LTP
follows segments. In the states beginning at GP_XMIT state, the CP marker (second-part green-part of
the
diagram), block is segmented as green data segments and follows queued for
transmission to the internal procedure Retransmit Checkpoint
[Sec 5.7]:

If receiver LTP; the CP Retransmission Limit set by network management for last green segment of the
session has been exceeded, block
is additionally marked as EOB, and after queueing it for transmission
the sender LTP proceeds towards
canceling moves to the session (with reason-code RLEXC) as indicated by WAIT_RP_ACK state.

While the
sequence sender LTP is at any of state transitions following the CX marker. Otherwise
(if RP_XMIT, GP_XMIT, or
WAIT_RP_ACK states, it might be interrupted by the Retransmission Limit is not exceeded yet), occurrence of the
following events:

1. An RS might be received from the receiver LTP (either in
response to a previously transmitted CP segment
is queued or sent
asynchronously for retransmission and the accelerated retransmission). The sender LTP returns
then moves to perform the
interrupted state. The Start Checkpoint Timer internal procedure
[Sec 5.2] is started again upon receiving a link-state cue
indicating the beginning of transmission sequence of the segment.

The sender LTP stays state transitions beginning
at the WAIT_RP_ACK state after reaching it
until RX marker (second-part of the red-part diagram), and retransmits
data if necessary, illustrating the internal procedure Retransmit
Data [Sec 6.13]:

First, if the RS segment had a non-zero CP serial number, the
corresponding CP timer is fully acknowledged as canceled. Then an RA segment
acknowledging the received by RS segment is queued for transmission
to the receiver LTP, LTP and then returns the sender LTP moves to the CLOSED Check Report
state following the
internal procedure Close Session [Sec 5.20].

Note that while at the CLOSED state, (CHK_RPT). If the sender LTP might receive an RS segment (if was redundantly transmitted by
the receiver LTP (possibly because either the last transmitted RA
segment before session close got lost or if the receiver LTP retransmitted the RS segment
prematurely), in which case it retransmits an acknowledging RA
segment timer expired prematurely at
the receiver), the sender LTP does nothing more and stays in returns back
to the CLOSED interrupted state. If Similarly, if all red-data within the session was canceled by
scope of the Receiver by issuing a CR segment, RS segment is reported as received, there is no work
to be done and the receiver may retransmit sender LTP returns to the
CR segment (either prematurely or because interrupted state.
However, if the acknowledging CAR RS segment got lost). In this case, indicated incomplete reception of data
within its scope, the sender LTP retransmits moves to the
acknowledging CAR Red-part Retransmit
state (RP_RXMT) where missing red data-segments within scope are
queued for transmission. The last such segment is marked as a CP,
and stays in the CLOSED state.

Asynchronous cancel request may be received from sender LTP returns to the local client interrupted state. The internal
procedure [Sec 6.2] is followed upon receiving a link-state cue

Ramadas et al. Expires - March October 2007 [Page 38]

Internet Draft LTP - Specification September 2006

service while April 2007

indicating the beginning of transmission of the CP segment.

2. A previously set CP timer might expire. Now the sender LTP was in any of
follows the states mentioned. If
it was not already in the sequence of state transitions beginning at the CX marker, CP marker (second-part of the
diagram), and follows the internal procedure Cancel Session Retransmit Checkpoint
[Sec 5.19] is
followed, and 6.7]:

If the CP Retransmission Limit set by network management for the
session has been exceeded, the sender LTP moves from its current state into the
sequence beginning at proceeds towards
canceling the CX marker initiating session cancellation
with (with reason-code USR_CNCLD. From RLEXC) as indicated by the
sequence of state transitions following the CX marker, marker. Otherwise
(if the CS segment with
appropriate reason-code (USR_CNCLD or RLEXC depending on how Retransmission Limit is not exceeded yet), the CX
sequence was entered) CP segment
is queued for transmission to the receiver LTP retransmission and the sender enters LTP returns to the Cancel-from-Sender Sent(CS_SENT)
interrupted state. The
internal procedure Start Cancel Checkpoint Timer internal procedure
[Sec 5.15] 6.2] is started again upon receiving a link-state cue
indicating the beginning of transmission of the CS segment. Upon receiving

The sender LTP stays at the acknowledging CAS segment from WAIT_RP_ACK state after reaching it
until the receiver, red-part data is fully acknowledged as received by the sender LTP moves
receiver LTP, and then returns to the CLOSED state (via the Cncld
marker). If the CS Timer expires, following the
internal procedure Retransmit
Cancellation Segment Close Session [Sec 5.16] is followed:

If the network management set retransmission limit is exceeded, 6.20].

Note that while at the session is simply closed and CLOSED state, the sender LTP follows the Cncld
marker to might receive an
RS segment (if the CLOSED state. If last transmitted RA segment before session close
got lost or if the retransmission limit is not
exceeded however, receiver LTP retransmitted the CS RS segment
prematurely), in which case it retransmits an acknowledging RA
segment is queued for a retransmission and the sender LTP stays in the CS_SENT CLOSED state. The CS Timer is
started upon receiving a link-state cue indicating If the beginning
of actual transmission according to session was canceled
by the internal procedure Start
Cancel Timer [Sec 5.15].

Asynchronous cancel request may also be received from Receiver by issuing a CR segment, the receiver
LTP in may retransmit
the form of a CR segment when the sender LTP is in any of (either prematurely or because the
states. Upon receiving such a CR segment, acknowledging CAR
segment got lost). In this case, the internal procedure
Acknowledge Cancellation [Sec 5.17] is invoked: The sender LTP sends
a retransmits the
acknowledging CAR segment in response and returns to stays in the CLOSED state.

Ramadas et al. Expires - March October 2007 [Page 39]

Internet Draft LTP - Specification September 2006

7.2 April 2007

8.2 Receiver
LTP Receiver State Transition Diagram

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

Ramadas et al. Expires - March October 2007 [Page 40]

Internet Draft LTP - Specification September 2006 April 2007

LTP Receiver State Transition Diagram (contd.)

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

Ramadas et al. Expires - March October 2007 [Page 41]

Internet Draft LTP - Specification September 2006

The receiver LTP begins at the CLOSED state and enters April 2007

Asynchronous cancel requests are handled in a manner similar to the Data
Segment Reception
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 CR segment with reason-code
USR_CNCLD SHOULD be sent to the sender LTP following the sequence of
state transitions beginning at the CX marker as described above. If
the asynchronous cancel request is received from the sender LTP, a
CAS segment is sent and the receiver LTP moves to the CLOSED state
(independent of the state the receiver LTP may be in).

The receiver LTP begins at the CLOSED state and enters the Data
Segment Reception (DS_REC) state upon receiving the first data
segment. If the client service ID referenced in the data segment was
non-existent, a CX Cx segment with reason-code UNREACH SHOULD be sent to
the sender LTP with via the Cancellation sequence beginning with the CX
marker (second part of the diagram). If the received segment was
found to be miscolored (a red-part data segment whose block offset
begins at an offset higher than the offset of any green-part data
segment previously received, or a green-part data segment whose block
offset begins at an offset lower than the offset of any red-part data
segment previously received), miscolored, the internal procedure Handle Miscolored
Segment [Sec 5.21] 6.21] is followed; followed, and a CX segment with reason-
code reason-code
MISCOLORED SHOULD be sent to the sender LTP with the Cancellation
sequence beginning with the CX marker.

Otherwise, the receiver LTP 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 green, respectively.

In the RCV_RP state, a check is made of the nature of the received
red DS. If the segment was a regular red data segment, the receiver
LTP just returns to the DS_REC state. For red data segments marked
also as CP and as CP & EORP, a responding RS segment is queued for
transmission to the sender following either the internal procedure
Retransmit RS [Sec 5.8] 6.8] or Send Reception Report [Sec 5.11] 6.11] depending
on whether the CP segment was a retransmission (An RS segment
corresponding to the Checkpoint Serial Number in the CP segment was
previously issued) or not, respectively. The 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] 6.3] is followed
upon receiving link-state cues indicating beginning of transmission
of the RS segments.

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

A previously set RS timer may expire asynchronously while and interrupt the receiver LTP was
while in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC states. If so,

Ramadas et al. Expires - October 2007 [Page 42]

Internet Draft LTP - Specification April 2007

the internal procedure Retransmit RS [Sec 5.8] 6.8] is followed as
illustrated in the states beginning at the RX marker (shown in the
second part of the diagram) before returning to the interrupted
state:

A check is made here to see if the retransmission limit set by the

Ramadas et al. Expires - March 2007 [Page 42]

Internet Draft LTP - Specification September 2006
network management has been exceeded in the number of RSs sent in
the session. If so, a CR segment with reason-code RLEXC SHOULD be
sent to the sender LTP and the sequence following indicated by the CX marker
is followed. Otherwise, the RS segment is queued for
retransmission and the associated RS timer is started following
the internal procedure Start RS Timer [Sec 5.3] 6.3] upon receiving a
link-state cue indicating the beginning of its transmission.

The receiver LTP may also receive RA segments from the sender in
response to the RS segments sent while in the DS_REC state. If so,
then the RS timer corresponding to the report serial number mentioned
in the RA segment is canceled following the internal procedure Stop
RS Timer [Sec 5.14]. 6.14].

The receiver LTP stays in the WAIT_RP_REC state until the entire red-
part of the block is received, and moves to the CLOSED state upon
full red-part reception. In this state, a check is made upon
reception of every red-part data segment to see if it is at a block
offset higher than any green-part data segment received. If so, the
Handle Miscolored Segment internal procedure [Sec 5.21] 6.21] is invoked
and the sequence of state transitions beginning with the CX marker is
followed; a CX segment with reason-code MISCOLORED SHOULD be sent to
the 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
the pathological case where the entire red-part of the block gets
lost but at least the green data segment marked EOB is received (the
receiver LTP has no indication of whether the session had a red-part
transmission), the receiver LTP assumes the "RP rcvd. fully"
condition to be true and moves to the CLOSED state from the
WAIT_RP_REC state.

In the WAIT_RP_REC state, the receiver LTP may receive the
retransmitted red data segments. Upon receiving red data segments
marked CP, it queues the responding RS segment for transmission based
on either internal procedure Retransmit RS [Sec 5.8] 6.8] or Send
Reception Report [Sec 5.11] 6.11] depending on whether the 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 beginning of transmission of the RS segment. If an RA

Ramadas et al. Expires - October 2007 [Page 43]

Internet Draft LTP - Specification April 2007

segment is received, the RS timer corresponding to the report segment
mentioned is canceled and the receiver LTP stays in the state until
the entire red-part is received.

In the sequence of state transitions beginning at the CX marker, the
CR segment with the given reason-code (depending on how the sequence

Ramadas et al. Expires - March 2007 [Page 43]

Internet Draft LTP - Specification September 2006
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]. 6.15]. If the
CAR segment is received from 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]. 6.18]. If the CR timer expires
asynchronously, the internal procedure Retransmit Cancellation
Segment [Sec 5.16] 6.16] is followed :
A check is made to see if the retransmission limit set by the
network management for the number of CR segments per session has
been exceeded. If so, the receiver LTP returns to the CLOSED
state following the Cncld marker. Otherwise, a CR segment is
scheduled for retransmission with the CR timer being started
following the internal procedure Start Cancel Timer [Sec 5.15] 6.15]
upon reception of a link-state cue indicating actual transmission.

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

Asynchronous cancel requests are handled similar to 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 CR segment with reason-code USR_CNCLD SHOULD be
sent to the sender LTP following the sequence of state transitions
beginning at the CX marker as described above. If the asynchronous
cancel request is received from the sender LTP, a CAS segment is sent
and the receiver LTP moves to the CLOSED state (independent of the
state the receiver LTP may be in).

8. Requirements from the Operating Environment

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

The local data-link layer needs to inform LTP whenever the link to a
specific LTP destination is brought up or torn down. Similarly, the
operating environment needs to inform the local LTP engine whenever
it is known that a remote LTP engine is set to begin or stop
communication with the local engine based on the operating schedules.
LTP requires link state cues from the datalink layer upon
transmission of the CP, RS, EORP, EOB, and Cx segments. LTP also
needs to be able to query the current distance (in light seconds) to
any peer engine in order to calculate timeout intervals in a typical
deep-space environment.

Ramadas et al. Expires - March 2007 [Page 44]

Internet Draft LTP - Specification September 2006

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

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

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

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

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

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

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

Ramadas et al. Expires - March 2007 [Page 45]

Internet Draft LTP - Specification September 2006

9.1 Security Mechanisms and Layering Considerations

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

The Application layer (above-LTP)

Higher layer security mechanisms clearly protect LTP payload, but
leave LTP headers open. Such mechanisms provide little or no
protection against DoS type attacks against LTP, but may well
provide sufficient data integrity and ought to be able to provide
data confidentiality.

The LTP layer

An authentication header (similar to IPSEC [AH]) can help protect
against replay attacks and other bogus packets. However, an
adversary may still see the LTP header of segments passing by in
the ether. This approach also requires some key management
infrastructure to be in place in order to provide strong
authentication, which may not always be an acceptable overhead.
Such an authentication header could mitigate many DoS attacks.

Similarly, a confidentiality service could be defined for LTP
payload and (some) header fields. However, this seems less
attractive since (a) confidentiality is arguably better provided
either above or below the LTP layer, (b) key management for such a
service is harder (in a high-delay context) than for an integrity
service, and (c) forcing LTP engines to attempt decryption of
incoming segments can in itself provide a DoS opportunity.

Further, within the LTP layer we can make various design decisions
to reduce the probability of successful DoS attacks. In
particular, we can mandate that values for certain fields in the
header (session numbers, for example) be chosen randomly.

The Datalink layer (below-LTP)

The lower layers can clearly provide confidentiality and integrity
services, although if the CS timer expired prematurely at the sender LTP). In
such security may result in unnecessary
overhead (if a service provided case the CAS is not required for all LTP
sessions, scheduled for example) and loss of flexibility. However, the lower
layers may well be the optimal place to do compression and
encryption.

9.2 retransmission.

9. Security Considerations

9.1 Denial of Service Considerations

Ramadas et al. Expires - March 2007 [Page 46]

Internet Draft LTP - Specification September 2006

Implementers SHOULD consider the likelihood 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 to expire, and has having the potential to disable
communication altogether if done with a knowledge of the
communications schedule. This could be achieved either by
mounting a DoS attack on a lower layer service in order to prevent
it from sending an acknowledgment segment, or by simply jamming
the transmission (all of which are more likely for terrestrial
applications of LTP).

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

Ramadas et al. Expires - October 2007 [Page 44]

Internet Draft LTP - Specification April 2007

An attacker may flood a node with segments for the internal
operations queue and 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
applications this may be much more serious since spotting the
additional traffic may not be possible from any network management
point.

LTP includes the following anti-DoS mechanisms:

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

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

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

The authentication header [LTPEXT].

9.3

9.2 Replay Handling

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

Ramadas et al. Expires - March 2007 [Page 47]

Internet Draft LTP - Specification September 2006

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:

Ramadas et al. Expires - October 2007 [Page 45]

Internet Draft LTP - Specification April 2007

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

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

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

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

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

9.4

9.3 Implementation Considerations

SDNV

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

Ramadas et al. Expires - March 2007 [Page 48]

Internet Draft LTP - Specification September 2006

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

Byte ranges

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

Randomness

Various fields in LTP (e.g. serial numbers) should MUST be initialized
using random values. Good sources of randomness which are not
easily guessable SHOULD be used [ECS94]. The collision of random

Ramadas et al. Expires - October 2007 [Page 46]

Internet Draft LTP - Specification April 2007

values is subject to the birthday paradox, which means that a
collision is likely after roughly the square-root of the space has
been seen (e.g. 2^16 in the case of a 32-bit random value).
Implementers MUST ensure that they use sufficiently long random
values so that the birthday paradox doesn't cause a problem in
their environment.

10. IANA Considerations

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

11. Acknowledgments

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

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

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

Part of this work was carried out at Trinity College Dublin as part
of the SeNDT contract funded by Enterprise Ireland's research

Ramadas et al. Expires - March 2007 [Page 49]

Internet Draft LTP - Specification September 2006
innovation fund.

12. References

12.1 Normative References

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

[LTPMTV] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider
Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp-
motivation-01.txt
motivation-04.txt (Work in Progress), July 2005. April 2007.

[LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider

Ramadas et al. Expires - October 2007 [Page 47]

Internet Draft LTP - Specification April 2007

Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp-
extensions-01.txt
extensions-05.txt (Work in Progress), July 2005. April 2007.

12.2 Informative References

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

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

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

[BP] K. Scott, Scott and S. Burleigh, "Bundle Protocol Specification", Work
draft-irtf-dtnrg-bundle-spec-08.txt (Work in Progress, October 2003. Progress), December
2006.

[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".

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

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

13. Author's Addresses

Ramadas et al. Expires - March 2007 [Page 50]

Internet Draft LTP - Specification September 2006

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 301-490
Pasadena, CA 91109-8099
Telephone +1 (818) 393-3353
FAX +1 (818) 354-1075
Email Scott.Burleigh@jpl.nasa.gov

Stephen Farrell

Ramadas et al. Expires - October 2007 [Page 48]

Internet Draft LTP - Specification April 2007

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

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Ramadas et al. Expires - March 2007 [Page 51]

Internet Draft LTP - Specification September 2006

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2006). IETF Trust (2007). 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.

Ramadas et al. Expires - October 2007 [Page 49]

Internet Draft LTP - Specification April 2007

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Ramadas et al. Expires - March October 2007 [Page 52] 50]

----