ISO 21080:2016

INTERNATIONAL ISO
STANDARD 21080
First edition
2016-07-01
Space data and information transfer
systems — Licklider transmission
protocol (LTP) for CCSDS
Données spatiales et systèmes de transfert d’information - Protocol de
transmission Licklider (LTP) pour CCSDS
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2. www.iso.org/directives
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
ISO 21080 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 734.1-B-1, May 2015) and was adopted (without modifications except those stated in clause
2 of this International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles,
Subcommittee SC 13, Space data and information transfer systems.
DEDICATION
This book is dedicated to Adrian Hooke, whose end-to-end sensibilities and tireless advocacy
for standardization of space data systems directly contributed to the formation of the
Consultative Committee for Space Data Systems in 1982. His unique combination of
technical skill, management abilities, and vision served CCSDS well for over 30 years.
During that time CCSDS solidified the standardization of Physical and Data Link Layer
protocols, and developed standards and technologies that had important and wide-ranging
impacts in both the space and terrestrial communications industries. In the late 1990s, Adrian
envisioned a new era for space communications leveraging a confluence of terrestrial
internetworking and space-based data transport technologies. This led to the development of
a concept that has come to be known as the Solar System Internetwork (SSI), of which the
Licklider Transmission Protocol described here is a part.
Adrian will be missed, by CCSDS for the scope of his technical contributions and his
leadership, and by his colleagues and friends for the greatness of his spirit and his wit. But
his legacy to the space community remains. CCSDS will continue to provide useful and
innovative solutions to space communication challenges so that Adrian’s vision of an
interoperable, standards-based communication system that reduces mission development
time, cost, and risk will eventually be realized.

CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
AUTHORITY
Issue: Recommended Standard, Issue 1
Date: May 2015
Location: Washington, DC, USA
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for
review and authorization of CCSDS documents is detailed in Organization and Processes for
the Consultative Committee for Space Data Systems (CCSDS A02.1-Y-4), and the record of
Agency participation in the authorization of this document can be obtained from the CCSDS
Secretariat at the e-mail address below.

This document is published and maintained by:

CCSDS Secretariat
National Aeronautics and Space Administration
Washington, DC, USA
E-mail: secretariat@mailman.ccsds.org
CCSDS 734.1-B-1 Page i May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. The Committee meets periodically to address
data systems problems that are common to all participants, and to formulate sound technical
solutions to these problems. Inasmuch as participation in the CCSDS is completely
voluntary, the results of Committee actions are termed Recommended Standards and are
not considered binding on any Agency.
This Recommended Standard is issued by, and represents the consensus of, the CCSDS
members. Endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever a member establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommended Standard. Establishing such a standard
does not preclude other provisions which a member may develop.
o Whenever a member establishes a CCSDS-related standard, that member will
provide other CCSDS members with the following information:
-- The standard itself.
-- The anticipated date of initial operational capability.
-- The anticipated duration of operational service.
o Specific service arrangements shall be made via memoranda of agreement. Neither
this Recommended Standard nor any ensuing standard is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this Recommended Standard will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Standard is issued, existing
CCSDS-related member standards and implementations are not negated or deemed to be
non-CCSDS compatible. It is the responsibility of each member to determine when such
standards or implementations are to be modified. Each member is, however, strongly
encouraged to direct planning for its new standards and implementations towards the later
version of the Recommended Standard.
CCSDS 734.1-B-1 Page ii May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
FOREWORD
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. CCSDS has processes for identifying patent issues and for securing
from the patent holder agreement that all licensing policies are reasonable and non-
discriminatory. However, CCSDS does not have a patent law staff, and CCSDS shall not be
held responsible for identifying any or all such patent rights.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-4). Current versions of CCSDS documents are maintained at the CCSDS
Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be sent to the CCSDS
Secretariat at the e-mail address indicated on page i.
CCSDS 734.1-B-1 Page iii May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking and
Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– Electronics and Telecommunications Research Institute (ETRI)/Korea.
– European Organization for the Exploitation of Meteorological Satellites (EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– South African National Space Agency (SANSA)/Republic of South Africa.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– Swiss Space Office (SSO)/Switzerland.
– United States Geological Survey (USGS)/USA.
CCSDS 734.1-B-1 Page iv May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
DOCUMENT CONTROL
Document Title Date Status
CCSDS Licklider Transmission Protocol May 2015 Original issue
734.1-B-1 (LTP) for CCSDS, Recommended
Standard, Issue 1
CCSDS 734.1-B-1 Page v May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
CONTENTS
Section Page
1 INTRODUCTION . 1-1

1.1 PURPOSE . 1-1
1.2 SCOPE . 1-1
1.3 ORGANIZATION OF THE DOCUMENT . 1-1
1.4 CONVENTIONS AND DEFINITIONS. 1-2
1.5 NOMENCLATURE . 1-5
1.6 REFERENCES . 1-6

2 OVERVIEW . 2-1

2.1 GENERAL . 2-1
2.2 ARCHITECTURAL ELEMENTS . 2-2
2.3 SERVICE PROVIDED BY LTP . 2-2

3 CCSDS PROFILE OF RFC 5326 . 3-1

3.1 BASE SPECIFICATIONS . 3-1
3.2 AMBIGUITY RESOLUTION . 3-1
3.3 LTP OVER UDP . 3-1
3.4 LTP FOR CCSDS . 3-1
3.5 LIMITS ON THE RANGES OF LTP FIELD VALUES . 3-2
3.6 AGENCY USE OF LTP ENGINE IDS . 3-4
3.7 GREEN-PART DATA . 3-4
3.8 LTP EXTENSIONS . 3-4
3.9 LTP SECURITY . 3-4

4 LTP SERVICE SPECIFICATION . 4-1

4.1 SERVICES AT THE USER INTERFACE . 4-1
4.2 SUMMARY OF PRIMITIVES . 4-1
4.3 SUMMARY OF PARAMETERS . 4-2
4.4 LTP SERVICE PRIMITIVES . 4-4

5 SERVICES LTP REQUIRES OF THE SYSTEM. 5-1

5.1 RELIABLE STORAGE SERVICE . 5-1
5.2 UNDERLYING COMMUNICATION SERVICE REQUIREMENTS . 5-1

CCSDS 734.1-B-1 Page vi May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
CONTENTS (continued)
Section Page
6 CONFORMANCE REQUIREMENTS . 6-1

6.1 PICS PROFORMA . 6-1
6.2 LICKLIDER TRANSMISSION PROTOCOL REQUIREMENTS . 6-1

7 CLIENT OPERATIONS . 7-1

7.1 OVERVIEW—LTP SERVICE DATA AGGREGATION (SDA) . 7-1
7.2 LTP SDA SPECIFICATION . 7-1

ANNEX A PROTOCOL IMPLEMENTATION CONFORMANCE
STATEMENT PROFORMA (NORMATIVE) . A-1
ANNEX B USING THE CCSDS SPACE PACKET OR ENCAPSULATION
SERVICE AS AN UNDERLYING COMMUNICATION SERVICE
FOR LTP (NORMATIVE) .B-1
ANNEX C LICKLIDER TRANSMISSION PROTOCOL MANAGEMENT
INFORMATION BASE (NORMATIVE) . C-1
ANNEX D SECURITY, SANA, AND PATENT CONSIDERATIONS
(INFORMATIVE) . D-1
ANNEX E INFORMATIVE REFERENCES (INFORMATIVE) .E-1
ANNEX F ACRONYMS AND ABBREVIATIONS (INFORMATIVE) . F-1
Figure
1-1  LTP’s Relationship to Neighboring Protocols . 1-3
2-1  Protocol Stack View of LTP Architectural Elements . 2-2
2-2  Communications View of LTP . 2-3
2-3  Overview of LTP Interactions . 2-4
2-4  Transmission Using Service Data Aggregation . 2-4

Table
A-1  Symbols Used in PICS ‘Status’ Column . A-2
A-2  Symbols to Be Used in PICS ‘Support’ Column . A-2
C-1  Local Engine Configuration Information .C-2
C-2  Remote Engine Configuration Information .C-3
D-1  Initial CCSDS LTP Engine ID Registry . D-5
D-2  Initial CCSDS LTP Client Service ID Number Registry . D-6

CCSDS 734.1-B-1 Page vii May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
1 INTRODUCTION
1.1 PURPOSE
This document defines a Recommended Standard for the CCSDS Licklider Transmission
Protocol (LTP) and associated service for application in the space environment. LTP
provides optional reliability mechanisms on top of an underlying (usually data link)
communication service.
1.2 SCOPE
LTP is intended for use over the current and envisaged packet delivery services used in the
space environment, including:
– CCSDS conventional packet telecommand;
– CCSDS conventional packet telemetry.
For space data links, LTP will typically be deployed over a CCSDS data link that supports
CCSDS Encapsulation Packets so that one LTP segment can be encapsulated in a single
Encapsulation Packet. LTP may also operate over a wide variety of ground-network services
including those specified by the CCSDS for cross-support purposes.
1.3 ORGANIZATION OF THE DOCUMENT
This Recommended Standard is organized as follows:
a) Section 2 contains a descriptive overview of LTP operation as well as a brief history
of the protocol’s heritage. Users not already familiar with LTP may want to start
with this section.
b) Section 3 contains a profile of RFC 5326 (reference [3]) for use by CCSDS.
c) Section 4 contains the abstract service specification for LTP.
d) Section 5 specifies the services that LTP requires from the underlying system.
e) Section 6 contains conformance requirements for the CCSDS profile of LTP.
f) Section 7 defines a client operations service that allows multiple layer-(N+1) SDUs to
be aggregated into a single LTP block in order to improve efficiency.
g) Annex A contains the Protocol Implementation Conformance Statement (PICS)
proforma.
h) Annex B specifies how to layer LTP over the CCSDS Space Packet Service or the
CCSDS Encapsulation Service.
i) Annex C contains the Management Information Base (MIB) for the protocol.
CCSDS 734.1-B-1 Page 1-1 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
j) Annex D discusses security, SANA, and patent considerations related to the
specification.
k) Annex E is a list of informative references.
l) Annex F is a list of abbreviations and acronyms that appear in the document.
1.4 CONVENTIONS AND DEFINITIONS
1.4.1 TERMS
1.4.1.1 Definitions from OSI Basic Reference Model
This Recommended Standard makes use of a number of terms defined in reference [1]. The
use of those terms in this Recommended Standard is to be understood in a generic sense, i.e.,
in the sense that those terms are generally applicable to any of a variety of technologies that
provide for the exchange of information between real systems. Those terms are:
– entity;
– Protocol Data Unit (PDU);
– service;
– Service Access Point (SAP);
– Service Data Unit (SDU).
Figure 1-1 illustrates the relationship of the LTP protocol defined in this document and
protocols at the layers above and below LTP. From the point of view of protocols above
LTP (e.g., Bundle Protocol), the service LTP provides is optionally reliable delivery of layer-
(N+1) PDUs across a link. For LTP, the interface to the data link is via either direct
encapsulation in CCSDS Space Packets or via the CCSDS Encapsulation Service.
Figure 1-1 illustrates the general service user-service provider relationships among layers.
For the specific case of LTP in the CCSDS stack, the LTP service sits between the Data Link
Layer and the Network Layer.
CCSDS 734.1-B-1 Page 1-2 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
Layer‐N Service  Layer‐N Service
Layer (N+1)
User Layer-(N+1) PDUs User
(e.g., BP) (e.g., BP)
Layer‐
(N+1) PDUs
Layer-N Service Interface
Layer‐
(N+1) PDUs
Layer-N
Layer‐N Service Provider  Layer‐N Service Provider
Layer (N)
PDUs
(e.g., LTP)  (e.g., LTP)
Layer-(N-1) Service Interface
Layer‐(N‐1) Service Provider
Layer (N‐1)
(e.g., CCSDS Encapsulation Packets)

