Delay Tolerant Networking Research Group M. Ramadas
Internet Draft Ohio University
<draft-irtf-dtnrg-ltp-02.txt> S. Burleigh
December 2004 NASA/Jet Propulsion Laboratory
Expires June 2005 S. Farrell
Trinity College Dublin
Licklider Transmission Protocol - Specification
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and any of which we become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [B97].
Discussions on this internet-draft are being made in the Delay
Tolerant Networking Research Group (DTNRG) mailing list. More
information can be found in the DTNRG web-site at
http://www.dtnrg.org
Abstract
This document describes the Licklider Transmission Protocol (LTP)
designed to provide retransmission-based reliability over links
characterized by extremely long message round-trip times (RTTs)
Ramadas et al. Expires - June 2005 [Page 1]
Internet Draft LTP - Specification December 2004
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-
haul" reliable transmission in interplanetary space, but has
applications in other environments as well.
In an Interplanetary Internet setting deploying the Bundling protocol
being developed by the Delay Tolerant Networking Research Group, LTP
is intended to serve as a reliable convergence layer over single hop
deep-space RF links. LTP does ARQ of data transmissions by soliciting
selective-acknowledgment reception reports. It is stateful, and has
no negotiation or handshakes.
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. Internal Procedures .......................................... 19
5.1 Start Transmission ....................................... 19
5.2 Start Checkpoint Timer ................................... 19
5.3 Start RS Timer ........................................... 20
5.4 Stop Transmission ........................................ 20
5.5 Suspend Timers ........................................... 20
5.6 Resume Timers ............................................ 21
5.7 Retransmit Checkpoint .................................... 21
5.8 Retransmit RS ............................................ 22
5.9 Signify Red-Part Reception ............................... 22
5.10 Signify Green-Part Segment Arrival ...................... 22
5.11 Send Reception Report ................................... 23
5.12 Signify Transmission Completion ......................... 24
5.13 Retransmit Data ......................................... 25
5.14 Stop RS Timer ........................................... 26
5.15 Start Cancel Timer ...................................... 26
Ramadas et al. Expires - June 2005 [Page 2]
Internet Draft LTP - Specification December 2004
5.16 Retransmit Cancellation Segment ......................... 26
5.17 Acknowledge Cancellation ................................ 26
5.18 Stop Cancel Timer ....................................... 27
5.19 Cancel Session .......................................... 27
5.20 Close Session ........................................... 27
5.21 Handle Miscolored Segment ............................... 27
6. Notices to Client Service .................................... 28
6.1 Session Start ............................................. 28
6.2 Green-Part Segment Arrival ................................ 28
6.3 Red-Part Reception ........................................ 29
6.4 Transmission Completion ................................... 29
6.5 Transmission Cancellation ................................. 29
6.6 Reception Cancellation .................................... 30
7. State Transition Diagrams ..................................... 30
7.1 Sender .................................................... 32
7.2 Receiver .................................................. 37
8. Requirements from the Operating Environment ................... 41
9. Security Considerations ....................................... 42
9.1 Security Mechanisms and Layering Considerations ........... 43
9.2 Denial of Service Considerations .......................... 44
9.3 Replay Handling ........................................... 45
9.4 Implementation Considerations ............................. 46
10. IANA Considerations .......................................... 46
11. Acknowledgments .............................................. 47
12. References ................................................... 47
12.1 Normative References ..................................... 47
12.2 Informative References ................................... 47
13. Author's Addresses ........................................... 48
14. Copyright Statement .......................................... 48
1. Introduction
This document serves as the main protocol specification of LTP, and
is part of a series of documents describing LTP. Other documents in
this series include the motivation document [LTPMOTIVE] and the
protocol extensions document [LTPEXT] respectively. We strongly
recommend reading the protocol motivation document before reading the
following document to establish sufficient background and motivation
for the contents that follow in this document.
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 protocol [BP][DTN], the
convergence layer adapter mediating between the two will be
Ramadas et al. Expires - June 2005 [Page 3]
Internet Draft LTP - Specification December 2004
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) to be transmitted via LTP
from one client service instance to another.
Any subset of a block comprising contiguous octets that begins at the
start of the block is termed a "block prefix" and any such subset of
the block that ends 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
acknowledgement 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 of a block begins at the octet following the end of the red-
part.
(5) Session
A thread of LTP protocol activity conducted for the purpose of
transmitting a block.
(6) Segment
The unit of LTP data transmission activity. It is the data structure
transmitted from one LTP engine to another in the course of a
session. An LTP segment is either a data segment, a report segment,
a report-acknowledgment segment, a cancel segment, or a cancel-
acknowledgment segment.
(7) Reception Claim
An assertion of reception of some number of contiguous octets of
application data (a subset of a block) characterized by the offset of
the first received octet and the number of contiguous octets
received.
(8) Scope
Ramadas et al. Expires - June 2005 [Page 4]
Internet Draft LTP - Specification December 2004
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 eligible
for retransmission.
Reception reports (which may comprise multiple report segments) also
have scope, as defined in Section 5.11.
(9) 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) End of Red-Part (EORP)
That segment transmitted as part of the original transmission of a
block which contains the last octet of the block's red-part. This
data segment also indicates that the segment's upper bound is the
length of the block's red-part (in octets).
(11) 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) Reception Report
Ramadas et al. Expires - June 2005 [Page 5]
Internet Draft LTP - Specification December 2004
A sequence of one or more report segments reporting on all block data
reception within some scope.
(13) Synchronous Reception Report
A reception report that is issued in response to a checkpoint.
(14) Asynchronous Reception Report
A reception report that is issued in response to some implementation-
defined event other than the arrival of a checkpoint.
(15) 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) Secondary Reception Report
A reception report that is issued in response to the arrival of a
checkpoint segment that was itself issued in response to a reception
report.
(17) Self-Delimiting Numeric Value (SDNV)
The design of LTP attempts to reconcile minimal consumption of
transmission bandwidth with
(a) extensibility to satisfy requirements not yet identified and
(b) scalability across a very wide range of network sizes and
transmission payload sizes.
A key strategic element in the design is the use of self-delimiting
numeric values (SDNVs) that are similar in design to the Abstract
Syntax Notation One [ASN1] encoding of data structures. SDNVs are of
two basic types, SDNV-8 and SDNV-16. An SDNV-8 can be used to encode
a variable length number from 1 to 128 octets in length; an SDNV-16
can be used to encode a variable length number from 2 to 128 octets
in length. The first octet of an SDNV - the "discriminant" - fully
characterizes the SDNV's value.
SDNV-8
If the most significant bit of the discriminant is zero, the
Ramadas et al. Expires - June 2005 [Page 6]
Internet Draft LTP - Specification December 2004
length of the SDNV-8 is 1 octet and the contents of the remaining
7 bits of the discriminant viewed as an unsigned integer is the
value of the SDNV. An integer in the range of 0 to 127 can be
encoded this way.
Otherwise (if the most significant bit of the discriminant is 1),
the remaining 7 bits encode the length of the SDNV's value. If the
content of the remaining 7 bits viewed as an unsigned integer has
the value N, the encoded number is N+1 octets long and has the
value found by concatenating octets 2 through N+2 of the SDNV-8,
viewed as an unsigned integer. For example, if N were 0, the
following single octet would contain the value of the SDNV-8; if N
were 127, the following 128 octets would contain the encoded
unsigned number.
SDNV-16
If the most significant bit of the discriminant is zero, then the
length of the SDNV-16 is 2 octets and the contents of the
remaining 7 bits of the discriminant concatenated with the
following octet, viewed as a 15-bit unsigned integer, is the value
encoded. An integer in the range of 0 to 32767 can be encoded this
way.
Otherwise (if the most significant bit of the discriminant is 1),
the encoding is similar to SDNV-8. If the content of the remaining
7 bits viewed as an unsigned integer has the value N, the encoded
number is N+1 octets long and has the value found by concatenating
octets 2 through N+2 of the SDNV-16, viewed as an unsigned
integer.
An SDNV can therefore be used to represent both very large and very
small integer values. For example, the maximum size of an SDNV - a
1024-bit number - is large enough to contain a fairly safe encryption
key, while any whole-degree Celsius temperature in the range in which
water is a liquid can be represented in a single-octet SDNV-8.
In the LTP header specification that follows, various fields in the
header are defined to be of types SDNV-8 or SDNV-16 depending on the
typical range of values expected for the field. If a field in the
header carries a number that typically requires 16 bits to encode,
but under certain infrequent conditions may grow longer and require,
say, 32 bits to encode, it might be optimal to specify it as an
SDNV-16 instead of specifying the field as a fixed 32 bit integer.
However, SDNV is clearly not the best way to represent every numeric
value. When the maximum possible value of a number is known without
question, the cost of an additional 8 bits of discriminant may not be
Ramadas et al. Expires - June 2005 [Page 7]
Internet Draft LTP - Specification December 2004
justified. For example, an SDNV-8 is a poor way to represent an
integer whose value typically falls in the range 128 to 255.
In general, though, we believe that SDNV representation of selected
numeric values in LTP segments yields the smallest segment sizes
without sacrificing scalability.
(18) Client Service Instance
A software entity, such as an application or a higher-layer protocol
implementation, that is using LTP to transfer data.
3. Segment Structure
Each LTP segment comprises
(a) a "header" in the format defined below.
(b) zero or more octets of "content".
(c) zero or more octets of "trailer" as indicated by information in
the "extensions field" of the header.
LTP segments are of four general types depending on the nature of the
content carried:
Data segments carry client service (application) data, together
with metadata enabling the receiving client service instance to
receive and make use of that data.
A report segment carries data reception claims together with the
upper and lower bounds of the data block scope to which the claims
pertain.
A report-acknowledgment segment carries only the serial number of
the report being acknowledged.
Session management segments are of two general subtypes:
Cancellation and Cancellation-acknowledgment. A Cancellation
segment carries a single byte reason-code to indicate the reason
for the cancellation. Cancellation-acknowledgment segments have no
content.
The overall segment structure is illustrated below :
Ramadas et al. Expires - June 2005 [Page 8]
Internet Draft LTP - Specification December 2004
Bit 0 1 2 3 4 5 6 7
^ +-----+-----+-----+-----+-----+-----+-----+-----+
| | Version number | Segment Type Flags |
| +-----------------------+-----------------------+
| | |
| / Session ID \
| \ /
Header +-----------------------+-----------------------+
| | Header Extension Cnt. | Trailer Extension Cnt.|
| +-----------------------+-----------------------+
| | |
| / Header Extensions \
| \ /
V +-----------------------------------------------+
| |
| |
| |
| Segment Content |
/ \
\ /
| |
| |
| |
^ +-----------------------------------------------+
| | |
Trailer / Trailer Extensions \
| \ /
V +-----------------------------------------------+
3.1 Segment Header
An LTP segment header comprises three data items: a single-octet
control byte, a session ID, and an extensions field.
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.
Session ID uniquely identifies, among all transmissions between the
segment's sender and receiver, the session of which the segment is
one token. It comprises the following:
Session originator: the engine ID of the LTP engine that initiated
the session, in SDNV-8 representation.
Ramadas et al. Expires - June 2005 [Page 9]
Internet Draft LTP - Specification December 2004
Session number: a number in SDNV-16 representation, typically a
random number (for anti-DoS reasons), generated by the LTP engine
identified as the session originator.
The format and resolution of session number are matters that are
private to the session-originating engine; the only requirement
imposed by LTP is that every session initiated by an LTP engine
MUST be uniquely identified by the session ID.
The 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 end of block. Any data segment (whether red-part
or 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.
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 or EORP or EOB}
0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB}
0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB
0 0 1 1 3 Red data, Checkpoint, EORP, EOB
0 1 0 0 4 Green data, NOT EOB
0 1 0 1 5 Undefined
0 1 1 0 6 Undefined
0 1 1 1 7 Green data, EOB
Ramadas et al. Expires - June 2005 [Page 10]
Internet Draft LTP - Specification December 2004
1 0 0 0 8 Report segment
1 0 0 1 9 Report-acknowledgment segment
1 0 1 0 10 Undefined
1 0 1 1 11 Undefined
1 1 0 0 12 Cancel segment from block sender
1 1 0 1 13 Cancel-acknowledgment segment
to 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
Ramadas et al. Expires - June 2005 [Page 11]
Internet Draft LTP - Specification December 2004
1 1 - 0 Cx Cancel segment (generic)
1 1 - 1 CAx Cancel-acknowledgment segment
(generic)
3.1.4 Extensions field
The extension field enables the 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.
Each extension consists of a one-octet tag identifying the type of
extension (the "T" of the extension TLV), followed by an extension
specification in SDNV-8 format. [Since an SDNV-8 comprises both a
numeric data value and the length of that value, the extension
specification serves to supply both the "L" and the "V" of the
extension TLV.]
The diagram below illustrates the extension TLVs as they may occur in
the header or trailer.
+--------+---------------///-+
|ext-tag | SDNV-8 spec |
+--------+-------------------////-+
|ext-tag | SDNV-8 spec |
+--------+-------------------////-+
|ext-tag | SDNV-8 spec |
+--------+------------////-+-+
|ext-tag | SDNV-8 spec |
+--------+--------------////-+
One extension type is defined at this time.
Extension tag Meaning
------------- -------
0x00 LTP authentication extension [LTPEXT]
0x01 LTP cookie estension [LTPEXT]
0x02-0xff Reserved
Ramadas et al. Expires - June 2005 [Page 12]
Internet Draft LTP - Specification December 2004
3.2 Segment Content
3.2.1 Data Segment (DS)
The content of a data segment includes client service data and
metadata enabling the receiving client service instance to receive
and make use of that data.
Client service ID [SDNV-8]
The client service ID number identifies the upper-level service to
which the segment is to be delivered by the destination LTP
engine. It is functionally analogous to a well-known TCP port
number. If multiple instances of the client service are present
at the destination, multiplexing must be done by the client
service itself on the basis of information encoded within the
transmitted block.
Offset [SDNV-16]
Offset indicates the location of the segment's client service data
within the session's transmitted block. It is the number of bytes
in the block prior to the byte from which the first octet of the
segment's client service data was copied.
Length [SDNV-16]
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-8]
The checkpoint serial number uniquely identifies the checkpoint
among all checkpoints issued by the block sender in a session.
The first checkpoint issued by the sender MUST have this serial
number chosen randomly for security reasons, and it is RECOMMENDED
that the sender use the guidelines in [ECS94] for this. Any
subsequent checkpoints issued by the sender MUST have the serial
number value found by incrementing the prior checkpoint serial
number by 1. When a checkpoint segment is retransmitted, however,
its serial number MUST be the same as when it was originally
Ramadas et al. Expires - June 2005 [Page 13]
Internet Draft LTP - Specification December 2004
transmitted.
Report serial number [SDNV-8]
If the checkpoint was queued for transmission in response to the
reception of an RS [Sec 5.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-8]
The report serial number uniquely identifies the report among all
reports issued by the block receiver in a session. The first
report issued by the receiver MUST have this serial number chosen
randomly for security reasons, and it is RECOMMENDED that the
receiver use the guidelines in [ECS94] for this. Any subsequent 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.
Checkpoint serial number [SDNV-8]
The value of checkpoint serial number MUST be zero if the report
segment is NOT a response to reception of a checkpoint, i.e., the
reception report is asynchronous; otherwise it is the checkpoint
serial number of the checkpoint that caused the RS to be issued.
Upper bound [SDNV-16]
The upper bound of a report segment is the size of the block
prefix to which the segment's reception claims pertain.
Ramadas et al. Expires - June 2005 [Page 14]
Internet Draft LTP - Specification December 2004
Lower bound [SDNV-16]
The lower bound of a report segment is the size of the (interior)
block prefix to which the segment's reception claims do NOT
pertain.
Reception claim count [SDNV-8]
The number of data reception claims in this report segment.
Reception claims
Each reception claim comprises two elements: offset and length.
Offset [SDNV-16]
The offset indicates the successful reception of data beginning
at the indicated offset from the lower bound of the RS. The
offset within the entire block can be calculated by summing
this offset with the lower bound of the RS.
Length [SDNV-16]
The length of a reception claim indicates the number of
contiguous octets of block data starting at the indicated
offset (within the scope of the report) that have been
successfully received so far.
Reception claims MUST conform to the following rules:
A reception claim's length shall never be less than 1 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.
Implied requests for retransmission of client service data can be
inferred from an RS's data reception claims. However, *nothing* can
be inferred regarding reception of block data at any offset equal to
or greater than the segment's upper bound or at any offset less than
the segment's lower bound.
For example, if the scope of a report segment has lower bound 0 and
Ramadas et al. Expires - June 2005 [Page 15]
Internet Draft LTP - Specification December 2004
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.
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-8]
This field returns the report serial number of the RS being
acknowledged.
3.2.4 Session Management Segments
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.
Cancel segments (Cx) carry a single byte reason-code with the
following semantics :
Reason-Code Mnemonic Semantics
----------- -------- ---------------------------------------
00 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 - June 2005 [Page 16]
Internet Draft LTP - Specification December 2004
04-FF Undefined
The Cancel-acknowledgments (CAx) have no content.
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 service ID
Destination LTP engine ID
Client service data to send, as an array of bytes.
Length of the data to be sent. This value MUST NOT exceed the
largest numeric value that can be represented in an SDNV-8.
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
each subdivision serving as the client service data of a single new
LTP data segment. The algorithm used for subdividing the data is a
local implementation matter; it is expected that data size
constraints imposed by the underlying communication service, if any,
will be accommodated in this algorithm.
The last (and only the last) of the resulting data segments must be
marked as 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.
Ramadas et al. Expires - June 2005 [Page 17]
Internet Draft LTP - Specification December 2004
To prevent segment type ambiguity, each data segment MUST contain
either only red-part data or only green-part data. Note that this
implies that, when the length of the block's red-part is N and the
total length of the block M, and N is not equal to M, the (N+1)st
byte of the block MUST be the first byte of client service data in
some green-part data segment.
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 serve as additional
discretionary checkpoints [Sec 3.1.2].
All data segments are appended to the (conceptual) application data
queue for transmission.
Finally, a session start notice [Sec 6.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 sender or as
receiver of the associated data block, the client service must
provide to LTP the session ID of the session to be canceled.
On reception of a valid cancellation request from a client service,
LTP proceeds as follows.
First the internal "Cancel session" procedure [Sec 5.19] is invoked.
Next, if the session is being canceled by the block sender (i.e., the
session originator part of the session ID supplied in the
cancellation request is the local LTP engine ID):
If none of the data segments previously queued for transmission as
part of this session have yet been de-queued and radiated - i.e.,
if the destination engine cannot possibly be aware of this session
- then the session is simply closed; the "Close session" procedure
[Sec 5.20] is invoked.
Otherwise, a CS with reason-code 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):
Ramadas et al. Expires - June 2005 [Page 18]
Internet Draft LTP - Specification December 2004
If there is no transmission queue-set bound for the block sender
(possibly because the local LTP engine is running on a receive-
only device), then the session is simply closed; the "Close
session" procedure [Sec 5.20] is invoked.
Otherwise, a CR with reason-code CNCLD MUST be queued for
transmission to the block sender.
5. Internal Procedures
This section describes the internal procedures that are triggered by
the occurrence of various events during the life-time of the LTP
session.
Whenever the content of any of the fields of the header of any
received LTP segment does not conform to this specification document,
the segment is assumed to be corrupt and MUST be discarded
immediately and processed no further. This procedure supersedes all
other procedures described below.
All internal procedures described below that are triggered by the
arrival of a data segment are superseded by the following procedure
in the event that the client service identified by the data segment
does not exist at the local LTP engine:
If there is no transmission queue-set bound for the block sender
(possibly because the local LTP engine is running on a receive-
only device), then the received data segment is simply discarded.
Otherwise, if the data segment contains data from the red-part of
the block, a CR with reason-code UNREACH MUST be enqueued for
transmission to the block sender. A CR with reason-code UNREACH
SHOULD be similarly enqueued for transmission to the data sender
even if the data segment contained data from the green-part of the
block; note however that (for example) in the case where the block
receiver knows that the sender of this green-part data is
functioning in a "beacon" (transmit-only) fashion, a CR need not
be sent. In either case the received data segment is discarded.
5.1 Start Transmission
This procedure is triggered by arrival of a link state cue indicating
the start of transmission to a specified remote LTP engine.
Response: the de-queuing and delivery of segments to the LTP engine
specified in the link state cue begins.
5.2 Start Checkpoint Timer
Ramadas et al. Expires - June 2005 [Page 19]
Internet Draft LTP - Specification December 2004
This procedure is triggered by arrival of a link state cue indicating
the de-queuing (for transmission) of a CP segment.
Response: the expected arrival time of the RS that will be produced
on reception of this CP segment is computed, and a countdown timer
for this arrival time is started. However, if it is known that the
remote LTP engine has ceased transmission [Sec 5.5], then this timer
is immediately suspended, because the computed expected arrival time
may require an adjustment that cannot yet be computed.
5.3 Start RS Timer
This procedure is triggered by arrival of a link state cue indicating
the de-queuing (for transmission) of an RS.
Response: the expected arrival time of the RA that will be produced
on reception of this RS is computed, and a countdown timer for this
arrival time is started. However, if it is known that the remote LTP
engine has ceased transmission [Sec 5.5], then this timer is
immediately suspended, because the computed expected arrival time may
require an adjustment that cannot yet be computed.
5.4 Stop Transmission
This procedure is triggered by arrival of a link state cue indicating
the cessation of transmission to a specified remote LTP engine.
Response: the de-queuing and delivery to the underlying communication
system of segments from traffic queues bound for the LTP engine
specified in the link state cue ceases.
5.5 Suspend Timers
This procedure is triggered by arrival of a link state cue indicating
the cessation of transmission from a specified remote LTP engine to
the local LTP engine. Normally, this event is inferred from advance
knowledge of the remote engine's planned transmission schedule.
Response: countdown timers for the acknowledging segments that the
remote engine is expected to return are suspended as necessary based
on the following procedure.
The nominal acknowledge transmission time is computed as the sum of
the transmission time of the original segment (to which the
acknowledging segment will respond) and the one-way light time to the
remote engine, plus N seconds of "additional anticipated latency"
(AAL) encompassing anticipated transmission delays other than signal
propagation time. N is determined in an implementation-specific
Ramadas et al. Expires - June 2005 [Page 20]
Internet Draft LTP - Specification December 2004
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 processing and queuing delay margin; it
can be a network management parameter, for which 2 seconds seems to
be 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 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 Resume Timers
This procedure is triggered by arrival of a link state cue indicating
the start of transmission from a specified remote LTP engine to the
local LTP engine. Normally, this event is inferred from advance
knowledge of the remote engine's planned transmission schedule.
Response: expected arrival time is adjusted for every acknowledging
segment that the remote engine is expected to return, for which the
countdown timer has been suspended. In each case, expected arrival
time is increased by a transmission delay interval that is calculated
as follows:
The nominal acknowledge transmission time is computed as the sum
of the transmission time of the original segment (to which the
acknowledging segment will respond) and the one-way light time to
the remote engine, plus N seconds of AAL [Sec 5.5].
If the nominal 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 acknowledge transmission time.
After adjustment of expected arrival time, each of the suspended
countdown timers is resumed.
5.7 Retransmit Checkpoint
This procedure is triggered by the expiration of a countdown timer
associated with a CP segment.
Ramadas et al. Expires - June 2005 [Page 21]
Internet Draft LTP - Specification December 2004
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] is invoked, a CS with reason-code RLEXC is
appended to the (conceptual) application data queue, and a
transmission cancellation notice [Sec 6.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 Retransmit RS
This procedure is triggered by either (a) expiration of a countdown
timer associated with an RS or (b) reception of a CP segment whose
checkpoint serial number is equal to that of one or more previously
issued RSs for the same session -- an unnecessarily retransmitted
checkpoint.
Response: if the number of times any affected RS has been queued for
transmission exceeds the report retransmission limit established for
the local LTP engine by network management, then the session of which
the segment is one token is canceled: the "Cancel session" procedure
[Sec 5.19] is invoked, a CR with reason-code RLEXC is queued for
transmission to the LTP engine that originated the session, and a
reception cancellation notice [Sec 6.6] is sent to the client service
identified in each of the data segments received in this session.
Otherwise, a new copy of each affected RS is queued for transmission
to the LTP engine that originated the session.
5.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] is sent to the
specified client service.
5.10 Signify Green-Part Segment Arrival
This procedure is triggered by the arrival of a data segment whose
content is a portion of the green-part of a block.
Ramadas et al. Expires - June 2005 [Page 22]
Internet Draft LTP - Specification December 2004
Response: a green-part segment arrival notice [Sec 6.2] is sent to
the specified client service.
5.11 Send Reception Report
This procedure is triggered by either (a) reception of a CP segment
whose checkpoint serial number is not equal to that of any previously
issued RS or (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] is invoked, a CR 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 cancellation notice [Sec 6.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 which can be issued for any
single session.
If such 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: For deployments where
bandwidth economy is not critical, the upper bound of a
synchronous reception report MAY be the maximum upper bound value
among all red-part data segments received so far in the affected
session.
If the checkpoint was itself issued in response to a report
segment, then this report is a "secondary" reception report. In
that case the lower bound of the report SHOULD be the lower bound
of the report segment to which the triggering checkpoint was
itself a response, to minimize unnecessary retransmission. Note:
For deployments where bandwidth economy is not critical, the lower
bound of the report MAY instead be zero.
If the checkpoint was not issued in response to a report segment,
this report is a "primary" reception report. The lower bound of
the first primary reception report issued for any session MUST be
Ramadas et al. Expires - June 2005 [Page 23]
Internet Draft LTP - Specification December 2004
zero. The lower bound of each subsequent primary reception report
issued for the same session SHOULD be the upper bound of the prior
primary reception report issued for the session, to minimize
unnecessary retransmission. Note: For deployments where bandwidth
economy is not critical, the lower bound of every primary
reception report MAY be zero.
If production of the reception report is "asynchronous" as noted
above:
The upper bound of the report MUST be the maximum upper bound
among all red-part data segments received so far for this session.
The lower bound of the first asynchronous reception report issued
for any session for which no other primary reception reports have
yet been issued MUST be zero. The lower bound of each subsequent
asynchronous reception report SHOULD be the upper bound of the
prior primary reception report issued for the session, to minimize
unnecessary retransmission. Note: For deployments where bandwidth
economy is not critical, the lower bound of every asynchronous
reception report MAY be zero.
In all cases, if the applicable lower bound of the scope of a report
is determined to be greater than or equal to the applicable upper
bound (e.g., due to out-of-order arrival of discretionary
checkpoints) then the reception report MUST NOT be issued. Otherwise:
As many RSs must be produced 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 RSs 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 of the report MUST be the
reception report's lower bound. The upper bound of the last RS of
the report MUST be the reception report's upper bound.
5.12 Signify Transmission Completion
This procedure is triggered at the earliest time at which (a) all
data in the block are known to have been transmitted *and* (b) the
entire red-part of the block - if of non-zero length - is known to
have been successfully received. Condition (a) is signaled by
arrival of a link state cue indicating the de-queuing (for
transmission) of the EOB segment for the block. Condition (b) is
signaled by reception of an RS whose reception claims, taken together
with the reception claims of all other RSs previously received in the
course of this session, indicate complete reception of the red-part
of the block.
Ramadas et al. Expires - June 2005 [Page 24]
Internet Draft LTP - Specification December 2004
Response: a transmission completion notice [Sec 6.4] is sent to the
client service that requested the transmission identified in the
segment header and the session is closed: the "Close session"
procedure [Sec 5.20] is invoked.
5.13 Retransmit Data
This procedure is triggered by reception of an RS.
Response: first, an RA with the same report serial number as the RS
is issued and is, in concept, appended to the queue of internal
operations traffic bound for the LTP engine that originated the
indicated session. If the RS is redundant -- i.e., either the
indicated session is unknown (for example, the RS is received after
the session has been completed or canceled), or the RS's report
serial number is equal to that of a previously received report
segment for this session -- then no further action is taken.
Otherwise the procedure below is followed.
If the report's checkpoint serial number is not zero, then the
countdown timer associated with the indicated checkpoint segment is
deleted.
Note: All retransmission buffer space occupied by data whose
reception is claimed in the report segment can be released.
If the segment's reception claims indicate incomplete data reception
within the scope of the report segment:
If the number of 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] is invoked, a CS with
reason-code RLEXC is appended to the transmission queue specified
in the transmission request that started this session, and a
transmission cancellation notice [Sec 6.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
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 the transmission
request that started this session. The last - and only the last -
such segment must be marked as a CP segment and must contain the
report serial number of the received RS.
Ramadas et al. Expires - June 2005 [Page 25]
Internet Draft LTP - Specification December 2004
5.14 Stop RS Timer
This procedure is triggered by reception of an RA.
Response: the countdown timer associated with the original RS
(identified by the report serial number of the RA segment) is
deleted. If no other countdown timers associated with RSs exist
for this session, then the session is closed: the "Close session"
procedure [Sec 5.20] is invoked.
5.15 Start Cancel Timer
This procedure is triggered by arrival of a link state cue
indicating the de-queuing (for transmission) of a Cx.
Response: the expected arrival time of the CAx that will be
produced on reception of this Cx is computed and a countdown timer
for this arrival time is started. However, if it is known that
the remote LTP engine has ceased transmission [Sec 5.5] then this
timer is immediately suspended, because the computed expected
arrival time may require an adjustment that cannot yet be
computed.
5.16 Retransmit Cancellation Segment
This procedure is triggered by the expiration of a countdown timer
associated with a Cx.
Response: if the number of times this Cx has been queued for
transmission exceeds the cancellation retransmission limit
established for the local LTP engine by network management, then
the session of which the segment is one token is simply closed:
the "Close session" procedure [Sec 5.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 Acknowledge Cancellation
This procedure is triggered by the reception of a Cx.
Response: in the case of a CS where there is no transmission
queue-set bound for the engine that originated the segment's
session (possibly because the local LTP engine is running on a
receive-only device), then no action is taken. Otherwise:
If the received segment is a CS, a CAS is issued and is, in
Ramadas et al. Expires - June 2005 [Page 26]
Internet Draft LTP - Specification December 2004
concept, appended to the queue of internal operations traffic
bound for the LTP engine that sent the CS.
If the received segment is a CR, a CAR is issued and is, in
concept appended to the queue of internal operations traffic
bound for the LTP engine that sent the CR.
It is possible that the Cx has been retransmitted because a
previous responding acknowledgment CAx was lost, in which case
there will no longer be any record of the session of which the
segment is one token. If so, no further action is taken.
Otherwise: the "Cancel session" procedure [Sec 5.19] is invoked
and a reception cancellation notice [Sec 6.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] is invoked.
5.18 Stop Cancel Timer
This procedure is triggered by reception of a CAx.
Response: the session of which the segment is one token is closed,
i.e., the "Close session" procedure [Sec 5.20] is invoked.
5.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, then all remaining data retransmission
buffer space allocated to the session can be released.
5.20 Close Session
This procedure is triggered internally by one of the other
procedures described above.
Response: any remaining countdown timers associated with the
session (such as the timer associated with a Cx) are deleted. The
session state record (SSR|RSR) for the session is deleted;
existence of the session is no longer recognized.
5.21 Handle Miscolored Segment
Ramadas et al. Expires - June 2005 [Page 27]
Internet Draft LTP - Specification December 2004
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 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 lower than the offset of any red-part
data segment previously received for the same session.
Response: the received data segment is simply discarded.
The Cancel Session procedure [Sec 5.19] is invoked and a CR with
reason-code MISCOLORED SHOULD be enqueued for transmission to the
data sender. Note : If there is no transmission queue-set bound
for the block sender (possibly because the local LTP engine is
running on a receive-only device), or if the block receiver knows
that the sender of this green-part data is functioning in a
"beacon" (transmit-only) fashion, a CR need not be sent. A
Reception Cancellation Notice [Sec 6.6] is sent to the client
service.
6. Notices to Client Service
In all cases the representation of notice parameters is a local
implementation matter.
6.1 Session Start
The LTP engine returns the session ID of the new transmission
session when a session start notice is delivered.
A session start notice informs the client service of the
initiation of a transmission session in response to a transmission
request from that client service. On receiving this notice the
client service may, for example, release resources of its own that
are allocated to the block being transmitted, or remember the
session ID so that the session can be canceled in the future if
necessary.
6.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
Ramadas et al. Expires - June 2005 [Page 28]
Internet Draft LTP - Specification December 2004
block.
Length of the data segment's content.
Indication as to whether or not the last byte of this data
segment's content is also the end of the block.
Source LTP engine ID.
6.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 Transmission Completion
The sole parameter provided by the LTP engine when a transmission
completion notice is delivered is the session ID of the
transmission session.
A transmission completion notice informs the client service that
all bytes of the indicated data block have been transmitted and
the destination LTP engine has received the red-part of the block.
6.5 Transmission Cancellation
The parameters provided by the LTP engine when a transmission
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 cancellation notice informs the client service that
the indicated session was terminated, either by decision of the
Ramadas et al. Expires - June 2005 [Page 29]
Internet Draft LTP - Specification December 2004
destination client service instance or due to violation of a
retransmission limit in the local LTP engine. There is no
assurance that the destination client service instance received
the critical part of the data block.
6.6 Reception 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 cancellation notice informs the client service that
the indicated session was terminated, either by decision of the
source client service instance or due to error conditions at the
local LTP engine. No subsequent delivery notices will be issued
for this session.
7. State Transition Diagrams
The following mnemonics have been used in the 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. Note that
blocks represented in rectangles as in
+---------+
| FG_XMIT |
+---------+
specify actual states in the state-transition diagrams, while
blocks represented as in
/\/\/\/\
| Cncld |
\/\/\/\/
are not actual states but merely pointers to a state or a sequence
of state transitions represented elsewhere in the state transition
Ramadas et al. Expires - June 2005 [Page 30]
Internet Draft LTP - Specification December 2004
diagram (to avoid having multiple copies of a sequence of state
transitions, thus accomodating space constraints).
Ramadas et al. Expires - June 2005 [Page 31]
Internet Draft LTP - Specification December 2004
7.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 - June 2005 [Page 32]
Internet Draft LTP - Specification December 2004
LTP Sender State Transition Diagram (contd.)
/\/\ /\/\
| CP | | CX |
\/\/ \/\/
| | | Snd CS,
| | RL EXC; | Start CS Tmr;
| | |
| | /\/\ | +---+
| +------>| CX | V V |
| \/\/ +---------+ | CS TE,
| | CS_SENT | | RL NOT EXC;
V RL NOT EXC; +-+--+--+-+ | Rxmt CS,
Rxmt CP, | | | | Restart
Start CP Tmr; CS TE, | | +---+ CS Tmr
RL EXC; | |
| | Rcv CAS;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
/\/\
| RX |
\/\/
| Cncl CP Tmr (if any)
V Snd RA
+---------+ +----+
| CHK_RPT | | |
+-+--+----+ RP in scope V |
| | \ NOT rcvd. fully +---------+ | Rxmt
Redundant | | RP +--------------------->| RP_RXMT | | missing
RS rcvd; | | in scope +----+--+-+ | RDS;
| | rcvd. fully | | |
V V Rxmt last | +----+
missing RDS |
(marked CP) |
Start CP Tmr; |
V
Ramadas et al. Expires - June 2005 [Page 33]
Internet Draft LTP - Specification December 2004
The sender LTP stays in the CLOSED state until receiving a
Block Transmission Request (Blk. Trans. Req) from the client
service instance. Upon receiving the request it either moves to
the Fully Green Transmission State (FG_XMIT) if no portion of the
block was requested to be transmitted as red, or moves to the Red-
Part Transmission State (RP_XMIT) state if a non-zero block-prefix
was requested to be transmitted red.
In the FG_XMIT state, the block is segmented as multiple green
LTP data segments respecting the link MTU size and the segments
are queued for transmission to the remote engine. The last such
segment is marked as EOB and the sender LTP returns to the CLOSED
state after queuing it for transmission.
Similarly, from the RP_XMIT state multiple red data segments
are queued for transmission. The sender LTP may optionally mark
some of the red data segments as asynchronous checkpoints; the
internal procedure Start Checkpoint Timer [Sec 5.2] is followed
upon receiving a link-state cue indicating the actual beginning of
transmission of such segments. The sender LTP marks the last red-
data segment of the block as both CP and EORP, and after queuing
it for transmission moves to the Green Part Transmission (GP_XMIT)
state. If the block transmission was fully red however, the last
red-data segment is marked as CP, EORP, and EOB and the sender LTP
moves to the Wait-for-Red-Part-Acknowledgment (WAIT_RP_ACK) state
instead. For both the above state-transitions, the internal
procedure Start Checkpoint Timer [Sec 5.2] is followed upon
receiving a link-state cue indicating the beginning of
transmission of the queued CP segments. If the sender LTP entered
the GP_XMIT state, the remaining green-part of the block is
segmented as green data segments and queued for transmission to
the receiver LTP; the last green segment of the block is
additionally marked as EOB and the sender LTP moves to the
WAIT_RP_ACK state.
While the sender LTP is at 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 the receiver LTP (either in
response to a previously transmitted CP segment or sent
asynchronously for accelerated retransmission). The sender LTP
then moves to perform the sequence of state transitions
beginning at the RX marker (second-part of the diagram), and
retransmits data if necessary, illustrating the internal
procedure Retransmit Data [Sec 5.13]:
First, if the RS had a non-zero CP serial number, the
Ramadas et al. Expires - June 2005 [Page 34]
Internet Draft LTP - Specification December 2004
corresponding CP timer is canceled. Then, an RA segment
acknowledging the received RS is queued for transmission to the
receiver LTP and the sender LTP moves to the Check Report state
(CHK_RPT). If the RS was redundantly transmitted by the
receiver LTP (possibly because either the last transmitted RA
got lost or the RS timer expired prematurely at the receiver),
the sender LTP does nothing more and returns back to the
interrupted state. Similarly, if all red-data within the scope
of the RS is reported as received, there is no work to be done
and the sender LTP returns to the interrupted state. However,
if the RS indicated incomplete reception of data within its
scope, the sender LTP moves to the Red-part Retransmit state
(RP_RXMT) where missing red data-segments within scope are
queued for transmission. The last such segment is marked as a
CP, and the sender LTP returns to the interrupted state. The
internal procedure [Sec 5.2] is followed upon receiving a
link-state cue indicating beginning of transmission of the CP
segment.
2. A previously set CP timer might expire. Now the sender LTP
follows the states beginning at the CP marker (second-part of
the diagram), and follows the internal procedure Retransmit
Checkpoint [Sec 5.7]:
If the CP Retransmission Limit set by network management for
the session has been exceeded, the sender LTP proceeds towards
canceling the session (with reason-code RLEXC) as indicated by
the sequence of state transitions following the CX marker.
Otherwise (if the Retransmission Limit is not exceeded yet),
the CP segment is queued for retransmission and the sender LTP
returns to 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 of the
segment.
The sender LTP stays at the WAIT_RP_ACK state after reaching it
until the red-part data is fully acknowledged as received by the
receiver LTP, and then returns to the CLOSED state following the
internal procedure Close Session [Sec 5.20].
<<Talk about 2 MSL here??>> Note that while at the CLOSED state,
the sender LTP might receive an RS (if the last transmitted RA
before session close got lost or if the receiver LTP retransmitted
the RS prematurely), in which case it retransmits an acknowledging
RA and stays in the CLOSED state. If the session was canceled by
the Receiver by issuing a CR segment, the receiver may retransmit
the CR (either prematurely or because the acknowledging CAR got
lost). In this case, the sender LTP retransmits the acknowledging
Ramadas et al. Expires - June 2005 [Page 35]
Internet Draft LTP - Specification December 2004
CAR and stays in the CLOSED state.
Asynchronous cancel request may be received from the local client
service while the sender LTP was in any of the states mentioned.
If it was not already in the sequence of state transitions
beginning at the CX marker, the internal procedure Cancel Session
[Sec 5.19] is followed, and the sender LTP moves from its current
state into the sequence beginning at the CX marker initiating
session cancellation with reason-code CNCLD. From the CX marker,
the CS segment with appropriate reason-code (CNCLD or RLEXC
depending on how the CX sequence was entered) is queued for
transmission to the receiver LTP and the sender enters the Cancel-
from-Sender Sent(CS_SENT) state. The internal procedure Start
Cancel Timer [Sec 5.15] is started upon receiving a link-state cue
indicating the beginning of transmission of the CS segment. Upon
receiving the acknowledging CAS from the receiver, the sender LTP
moves to the CLOSED state (via the Cncld marker). If the CS Timer
expires, the internal procedure Retransmit Cancellation Segment
[Sec 5.16] is followed:
If the network management set retransmission limit is exceeded,
the session is simply closed and the sender LTP follows the
Cncld marker to the CLOSED state. If the retransmission limit
is not exceeded however, the CS segment is queued for a
retransmission and the sender LTP stays in the CS_SENT state.
The CS Timer is started upon receiving a link-state cue
indicating the beginning of actual transmission according to
the internal procedure Start Cancel Timer [Sec 5.15].
Asynchronous cancel request may also be received from the receiver
LTP in the form of a CR segment when the sender LTP is in any of
the states. Upon receiving such a CR segment, the internal
procedure Acknowledge Cancellation [Sec 5.17] is invoked: The
sender LTP sends a CAR segment in response and returns to the
CLOSED state.
Ramadas et al. Expires - June 2005 [Page 36]
Internet Draft LTP - Specification December 2004
7.2 Receiver
LTP Receiver State Transition Diagram
/\/\/\/\
+----+ +----+ Cncld |
Rcv CS; | V V \/\/\/\/
Snd CAS | +-------------+
+--+ CLOSED +<--------------------------+
+------+------+ |
+----+ | Rcv first DS |
Rcv RA; | V V |
Cncl RS Tmr | +--------+ |
+---+ DS_REC | |
+----------------------------->+-+--+-+-+<----------------------+---+ |
| Svc. does not exist | | | RS TE | | |
| /\/\ or Rcv miscolored seg. | | | /\/\ | | |
| | CX |<-----------------------+ | +------------->| RX |---->+ | |
| \/\/ | \/\/ | |
| Rcv RDS; | Rcv GDS; | |
| +-----------+------------+ | |
| V V | |
| /\/\ RS TE +--------------+ +--------+ | |
+<-| RX |<------+ RCV_RP | | RCV_GP | | |
| \/\/ +-+----+--+--+-+ +--+-+-+-+ | |
| | | | | | | | | |
| Rcvd RDS; | | | | Rcvd {RDS, CP, | | | RS TE /\/\ | |
| | | | | EORP, EOB}; | | +------>| RX |->+ |
+<----------------+ | | | Snd RS, | | \/\/ | |
| | | | Start RS Tmr | | Rcvd GDS; | |
| Rcvd {RDS, CP}; | | | | +---------------->+ |
| Snd RS, Start RS Tmr | | +-------+ +-----+ |
+<---------------------+ | | | Rcvd {GDS, EOB}; |
| | | | |
| | +-----+ | | +------+ |
| Rcvd {RDS, CP, EORP}; | | V V V V | |
| Snd RS, Start RS Tmr | | +----------------+ | Rcv RDS; |
| | | | +-->+ |
| | | | WAIT_RP_REC | | Rcv {RDS, CP}; |
| | | | +-->+ Snd RS, Start |
+<------------------------+ | +---+--+-+-+-----+ | RS Tmr |
| RS TE | | | | Rcv RA; | |
| V | | | Cncl | |
| /\/\ | | | RS Tmr | |
+---| RX | | | +-------->+ |
\/\/ | | |
/\/\ | | |
| CX |<------------------------+ | RP rcvd. fully |
\/\/ Rcv miscolored seg. +--------------------------->+
Ramadas et al. Expires - June 2005 [Page 37]
Internet Draft LTP - Specification December 2004
LTP Receiver State Transition Diagram (contd.)
/\/\
| RX |
\/\/
| |
| | RL EXC; /\/\
RL NOT EXC; | +---------->| CX |
Rxmt RS, | \/\/
Start RS Tmr |
V
/\/\
| CX |
\/\/
| Snd CR,
| Start CR Tmr;
|
| +----+
V V |
+---------+ | CR TE,
| CR_SENT | | RL NOT EXC;
+-+--+--+-+ | Rxmt CR,
| | | | Restart
CR TE, | | +---+ CR Tmr
RL EXC; | |
| | Rcv CAR;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
Ramadas et al. Expires - June 2005 [Page 38]
Internet Draft LTP - Specification December 2004
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 segment with reason-code UNREACH SHOULD be
sent to the sender LTP with 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), the
internal procedure Handle Miscolored Segment [Sec 5.21] 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.
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 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 is
queued for transmission to the sender following either the
internal procedure Retransmit RS [Sec 5.8] or Send Reception
Report [Sec 5.11] depending on whether the CP segment was a
retransmission (An RS corresponding to the Checkpoint Serial
Number in the CP was previously issued) or not, respectively.
The receiver LTP then returns to the DS_REC state. If the block
transmission was fully red and the segment was marked as CP, EORP,
and EOB, the receiver LTP enters the Wait-for-Red-Part-Reception
state (WAIT_RP_REC). In all cases the internal procedure Start RS
Timer [Sec 5.3] is followed upon receiving link-state cues
indicating beginning of transmission of the 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 the
receiver LTP was in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC
states. If so, the internal procedure Retransmit RS [Sec 5.8] is
followed as illustrated in the states beginning at the RX marker
(shown in the second part of the diagram) before returning to the
interrupted state:
Ramadas et al. Expires - June 2005 [Page 39]
Internet Draft LTP - Specification December 2004
A check is made here to see if the retransmission limit set by
the network management has been exceeded in the number of RSs
sent in the session. If so, a CR segment with reason-code RLEXC
SHOULD be sent to the sender LTP and the sequence following the
CX marker is followed. Otherwise, the RS is queued for
retransmission and the associated RS timer is started following
the internal procedure Start RS Timer [Sec 5.3] upon receiving
a link-state cue indicating the beginning of its transmission.
The receiver LTP may also receive RA segments from the sender in
response to the RSs 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].
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 DS to see if it is at a block offset
higher than any green-part DS received. If so, the Handle
Miscolored Segment internal procedure [Sec 5.21] is invoked and
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 for transmission based on
either internal procedure Retransmit RS [Sec 5.8] or Send
Reception Report [Sec 5.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. If an RA
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,
Ramadas et al. Expires - June 2005 [Page 40]
Internet Draft LTP - Specification December 2004
the CR segment with the given reason-code (depending on how the
sequence is entered) is queued for transmission, and the CR timer
is started upon reception of the link-state cue indicating actual
transmission following internal procedure Start Cancel Timer [Sec
5.15]. If the CAR 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]. If the CR
timer expires asynchronously, the internal procedure Retransmit
Cancellation Segment [Sec 5.16] is followed :
A check is made to see if the retransmission limit set by the
network management for the number of CRs per session has been
exceeded. If so, the receiver LTP returns to the CLOSED state
following the Cncld marker. Otherwise, a CR segment is
scheduled for retransmission with the CR timer being started
following the internal procedure Start Cancel Timer [Sec 5.15]
upon reception of a link-state cue indicating actual
transmission.
<<Talk about 2 MSL here??>> The receiver LTP might also receive a
retransmitted CS at the CLOSED state (either if the CAS segment
previously transmitted was lost or if the CS timer expired
prematurely at the sender LTP). In such a case the CAS is
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 with reason-code 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
Ramadas et al. Expires - June 2005 [Page 41]
Internet Draft LTP - Specification December 2004
seconds) to any peer engine in order to calculate timeout
intervals in a typical deep-space environment.
A MIB (Management Information Base), with the above parameters
filled in by the local data-link layer and the operating
environment periodically, should be made available to the LTP
engine for its operations. The exact details of the MIB are,
however, beyond the scope of this 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
<<Note : The LTP-Auth security mechanism defined in [LTPEXT] may
be moved back into this section if there was community consensus
in having it as a critical feature that ought to be implemented in
all implementations of the protocol.>>
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.
Ramadas et al. Expires - June 2005 [Page 42]
Internet Draft LTP - Specification December 2004
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].
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
Ramadas et al. Expires - June 2005 [Page 43]
Internet Draft LTP - Specification December 2004
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 such security may result in
unnecessary overhead (if a service provided is not required for
all LTP sessions, for example) and loss of flexibility.
However, the lower layers may well be the optimal place to do
compression and encryption.
9.2 Denial of Service Considerations
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 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 flip some bits, which is tantamount to
deleting that segment.
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.
<<More TBD>>
LTP includes the following anti-DoS mechanisms:
Session numbers MUST be partly random making it harder to
Ramadas et al. Expires - June 2005 [Page 44]
Internet Draft LTP - Specification December 2004
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 Replay Handling
The following algorithm is given as an example of how an LTP
implementation MAY handle replays.
1. On receipt of an LTP segment, check against a cache for replay.
If this is a replay segment and if a pre-cooked response is
available (stored from the last time this segment was processed),
then send the pre-cooked response. If there is no pre-cooked
response then silently drop the inbound segment. This can all be
done without attempting to decode the buffer.
2. If the inbound segment does not decode correctly, then silently
drop the segment. If the segment decodes properly, then add its
hash to the replay cache and return a handle to the entry.
3. For those cases where a pre-cooked response should be stored,
store the response using the handle received from the previous
step. These cases include:
(a) when the inbound packet is a CP DS the response RS gets
stored as pre-cooked;
(b) when the incoming packet is an RS the RA is stored as
precooked, and,
(c) when the incoming packet is a Cx the CAx gets stored
precooked.
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
Ramadas et al. Expires - June 2005 [Page 45]
Internet Draft LTP - Specification December 2004
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 Implementation Considerations
SDNV
Implementations SHOULD make sanity checks on SDNV length fields
and SHOULD check that no SDNV field is too long when compared
with the overall segment length.
Implementations SHOULD check that SDNV values are within
suitable ranges where possible, e.g. <<TBD>>
Byte ranges
Various report and other segments contain offset and length
fields. Implementations MUST ensure that these are consistent
and sane.
Randomness
Various fields in LTP (e.g. serial numbers) should be
initialized using random values. Good sources of randomness
which are not easily guessable SHOULD be used [ECS94]. The
collision of random values is subject to the birthday paradox,
which means that a collision is likely after roughly the
square-root of the space has been seen (e.g. 2^16 in the case
of a 32-bit random value). Implementers MUST ensure that they
use sufficiently long random values so that the birthday
paradox doesn't cause a problem in their environment.
10. IANA Considerations
At present there are none known. However if someone wanted to run
LTP over IP (or even TCP or UDP), then we would want to allocate a
port number. <<Considering this is TBD>>
Ramadas et al. Expires - June 2005 [Page 46]
Internet Draft LTP - Specification December 2004
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, and Dovel
Myers at Ohio University for their suggestions and advice in
making various design decisions.
Part of this work was carried out at Trinity College Dublin as
part of the SeNDT contract funded by Enterprise Ireland's research
innovation fund.
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.
[LTPMOTIVE] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider
Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp-
motivation-00.txt (Work in Progress), December 2004.
[LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider
Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp-
extensions-00.txt (Work in Progress), December 2004.
12.2 Informative References
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ASN1] Abstract Syntax Notation One (ASN.1). Specification of
Basic Notation. ITU-T Rec. X.680 (2002) | ISO/IEC 8824-1:2002.
[DDJ] I. Goldberg and E. Wagner, "Randomness and the Netscape
Browser", Dr. Dobb's Journal, 1996, (pages 66-70).
Ramadas et al. Expires - June 2005 [Page 47]
Internet Draft LTP - Specification December 2004
[BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification",
Work in Progress, October 2003.
[DTN] K. Fall, "A Delay-Tolerant Network Architecture for
Challenged Internets", In Proceedings of ACM SIGCOMM 2003,
Karlsruhe, Germany, Aug 2003.
[IPN] InterPlanetary Internet Special Interest Group web page,
"http://www.ipnsig.org".
[ECS94] D. Eastlake, S. Crocker, and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
13. Author's Addresses
Manikantan Ramadas
Internetworking Research Group
301 Stocker Center
Ohio University
Athens, OH 45701
Telephone +1 (740) 593-1562
Email mramadas@irg.cs.ohiou.edu
Scott C. Burleigh
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 179-206
Pasadena, CA 91109-8099
Telephone +1 (818) 393-3353
FAX +1 (818) 354-1075
Email Scott.Burleigh@jpl.nasa.gov
Stephen Farrell
Distributed Systems Group
Computer Science Department
Trinity College Dublin
Ireland
Telephone +353-1-608-3070
Email stephen.farrell@cs.tcd.ie
14. Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
This document and the information contained herein are provided on an
Ramadas et al. Expires - June 2005 [Page 48]
Internet Draft LTP - Specification December 2004
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Ramadas et al. Expires - June 2005 [Page 49]
