Licklider Transmission Protocol for
CCSDS (LTP for CCSDS) Interoperability
Test Report
1 Background
As part of its goal to develop a suite of internetworking protocols for space, CCSDS is creating profiles of
two protocols developed in the DTN Research Group (dtnrg) in the Internet Research Task Force (IRTF):


Licklider Transmission Protocol (LTP) [RFC5326, RFC5327]
Bundle Protocol (BP) [RFC5050]
LTP provides an optionally-reliable mechanism for transferring data across a single space link, and in the
CCSDS context is intended to be used as a ‘convergence layer’ for carrying BP bundles (though LTP can
also be used for other types of traffic).
This document describes the interoperability testing required to move the LTP book from ‘Red’ to ‘Blue’
status within CCSDS.
2 Overview
This interoperability test report lists the requirements of LTP-for-CCSDS implementations and describes
the interoperability tests executed to verify those requirements between two independent
implementations of the protocol. The results of the interoperability tests are listed in section
XXX_FIXME_XXX.
Note that some of the requirements listed in Table 1 pertain to conformance and not interoperability.
For example, whether or not an implementation generates the complete and correct set of service
indications does not impact the implementation’s ability to interoperate over the wire.
2.1 LTP-for-CCSDS Requirements
The following table lists the conformance requirements from [LTP_CCSDS].
Table 1: LTP Profile for CCSDS Requirements
6.2.1.1
RFC5326 3.0
RFC5326 3.1(.0)
Segment structure with header, content, trailer.
Segment Header consists of 1) control byte 2) session ID 3)
Extensions. Control Byte contains segment type.
RFC5326 3.1.4
Extensions Field Format (in header): 1 octet of # of
extensions
RFC5326 3.1.4
Extensions Format as 1 octet id followed by SDNV length
then value. [header / trailer]
RFC5326 3.2.1
Data Segments contain client service ID, offset, length,
checkpoint serial number (if checkpoint) report serail
number (if checkpoint queued in response to a report,
otherwise zero), and client service data.
RFC5326 3.2.2
Report Segments have a report serial number, checkpoint
serial number, upper bound, lower bound, reception claim
count, reception claims [offset, length]; reception claims
are always of length >0 and stay inside bounds of the
report
RFC5326 3.2.3
Report-Acknowledgement Segments contain a resport
serial number.
RFC5326 3.2.4
Cancel segment reason codes
RFC5326 3.3
Segment Trailer contains extnsions encoded as TLVs
RFC5326 4.1
RFC5326 4.2
RFC5326 6.0
Transmission.request primitive
Cancellation.request primitive
Overriding Rule -- 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
RFC5326 6.0
Overriding Rule -- if no client service id exists at local LTP
engine and no transmission queue to segment sender,
silently drop segment
RFC5326 6.0
Overriding Rule -- if no client service id exists at local LTP
engine but queue to segment sender send UNREACH
RFC5326 6.1
Start Transmission -- Receipt of link cue that transmission
can begin results in starting transmission.
RFC5326 6.2
Start Checkpoint Timer -- When a checkpoint is
transmitted, start checkpoint timer.
RFC5326 6.2
Start Checkpoint Timer -- Immediately suspend timer if it is
known that the receiver is not transmitting.
RFC5326 6.3
Start Report Segment Timer -- When a report segment is
transmitted, start the report segment timer.
RFC5326 6.3
Start Report Segment Timer -- Immediately suspend timer
if it is known that the remote engine is not transmitting.
RFC5326 6.4
Stop Transmission -- On receipt of a link cue that
transmission should be stopped, stop transmitting.
RFC5326 6.5
Suspend Timers -- When transmission is halted, stop
countdown timers associated with the remote engine.
RFC5326 6.6
Resume Timers -- When transmission is resumed, resume
countdown timers associated with the remote engine.
RFC5326 6.7
Retransmit Checkpoint -- When a checkpoint timer expires:
If the retransmission count has NOT expired, retransmit the
checkpoint.
RFC5326 6.7
Retransmit Checkpoint -- When a checkpoint timer expires:
If the retransmission count has expired, cancel the session.
RFC5326 6.8
Retransmit Report Segment -- When a report timer
expires: If the retransmission count has NOT expired,
retransmit the report
RFC5326 6.8
Retransmit Report Segment -- When a report timer
expires: If the retransmission count has expired, cancel the
session
RFC5326 6.9
RFC5326 6.1
RFC5326 6.11
RedPartReception.indication
GreenPartSegmentArrival.indication
Send Reception Report -- if the number of reception
problems does NOT exceed limit, send a report in response
to a checkpoint; note formatting and semantic rules of
6.11.
RFC5326 6.11
Send Reception Report -- if the number of reception
problems exceeds limit, cancel the session with reason
RLEXC.
RFC5326 6.12
InitialTransmissionCompletion.indication -- provide this
indication to the sending client when all data transmitted
and all red data (if any) known received.
RFC5326 6.13
Retransmit Data -- triggered by receipt of a report
segment; send Report Ack; retransmit data as indicated by
report.
RFC5326 6.14
Stop Report Segment (RS) Timer -- stop RS timer on receipt
of a report ack for the report.
RFC5326 6.15
Start Cancel Timer -- when a cancel semgnet is sent, start
cancel timer.
RFC5326 6.15
Start Cancel Timer -- Immediately suspend if known that
the peer is not transmitting.
RFC5326 6.16
Retransmit Cancellation Segment -- If the number of
retransmissions exceeds the limit, cancel the session.
Retransmit Cancellation Segment -- If the number of
retransmissions does NOT exceed the limit, retransmit the
cancel segment (with the same reason-code as before).
RFC5326 6.16
RFC5326 6.17
Acknowledge Cancellation -- In response to receipt of a
cancel segment: If there is no transmission queue to the
receiver, no action.
Acknowledge Cancellation -- in response to receipt of a
cancel segment: If there is a transmission queue to the
receiver send an appropriate (cancel ack to block
sender/receiver) segment. If there IS a record of the
session, cancel session.
Acknowledge Cancellation -- in response to receipt of a
cancel segment: if there is a transmission queue to the
receiver send an appropriate (cancel ack to block
sender/receiver) segment. If there is NO record of the
session, no further action.
RFC5326 6.18
Stop Cancel Timer -- in response to receipt of a cancellation
acknowledgement, stop the cancel timer.
RFC5326 6.19
Cancel Session: dump everything queued for transmission;
stop all countdown timers.
RFC5326 6.20
Close Session -- on session closure, stop any countdown
timers and remove session (session no longer recognized)
RFC5326 6.21
Handle Miscolored Segment -- discard segment and cancel
session.
6.2.1.2
6.2.1.2
CCSDS
CCSDS
CCSDS 7.3
CCSDS 7.4
CCSDS 7.5
CCSDS 7.6
CCSDS 7.7
RFC5326 8.1 (red)
RFC5326 8.2 (green)
CCSDS 10.2
CCSDS 3.1.2
CCSDS 3.9.1
TransmissionSessionStart.indication
ReceptionSessionStart.indication
SDA: RedPartReception.indication
SDA: TransmissionSessionCompletion.indication
SDA: TransmissionSessionCancellation.indication
SDA: ReceptionSessionCancellation.indication
SDA: InitialTransmissionCompletion.indication
State Transition diagram
State Transition diagram
Use IANA Extension tag registry
LTP Authentication: RFC5327
LTP Authentication: MAY implement authentication
6.2.1.2
CCSDS 3.9.1.1
LTP Authentication: MUST identify the ciphersuite used in
accordance with IANA registry of LTP ciphersuites.
6.2.1.2
CCSDS 3.9.2
LTP Authentication: MUST NOT implement cookies
6.2.1.2
CCSDS 3.9.4
LTP Authentication: MIB contains key material if
authentication implemented
6.2.1.2
6.2.1.3
6.2.1.4
6.2.1.5
6.2.1.6
6.2.1.8
RFC5326 2.1
LTP Authentication
NO LTP Cookies
LTP over UDP
Session Number Selection
Checkpoint Serial Number Selection
Encapsulation in Space Packets
CCSDS 3.3.1 and 3.3.2
CCSDS 3.5.1
CCSDS 3.5.2, 3.5.3
CCSDS D2.3
6.2.1.9
6.2.1.10
6.2.1.11
6.2.1.12
CCSDS D2.4
CCSDS 3.5.5, 3.5.6
RFC5326 6.1, 6.10, 7.2
CCSDS 7.2.1, 7.2.2.2,
7.2.2.3--2.2.2.5.2
Encapsulation in Encap Packets
Report Serial Number Selection
Green Data
Service Data Aggregation
2.2 Test Infrastructure
The test infrastructure uses Linux Containers (Linux Network Namespaces) to segregate the two
implementations under test.
Each instance locally communicates with a UDP-to-CCSDSEncap gateway to convert between LTP over
UDP and LTP over CCSDS Encapsulation over UDP.
The network connection between the two implementations under test is via a bridge in the Linux host.
This allows the imposition of Linux traffic control (TC) measures such as the network emulation (netem)
module to emulate delay and loss.
For some tests, one or more host processes monitors the test process in order to modify the
communications parameters. This allows the test to drive the implementations into particular
conditions. For example, a monitoring process might use ebtables to block communications after a
checkpoint segment has been sent but before the report segment is received. This would cause the
sender to retransmit the checkpoint segment until communications were re-established.
Container #1
Container #2
Sending
App
Receiving
App
Sending LTP
Engine
Receiving
LTP Engine
LTP/UDP
LTP/UDP
UDP to
Encap/UDP
UDP to
Encap/UDP
LTP/CCSDSEncap/UDP
LTP/CCSDSEncap/UDP
Ethernet Bridge in
host for Delay / Loss /
Mangling
Virtual Ethernet Interfaces in host (interfaces to containers)
Figure 1: Overview of test configuration.
Test Process(es) running
in host to drive specific
test cases
The test infrastructure is implemented in Python. Each individual test is described in a Python test script
with support from an overall infrastructure script. The steps in test execution are:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Make a test directory and copy the relevant files into it
Set up the virtual containers and wait for them to stabilize
Configure the network connectivity (bridge) between them, including any latency and loss
Start packet captures on the two virtual Ethernet interfaces in the host
Start any monitoring process(es) needed by the test
Execute the LTP data transfer by invoking the ‘test’ operation of the test script.
Stop the packet captures
Post-process the packet captures for possible visualization
Analyze the test results by invoking the ‘analyze’ operation of the test script
The analyses rely heavily on the Python ‘scapy’ package [scapy] augmented to understand both the LTP
and the CCSDS Encapsulation packet formats.
3 Implementations
The two implementations used for testing are:
1. The LTPlib implementation originally written by Stephen Farrell of Trinity College, Dublin and
modified to comply with the CCSDS profile
2. A Python-based implementation written by Keith Scott of the MITRE Corporation
4 Tests
4.1 Test Cases
Table XXX lists the interoperability tests.
Table 2: LTP-for-CCSDS Interoperability Test Cases
Test
Name
Red-Part
Green
-Part
Added
Error
Rate
LTP
Segment
Size
Basic1
100
-
None
1200
Basic1B
100
-
None
1200
Basic2
-
1,024
None
1200
LTP
Checkpoint
Interval
None (only
checkpoint
end of Red
Part)
None (only
checkpoint
end of Red
Part)
None (only
checkpoint
end of Red
Part)
Procedure
Test-Specific Success Criteria
100B Red Data. Sender sends LTP Block
to a listening service on an LTP receiver.
Correct transfer of the Red Data.
100B Red Data with Link Cues. Sender
sends LTP Block to a listening service on
an LTP receiver. Block receiver-totransmitter traffic via ebtables rule;
after checkpoint is sent and
retransmitted (and report has been
sent and retransmitted but not
received), suspend the tx->rx link (use
link cue to tell the sender that the
receiver is no longer transmitting) and
the rx->tx link (use link cue to tell the
receiver that the transmitter is no
longer transmitting); note that while
the link is suspended, checkpoints and
reports are NOT retransmitted. Cue the
tx-> rx and rx->tx links to be 'up' and
note that retransmissions begin;
unblock the rx->tx link and note that
the transfer succeeds.
1024B Green Data. Sender sends LTP
Block to a listening service on an LTP
receiver.
Correct transfer of the Red Data.
Correct transfer of the Green Data.
Basic3
2,048
4,096
None
1200
Basic4
2,048
-
None
1200
NTR
2,048
-
None
1200
Cancel1
10,000
-
None
Cancel2
10,000
-
None
None (only
checkpoint
end of Red
Part)
1,000
None (only
checkpoint
end of Red
Part)
None (only
checkpoint
end of Red
Part)
None (only
checkpoint
end of Red
Part)
2kRed, 4kGreen. Sender sends LTP
Block to an listening service on an LTP
receiver.
Correct transfer of the Red and Green
data; use of 1- and 2-byte SDNVs in redpart segments.
Multi-checkpoint Red Data. Ensure
that the sender generates a
"Checkpoint, not EORP, not EOB"
segment (type 1)
Non-Transmitting Receiver. Sender
configured to know that receiver can't
send.
Correct transfer of the Red data.
User Cancel at Sender. After starting
the transfer and while it is ongoing,
drop the link (without providing any
link cues to the sender) and then cancel
the session at the sender (by the
sending LTP user). After a short period
of time (to allow for retransmission of
cancellation segments) restore the link.
Cancellation segments sent by sender;
cancellation segments retransmitted by
sender while link down; cancellation ACK
sent by receiver after link is restored;
sender ceases transmission of cancellation
segments after receiving cancellation ACK.
No data carrying segments sent by sender
after user cancel processed; a single
cancel-ACK sent in response to a given
cancel segment. Cancellation indications
delivered to sending and receiving LTP
clients.
User Cancel at Receiver. After starting
the transfer and while it is ongoing,
drop the link (without providing any
link cues to the sender) and then cancel
the session at the reciever (by the
receiving LTP user). After a short
period of time (to allow for
retransmission of cancellation
segments) restore the link.
Cancellation segments sent by receiver;
cancellation segments retransmitted by
receiver while link down; cancellation ACK
sent by sender after link is restored;
receiver ceases transmission of
cancellation segments after receiving
cancellation ACK. No segments sent by
receiver after cancel ACK received; A
single cancel-ACK sent in response to a
given cancel segment.
Reception-Session Cancellation Indication
delivered to sending LTP user.
Cancellation indications delivered to
sending and receiving LTP clients.
Checkpoint timers should be immediately
suspended (no checkpoint
retransmsissions).
Cancel3
10,000
Cancel4
10,000
Error1
10,000
Corrupt
None (only
checkpoint
end of Red
Part)
User cancel at sender with nontransmitting receiver. After starting
the transfer and while it is ongoing,
cancel the session at the sender (by the
sending LTP user). Receiver is nontransmitting and sender knows it.
A single cancel segment sent by sender.
Cancellation indication delivered to
sending LTP client.
None
1200
None (only
checkpoint
end of Red
Part)
User cancellation at sender before any
data sent. After sending the
transmission request but before any
data can be sent, sender cancels.
Nothing ever happens over the wire.
5,000
PLR =
20%
1200
None (only
checkpoint
end of Red
Part)
20% PLR
Correct reception of the Red-Part Data;
receipt of at least some Green-Part Data.
-
10,000
None
1200
During an LTP transfer session with only
red data, send a malformed segment
then complete the session.
No LTP segment is generated by the
receiver in response to the malformed
segment (malformed segment is silently
discarded); data transfer succeeds.
Unreach1
100
-
None
1200
None (only
checkpoint
end of Red
Part)
Attempt to open an LTP connection to
an LTP client service that is not extant
at the receiver.
Receiver responds with an an LTP cancel
segment with reason code: UNREACH to
the sender. Sender closes the connection
on receipt of the UNREACH segment.
Miscolore
d1
5,000
5,000
None
1200
None (only
checkpoint
end of Red
Part)
After establishing a connection and
transmitting the Red Part data, and
beginning to send the Green Part, send
a Red segment with an offset in the
Green sequence space.
Receiver responds with an LTP cancel
segment with reason code: MISCOLORED
(and closes the connection). Sender
cancels the session on receipt of the
cancellation segment and sends a cancel
ACK.
Miscolore
d2
5,000
5,000
None
1200
None (only
checkpoint
end of Red
Part)
After establishing a connection and
transmitting the Red Part data, send a
Green segment with an offset in the
Red sequence space.
Receiver responds with an LTP cancel
segment with reason code: MISCOLORED
(and closes the connection). Sender
cancels the session on receipt of the
cancellation segment.
LinkState1
10,000
10,000
None
1200
None (only
checkpoint
end of Red
Part)
After starting transmission, suspend for
a while and then resume.
Sender does not transmit during period
where the link is asserted unavailable.
Transmission succeeds once the link is
asserted available again. This tests
suspend/resume of data, not
suspend/resume of retransmission timers.
Aggregati
on Length
Variable
0
None
1200
None (only
checkpoint
end of Red
Part)
Aggregation service running at the
sender and client; aggregation size at
the sender set to 1,000 bytes,
aggregation time set to 5 seconds.
Sending client sends 'messages' to the
aggregation service at the receiver.
Each message is consists of 1 octet of
message length followed by (length-1)
bytes of 'message' (for testing
purposes, copies of the ASCII
representations of characters 'A', 'B', ...)
Sender chooses the lengths of the
messages to send and ensures that it
sends enough messages fast enough to
invoke the 1,000-byte send trigger. All
messages are sent as red-part data.
Aggregati
on Time
Variable
0
None
1200
None (only
checkpoint
end of Red
Part)
Aggregation service running at the
sender and client; aggregation size at
the sender set to 1,000 bytes,
aggregation time set to 5 seconds.
Sending client uses the aggregation
service to send a few messages, staying
under the 1,000-byte aggregation size
trigger. Verify that aggregated groups
are send out approx. every 5s.
Authentic
ation1
0
1,000
RLEXC_S
0
1,000
0
Send a red block with LTP
Authentication turned on
Block reception at receiver; wait for
sender to give up and cancel the
session after (re)transmitting a bunch
of checkpoints; then wait for the sender
to give up on cancelling the session.
Receiver correctly demultiplexes the
messages provided by the sending
aggregator. Aggregate messages (LTP
blocks) are transmitted according to the
aggregation size limit setting.
Verify that
TransmissionSessionCompletion.indication
indications are issued for each of the
client SDUs.
Receiver correctly demultiplexes the
messages provided by the sending
aggregator. Aggregate messages (LTP
blocks) are transmitted according to the
aggregation time setting.
Verify that
TransmissionSessionCompletion.indication
indications are issued for each of the
client SDUs.
RLEXC_R
10,000
-
None
1200
None (only
checkpoint
end of Red
Part)
Drop the link in at least the forward
direction after the first report but
before the report acknowledgement
segment ; provide no link queue to
either the sender or receiver (elicit
retransmissions of reports (from
receiver) segments; cause
retransmission limit exceeded RLEXC)
RXMTCYC
EXC_S
Turn the error rate up, size up, and
segment size down and then jack with
the MAXRXMTCYC value for the
transmitter (set way below that of the
receiver)
RXMTCYC
EXC_R
Turn the error rate up, size up, and
segment size down and then jack with
the MAXRXMTCYC value for the
receiver (set way below that of the
transmitter
Report segments are retransmitted by the
sender until the retransmission limit is
exceeded. When the retransmission limit
is exceeded the session is terminated (and
a cancellation segment is sent?)
4.2 Mapping tests to Requirements
Table XXXX maps the tests to the requirements
Table 3: Mapping of Tests to Requirements
For the time being, use the Excel Spreadsheet
5 Tests
5.1 Basic1: Send a single red-part data segment
Red-Part
Green-Part
Latency
Error Rate
Data Rate
LTP Segment Size
100 Bytes
N/A
500ms one-way latency
No artificially-imposed errors
No artificially-imposed data rate restriction
1200 Bytes
6 Test Artifacts
The following test artifacts XXX_FIXME_WERE_XXX generated to accompany this test report:





The Python LTP implementation
An implementation of XXX_FIXME_LTPlib_XXX modified to conform to the LTP-for-CCSDS profile.
Test infrastructure (all the scripts required to execute the tests)
Extensions to the Python Scapy packet processing infrastructure to parse ltp and CCSDS
Encapsulation packets
Results of each test run, including
o Packet captures at sending and receiving interfaces
o Log files from the various software instances
o Post-run analyses according to the test infrastructure
7 Issues Identified During Testing
7.1 Sender Response to RS from Closed Sessions
Once an LTP sender receives enough reception claims to cover the red-part of a block and has
transmitted all of the block data at least once, it will close the transmit session. This means that the
sender will no longer have a record of the destination LTP Engine ID for that session and, as a result, can
not respond to future RS from the receiver. This is an issue if the RA for the last RS is lost. The receiver
will continue to retransmit RS until the retransmission limit is exceeded, then will start sending CS
(which will be retransmitted, since the LTP sender won’t respond to those either).
An implementation optimization to address this would be to keep, at the LTP sender, information about
the mapping between session IDs and destination LTP engine IDs for some number of closed sessions. In
this way, RA segments could be sent in response to retransmitted RS.
An approach that would require modification of the specification would be to include the receiving LTP
engine ID in (at least some) segments sent by the LTP receiver to the LTP sender. If, for example, report
segments contained the LTP Engine ID of the receiver, then the sender could respond to them even if
the sending session had been closed. In this case there would still be the issue of HOW to respond,
especially if the memory of closed session described above was not also implemented (e.g. a new cancel
session reason – ‘No xmit session’?).
7.2 LTPLib Receiver Wants SessionOriginator to be IP address of session
originator
And it WILL use the SDNV representation if it doesn’t like the SessionOriginator (e.g. ‘6’) that it receives
in a CP segment.
7.3 SessionOriginator in SessionID of Report Segments Should Be What?
Should this be the SessionID of the LTP block sender or the LTP block receiver?
7.4 LTPLib Indications
LTPLib doesn’t seem to produce the full suite of indications in the LTP-for-CCSDS Service specification.
7.5 LTPLib Timer Suspension / Resumption
LTPLib doesn’t support timer suspension / resumption in response to link cues.
7.6 RXMTCYCEXC and ‘Progressive Checkpointing’
If an implementation sends checkpoints every X bytes say, then it needs to be careful about the value of
RXMTCYCEXC. In particular, the implementation needs to count retransmissions of PARTICULAR reports,
not just total number of reports sent.
7.7 LTPLib sender sends Cancel after green segment (Green Part of Block?);
Python_LTP does NOT seem to respond with a Cancel-ACK
References
[RFC5326]
Ramadas, M., and Burleigh, S., and S. Farrell, Licklider Transmission Protocol –
Specification, RFC5326
[RFC5327]
Farrell, S., and Ramadas, M., and S. Burleigh, Licklider Transmission Protocol – Security
Extensions, RFC5327
[LTP_CCSDS]
Licklider Transmission Protocol (LTP) for CCSDS, CCSDS Red Book, Issue 2.
[LTPlib]
Stephen Farrell’s LTPlib implementation, http://dtn.dsg.cs.tcd.ie/sft/ltplib/
[scapy]
http://www.secdev.org/projects/scapy/