Licklider Transmission Protocol

LTP is designed to run directly over a data link layer (e.g. the Advanced Orbiting Systems (AOS) Space Data Link Protocol^[1]). It can also run on the User Datagram Protocol (UDP), e.g. if used in a sensor network, in a private network (where bandwidth contestation isn’t an issue), or for software debug purposes. Therefore, it does not address issues like routing or congestion control. It was originally designed to support “long-haul” transmission in an interplanetary network; its design is based on experiences with the CCSDS File Delivery Protocol (CFDP).

Developed for space communication, its features are:

• Reliable data transport for important data (such as a file header)
• Unreliable data transport for less important data (such as image pixels—a damaged pixel can be overcome)
• No exchange of messages to perform negotiation. The protocol avoids this process to avoid delays due to high round-trip times. It also avoids link underutilisation.
• Energy efficiency, as it only transmits if a link is available and distinguishes between important and unimportant data.
• Its timers work together with communication schedules and can be suspended whenever a scheduled link outage occurs.
• It needs to be informed about link layer availability, round-trip time and communication schedules, basically requiring a management information base (MIB). LTP is highly stateful.
• Unidirectional transmission sessions, circumvent high round-trip times or the inability of a peer communication node to transmit

The application divides its data to send into two parts (either part may have a size of 0):

• a red part: It contains data that has to be transported reliably, has to be acknowledged by the receiver, and has to be held available until acknowledged. This could, e.g., be a header that contains important information to decode the following data, and whose corruption would render all following data useless.
• a green part. It contains data that does not require reliable transport. Since reception of this data is not acknowledged, it can be discarded after transmission.

The LTP engine stores data in a queue, checks whether the link towards the destination is available and if so, starts the transmission. If the link is not available, the data remains in queue and transmission starts as soon as a so-called “link state cue” arrives, either from an underlying link layer or from a management information base. Given red data to send, the last segment of the red data is marked with an “end of red data” flag and a timer is started for that segment. Absent green data to send, the “end of block” flag is set, otherwise the green data is transmitted and the last segment of this part gets marked with the “end of block” flag. The receiver issues a report segment for the sender once it received the “end of red data” segment and all data is complete. Once the report segment has been transmitted, a timer is started. Upon arrival of the report segment, the sender cancels its timer, queues a report-acknowledgement for the receiver and informs the application that all red data has been successfully transmitted. Once the receiver receives the report-acknowledgement it cancels its timer and the transmission of the red data is completed. The transmission is completed if the “end of block” segment has arrived.

The two reference implementations for LTP are:

• ION, written in C by the Jet Propulsion Laboratory and maintained at Ohio University.
• LTPlib, written in C by Trinity College, Dublin.

• Scapy has an LTP contrib module,^[2] contributed by the MITRE Corporation.^[3]

• RFC 5325: Licklider Transmission Protocol—Motivation
• RFC 5326: Licklider Transmission Protocol—Specification
• RFC 5327: Licklider Transmission Protocol—Security Extensions
• ION, University of Ohio
• LTPlib Trinity College