Figure 1-1: LTP’s Relationship to Neighboring Protocols
1.4.1.2 Definitions from Open Systems Interconnection (OSI) Service Definition
Conventions
This Recommended Standard makes use of a number of terms defined in reference [2]. The
use of those terms in this Recommended Standard is to be understood in a generic sense, i.e.,
in the sense that those terms are generally applicable to any of a variety of technologies that
provide for the exchange of information between real systems. Those terms are:
– indication;
– primitive;
– request;
– response.
1.4.1.3 Definitions from RFC 5326
This Recommended Standard makes use of a number of terms defined in reference [3].
Some of the definitions needed for section 2 of this document are reproduced here for
convenience.
engine ID: An integer that uniquely identifies a given LTP engine, within some closed set of
communicating LTP engines.
NOTE – When LTP is operating underneath the Delay-Tolerant Networking (DTN)
Bundle Protocol (BP), the convergence layer adapter mediating the two will be
responsible for translating between DTN endpoint IDs and LTP engine IDs in an
implementation-specific manner.
CCSDS 734.1-B-1 Page 1-3 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
block: An array of contiguous octets of application data handed down by the upper layer
protocol (typically BP) to be transmitted from one LTP client service instance to another.
Any subset of a block comprising contiguous octets beginning at the start of the block is
termed a ‘block prefix’, and any such subset of the block ending with the end of the block is
termed a ‘block suffix’.
red-part: The block prefix that is to be transmitted reliably, i.e., subject to acknowledgment
and retransmission.
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.
session: A thread of LTP protocol activity conducted between two peer engines for the
purpose of transmitting a block. Data flow in a session is unidirectional: data traffic flows
from the sending peer to the receiving peer, while data-acknowledgment traffic flows from
the receiving peer to the sending peer.
sender: The data-sending peer of a session.
receiver: The data-receiving peer of a session.
client service instance: A software entity, such as an application or a higher-layer protocol
implementation, that is using LTP to transfer data.
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. Each LTP segment is of one of the
following types: data segment, report segment, report-acknowledgment segment, cancel
segment, cancel-acknowledgment segment.
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).
end of red-part, EORP: The segment transmitted as part of the original transmission of a
block containing the last octet of the block’s red-part. This data segment also indicates that
the segment’s upper bound is the length of the block’s red-part (in octets).
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’.
client service ID: Numeric identifier of the upper-level service to which the segment is to be
delivered by the receiver. It is functionally analogous to a TCP port number. If multiple
CCSDS 734.1-B-1 Page 1-4 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
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.
self-delimiting numeric value, SDNV: A representation of integer values in binary format
where the length of the representation is a function of the value being represented.
NOTE – Definition (20) of RFC 5326 (reference [3]) or RFC 6256 (reference [E4]) can be
consulted for additional explanation and examples.
1.4.1.4 Other Definitions
application process identifier, APID: Part of the path ID used to identify a logical data
path for CCSDS Space Packets.
underlying communication protocols, UCP: The communication protocols used by LTP to
transfer segments between LTP engines.
1.5 NOMENCLATURE
1.5.1 NORMATIVE TEXT
The following conventions apply for the normative specifications in this Recommended
Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
1.5.2 INFORMATIVE TEXT
In the normative sections of this document, informative text is set off from the normative
specifications either in notes or under one of the following subsection headings:
– Overview;
– Background;
– Rationale;
– Discussion.
CCSDS 734.1-B-1 Page 1-5 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
1.6 REFERENCES
The following publications contain provisions which, through reference in this text,
constitute provisions of this document. At the time of publication, the editions indicated
were valid. All publications are subject to revision, and users of this document are
encouraged to investigate the possibility of applying the most recent editions of the
publications indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS publications.
[1] Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. 2nd ed. International Standard, ISO/IEC 7498-1:1994. Geneva: ISO,
1994.
[2] Information Technology—Open Systems Interconnection—Basic Reference Model—
Conventions for the Definition of OSI Services. International Standard, ISO/IEC
10731:1994. Geneva: ISO, 1994.
[3] M. Ramadas, S. Burleigh, and S. Farrell. Licklider Transmission Protocol—
Specification. RFC 5326. Reston, Virginia: ISOC, September 2008.
[4] S. Farrell, M. Ramadas, and S. Burleigh. Licklider Transmission Protocol—Security
Extensions. RFC 5327. Reston, Virginia: ISOC, September 2008.
[5] “Port Numbers.” Internet Assigned Numbers Authority. Internet Corporation for
Assigned Names and Numbers. http://www.iana.org/assignments/port-numbers.
[6] “Licklider Transmission Protocol Engine Identifiers.” Space Assigned Numbers
Authority. http://sanaregistry.org/r/ltp_engineid/.
[7] K. Scott and M. Blanchet. Licklider Transmission Protocol (LTP), Compressed Bundle
Header Encoding (CBHE), and Bundle Protocol IANA Registries. RFC 7116. Reston,
Virginia: ISOC, February 2014.
[8] “Licklider Transmission Protocol (LTP) Parameters.” Internet Assigned Numbers
Authority. Internet Corporation for Assigned Names and Numbers.
http://www.iana.org/assignments/ltp-parameters/ltp-parameters.xhtml.
[9] Encapsulation Service. Issue 2. Recommendation for Space Data System Standards
(Blue Book), CCSDS 133.1-B-2. Washington, D.C.: CCSDS, October 2009.
[10] “Protocol Identifier for Encapsulation Service.” Space Assigned Numbers Authority.
http://sanaregistry.org/r/protocol_id/.
[11] Space Packet Protocol. Issue 1. Recommendation for Space Data System Standards
(Blue Book), CCSDS 133.0-B-1. Washington, D.C.: CCSDS, September 2003.
[12] “Space Packet Protocol Application Process Identifier (APID).” Space Assigned Numbers
Authority. http://sanaregistry.org/r/space_packet_protocol_application_process_id/.
CCSDS 734.1-B-1 Page 1-6 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
2 OVERVIEW
2.1 GENERAL
CCSDS has identified requirements for a protocol to sit between an internetworking protocol
such as the Bundle Protocol (reference [E1]) and the various CCSDS data links (see
reference [E3]). The two requirements identified in reference [E3] for such a layer-N
protocol are reliable delivery of layer-(N+1) PDUs and the ability to aggregate multiple layer
(N+1) PDUs into a single layer-N PDU for the purposes of reliable delivery across the link.
Reliable data delivery is accomplished by the red-part delivery service of the LTP protocol
described in section 3 of this document. Aggregation of multiple layer-(N+1) SDUs into a
single layer-N PDU (LTP block) is achieved by the implementation of the standardized
‘Service Data Aggregation’ client operation described in section 7. Such an adaptor is
envisaged by figure 2-4 of reference [E3], which lists an ‘LTP/ENCAP Convergence Layer
Adaptor’ as a work item. The rationale for aggregating multiple layer-(N+1) PDUs into a
single layer-N PDU for the purposes of reliable delivery is that it may allow the system to
reduce the acknowledgement-channel bandwidth in the case that the layer-(N+1) (and
higher) protocols transmit many small PDUs, each of which might otherwise require
independent acknowledgement.
The Licklider Transmission Protocol (LTP) sits between the Data Link and the Network
Layers of the ISO stack and provides optionally reliable communications over a single data
link hop. While LTP can be deployed over multi-hop services (e.g., UDP) on the ground,
this document recommends that LTP be terminated at the ends of each long-delay, error-
prone, or disruption-prone link (such as a space link) in what might be a multi-hop path.
Thus when considering LTP’s suitability for use on space links, it is enough to consider its
functionality, its scalability to multiple 1-hop peers, and its interaction with other protocols
on a single space link. The main restriction on LTP’s scalability to multiple peers is the
storage required to maintain data for retransmission between contacts to a particular peer.
Because of the sparseness of space communications, it is not envisioned that this scalability
with the number of peers will be an issue.
LTP was originally developed for space communication and is largely derived from the
Acknowledged-mode procedures of the CCSDS File Delivery Protocol (CFDP). The
protocol specification below is a reproduction of the Internet Engineering Task Force (IETF)
Request for Comments (RFC) 5326, Licklider Protocol Specification. A separate
motivational RFC (reference [E2]) provides the motivation behind the IETF specification of
the protocol and may be informative in this context.
The IETF’s classification of the Licklider Transmission Protocol RFC as ‘experimental’
should be considered in the context of LTP’s deployment on the global Internet, where
millions of end systems are exchanging millions of data flows at any given instant, and
where protocols such as LTP are typically thought of as ‘transport’ or ‘end-to-end’ protocols
operating across multiple data links. In the Internet context, issues such as scalability to
millions of nodes, congestion control, and non-destructive coexistence with other established
protocols (in particular the Transmission Control Protocol [TCP]), are of extreme
CCSDS 734.1-B-1 Page 2-1 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
importance. The specification’s status as ‘experimental’ for use in the Internet is
independent of and orthogonal to its applicability for space use. As stated above, because
this document recommends LTP for use over individual space links, the scalability concerns
associated with LTP deployment in the Internet do not pertain to CCSDS.
While LTP could be used as a bearer mechanism for cross-support between CCSDS
Agencies across the Internet, it is more likely that Internet protocols such as TCP mentioned
above would be used for that purpose, in part because of the issues that cause LTP to be
marked as ‘experimental’ for use in the Internet.
2.2 ARCHITECTURAL ELEMENTS
The architectural elements of LTP are depicted in figure 2-1.
Client Service
Instance
LTP Engine
Storage MIB
Underlying
Communication
Protocols
Figure 2-1: Protocol Stack View of LTP Architectural Elements
2.3 SERVICE PROVIDED BY LTP
2.3.1 GENERAL
LTP provides a data transmission service to move blocks of data from one LTP engine to
another, where in general the two engines are resident in separate data systems, often with a
single connecting space link.
Each block consists logically of two parts, either of which may be of length zero. The first
part, termed the ‘red-part’, is transmitted reliably between LTP entities, using
acknowledgements and retransmissions to ensure that the entire red-part is received reliably
at the receiver; this provides a reliable transmission service. The second part of the block,
termed the ‘green-part’, consists of data to be transmitted unreliably. Data in the green-part
is not subject to acknowledgements and retransmissions and therefore provides an unreliable
service. The LTP Client Service Instance controls what data in a block is ‘red’ and what is
CCSDS 734.1-B-1 Page 2-2 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
‘green’. A Client Service Instance that desires completely reliable data transfer must
therefore specify that all of the data be sent as ‘red’ (reliable) data. In this specification, the
ability to send/receive green-part data is optional. However, if green-part capability is
supported, then both transmission and reception must be supported. Block transmission may
span periods of disconnection. During these periods, retransmission timers maintained by
LTP are suspended.
As depicted in figure 2-2, below, the data transmission procedures constitute the interaction
between two LTP engines. LTP uses an underlying communication service as described in
5.2 to transmit and receive LTP segments.
Client Service  Client Service
Client Service  Client Service
CliInenstant Sercevice  CInliesntta nSercevice
Instance Instance
Instance Instance
Data Transmission
LTP Engine LTP Engine
Procedures
Underlying  Underlying
Communication  Communication
Protocols Protocols
Figure 2-2: Communications View of LTP
Figure 2-3 illustrates an LTP block transmission operation involving both red (reliable) and
green (unreliable) parts. In the figure, the sender generates an asynchronous checkpoint
(third red segment) to which the receiver responds with a report segment. The segment
containing the EORP is lost, as well as the second green-part segment. The EORP segment
is retransmitted; the lost green segment is not.
Section 7 of this document describes LTP Service Data Aggregation (SDA). SDA reduces
the acknowledgement overhead associated with multiple small red LTP blocks by
aggregating them together for the purposes of transmission and reporting. Figure 2-4
illustrates the operation of LTP when using Service Data Aggregation.
CCSDS 734.1-B-1 Page 2-3 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL

