Licklider Transmission Protocol
Lua error in package.lua at line 80: module 'strict' not found. Licklider Transmission Protocol is a point to point protocol for the use in deep space links.
Design
LTP is designed to run directly over a data link layer (such as e.g. AOS), but 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), and 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). LTP is commonly seen as the standard underlying convergence layer protocol for the Bundle Protocol (RFC 5050), supporting a wide selection of networks.
Developed for space communication however, 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 defunct pixel can be overcome)
- no negotiation exchange due to potentially higher round trip times and to avoid link underutilisation
- energy efficiency, as it will only send if a link is available and distinguishes between important and unimportant data
- timers work together with communication schedules and can be suspended whenever a scheduled link outage occurs
- needs to be informed about link layer availability, round-trip time and communication schedule, basically requiring a management information base (MIB). LTP is highly stateful.
- unidirectional sessions, circumvents high round-trip times or inability of peer to transmit.
The application divides its data to send into two parts (however, either part may have a size of 0):
- a red part: It contains data that has to be transported reliable, 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 to be transported in a reliable fashion. Since reception of this data will not be acknowledged, it can be discarded after being sent out.
Function
The LTP engine will store the data in a queue, check whether the link towards the destination (remember, this is a point-to-point protocol) is available and if so, start the transmission. If the link is not available, it will keep the data in its queue and start transmission as soon as a so-called “link state cue” arrives, either from an underlying link layer or from a Management information base. If there was 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. If there is no 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 will issue 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 will cancel its timer and enqueue 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. More details about LTP can be found in the corresponding RFC 5325.
Reference Implementations
There are two reference implementations for LTP available
- ION written in C by the Jet Propulsion Laboratory and maintained at Ohio University.
- LTPlib is written in C by Trinity College, Dublin.
Name
LTP is named in honor of the American computer scientist Joseph Carl Robnett Licklider.