Sending LTP  Sending LTP  Receiving Receiving
Client Engine LTP Engine LTP Client
Transaction.
R
request
R
G
R
SessionStart.indication
R
SessionStart.indication
R
R
R
R
R
R
R
R
G
G
InitialTransmission
G
Complete.indication
G
G
GSArrival.
R
indications
G
G
R
R
RedPartReception.
TransmissionSession
indication
Complete.
indication CP Checkpoint
RS Report Segment
RA Report Acknowledgment
EORP End of Red Part
EOB End of Block
Lost Segment
Green segment for
G
Client Service ID Y
Red Part Reception
R
to Client Service ID Y
Figure 2-3: Overview of LTP Interactions
Sending SDA  SDA LTP Client Sending LTP  Receiving SDA LTP Client Receiving SDA
Client Engine LTP Engine Client
CP Checkpoint
R1
RS Report Segment
RA Report Acknowledgment
R2
EORP End of Red Part
EOB End of Block
R3
LTP Block containing
R4 R2
data ‘R2’ to client
service ID Y
1, R1
LTP SDA Capsule to
X, R1
client service ID X
3, R2
3, R3 1, R1
LTP Block containing
3, R2
LTP Service Data
1, R4
3, R3
Aggregation Capsules
1, R4
R
SessionStart.indication
R
SessionStart.indication
R
R
R
R
R
R
InitialTransmission R
R
Complete.indication
InitialTransmission R
Complete.indication
R 1, R1
3, R2
TransmissionSession
Complete.
3, R3
indication
1, R4
R1
RedPartReception.
R2
indication
R3
R4
Figure 2-4: Transmission Using Service Data Aggregation
CCSDS 734.1-B-1 Page 2-4 May 2015
Transaction.
requests
1 3 3 1
Transaction.
request
Y
Y
Y
1 3 3 1
RedPartReception.
indications
RedPartReception.
indication
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
2.3.2 SERVICES NOT PROVIDED BY LTP
LTP does not provide an ‘in-order delivery’ service between different LTP blocks. That is,
the order of arrival of LTP blocks may not be the order in which they were submitted to the
sending LTP engine for transmission. This is especially true when multiple blocks are sent
concurrently, as retransmissions of segments from the first block may cause the (red part of)
that block to be delivered to the destination LTP client after a block that started transmission
later.
NOTES
1 If in-order delivery is desired, the Delay-Tolerant Payload Conditioning (DTPC)
service of the Bundle Protocol for CCSDS should be considered.
2 A sending LTP client application can ensure in-order delivery of a sequence of LTP
blocks at the cost of performance by waiting for confirmation of the delivery of block
N to the receiver (a TransmissionSessionCompletion.indication, see section 4.4.9)
before submitting block N+1 for transmission.
2.3.3 ADDRESSING
For CCSDS, every LTP engine deployed in space will have a unique engine ID. At each
LTP engine location, address look-up capabilities are provided using information contained
in the associated MIB. This look-up capability provides translation between the engine ID
and the information needed to communicate with that engine using the UCP, which may in
reality be an IP address, radio device buffer, APID, virtual channel number, or other
implementation-specific mechanism.

CCSDS 734.1-B-1 Page 2-5 May 2015
CCSDS RECOMMENDED STANDARD FOR LICKLIDER TRANSMISSION PROTOCOL
3 CCSDS PROFILE OF RFC 5326
3.1 BASE SPECIFICATIONS
3.1.1 This document adopts the Licklider Transmission Protocol (LTP) as specified in
Internet RFC 5326 (reference [3]), with the constraints and exceptions specified in section 3
of this document.
3.1.2 This document adopts the Licklider Transmission Protocol security extensions as
specified in Internet RFC 5327 (reference [4]) with the constraints and exceptions specified
in section 3 of this document.
3.2 AMBIGUITY RESOLUTION
Ambiguities or contradictions between the text of section 3 and the text of RFC 5326 or
RFC 5327 shall be resolved in favor of the RFC.
NOTE – Section 3 of this protocol profile restricts some parameters of the LTP
specification as defined in RFC 5326, while section 7 defines a client operation
that aggregates multiple LTP segments in order to reduce the overhead of the
mechanisms LTP uses to provide reliable data transfer.
3.3 LTP OVER CCSDS SPACE LINKS
When used in support of CCSDS missions and across space links, LTP should be deployed
across individual space data links and should be terminated at the ends of each space data link.
NOTES
1 The LTP protocol was not designed to address issues associated with communication
over a concatenation of multiple space data links with heterogeneous characteristics.
2 When used with an underlying communication service, such as UDP, that provides
multi-hop data delivery, it may be desirable to extend LTP connections across
multiple hops in the underlying network. This might especially be the case for LTP
segments crossing the terrestrial Internet, for example.
3.4 LTP OVER UDP
3.4.1 This document allows UDP to be used as an underlying communication service for
LTP when deployed in private networks.
CCSDS 734.1-B-1 Page 3-1 May 2015
...