ISO 15893:2010

INTERNATIONAL ISO
STANDARD 15893
Second edition
2010-09-15
Space data and information transfer
systems — Space communications
protocol specification (SCPS) —
Transport protocol (SCPS-TP)
Systèmes de transfert des informations et données spatiales —
Spécification de protocole pour communications spatiales (SCPS) —
Protocole de transport (SCPS-TP)

Reference number
©
ISO 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2010 – 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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
This second edition cancels and replaces the first edition (ISO 15893:2000), which has been technically
revised.
ISO 15893 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 714.0-B-2, October 2006) 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.

INTERNATIONAL STANDARD ISO 15893:2010(E)

Space data and information transfer systems — Space
communications protocol specification (SCPS) — Transport
protocol (SCPS-TP)
1 Scope
This International Standard specifies the requirements for the services and protocols of the space
communications protocol specification (SCPS) transport service. These requirements are meant to allow
independent implementations of this protocol in space and ground segments of the SCPS network to
interoperate.
This International Standard is applicable to any kind of space mission or infrastructure, regardless of
complexity.
The scope and field of application are further detailed in subclauses 1.2 and 1.3 of the enclosed CCSDS
publication.
2 Requirements
Requirements are the technical recommendations made in the following publication (reproduced on the
following pages), which is adopted as an International Standard:
CCSDS 714.0-B-2, October 2006, Space communications protocol specification (SCPS) — Transport protocol
(SCPS-TP)
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 714.0-B-2.
Pages i to v
This part is information which is relevant to the CCSDS publication only.
Page 1-8
Add the following information to the reference indicated:
[10] Document CCSDS 713.0-B-1, May 1999, is equivalent to ISO 15891:2000.
[11] Document CCSDS 713.5-B-1, May 1999, is equivalent to ISO 15892:2000.
3 Revision of publication CCSDS 714.0-B-2
It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee
ISO/TC 20/SC 13 will be consulted in the event of any revision or amendment of publication
CCSDS 714.0-B-2. To this end, NASA will act as a liaison body between CCSDS and ISO.
(blank page)
2 © ISO 2010 – All rights reserved

Recommendation for Space Data System Standards
SPACE COMMUNICATIONS
PROTOCOL SPECIFICATION (SCPS)—
TRANSPORT PROTOCOL
(SCPS-TP)
RECOMMENDED STANDARD
CCSDS 714.0-B-2
BLUE BOOK
October 2006
(blank page)
4 © ISO 2010 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
AUTHORITY
Issue: Recommended Standard, Issue 2
Date: October 2006
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 Recommendations is detailed in the Procedures Manual
for the Consultative Committee for Space Data Systems, and the record of Agency
participation in the authorization of this document can be obtained from the CCSDS
Secretariat at the address below.

This document is published and maintained by:

CCSDS Secretariat
Office of Space Communication (Code M-3)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 714.0-B-2 Page i October 2006
CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
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 714.0-B-2 Page ii October 2006
6 © ISO 2010 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
FOREWORD
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommendation is therefore subject to
CCSDS document management and change control procedures as defined in reference [B1].
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 addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 714.0-B-2 Page iii October 2006
CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
At time of publication, the active Member and Observer Agencies of the CCSDS were:

Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– British National Space Centre (BNSC)/United Kingdom.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (Roskosmos)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.

Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– Centro Tecnico Aeroespacial (CTA)/Brazil.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Danish Space Research Institute (DSRI)/Denmark.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– 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.
– MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic & Atmospheric Administration (NOAA)/USA.
– National Space Organization (NSPO)/Taipei.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.

CCSDS 714.0-B-2 Page iv October 2006
8 © ISO 2010 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Communications May Original issue, superseded
714.0-B-1 Protocol Specification 1999
(SCPS)—Transport Protocol
(SCPS-TP)
CCSDS Space Communications October Current issue:
714.0-B-2 Protocol Specification 2006 – adds optional support for
(SCPS)—Transport Protocol Selective Acknowledgements
(SACK) and Explicit
(SCPS-TP), Recommended
Congestion Notification
Standard, Issue 2
(ECN);
– defines semantics to extend
SCPS-TP signaling to allow
optional inclusion of vendor-
and community-specific
options;
– clarifies some ambiguities in
the original specification
regarding:
• inclusion/position of
compressed short-form
SNACK options in
compressed SCPS-TP
headers (the position of the
compressed SNACK option
within the header is given);
• what connection identifier is
transmitted in compressed
headers (the one sent to the
peer during the SYN
exchange);
• what N-user protocol ID is
used to calculate the pseudo
header checksum when
header compression is in
use (decimal 105).
NOTE – Revision bars in the inside margin indicate changes from the previous issue.
CCSDS 714.0-B-2 Page v October 2006
CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
CONTENTS
Section Page
1 INTRODUCTION. 1-1

1.1 PURPOSE.1-1
1.2 SCOPE.1-1
1.3 APPLICABILITY.1-1
1.4 RATIONALE.1-1
1.5 ORGANIZATION OF THIS RECOMMENDATION. 1-1
1.6 HOW TO READ THIS DOCUMENT . 1-2
1.7 CONVENTIONS AND DEFINITIONS.1-3
1.8 REFERENCES.1-7

2 OVERVIEW. 2-1
3 SCPS-TP EXTENSIONS TO STANDARD TCP . 3-1

3.1 RELATIONSHIP BETWEEN SCPS-TP AND TCP . 3-1
3.2 CONNECTION MANAGEMENT.3-1
3.3 DATA TRANSFER.3-11
3.4 ERROR RECOVERY.3-16
3.5 SELECTIVE NEGATIVE ACKNOWLEDGMENT OPTION . 3-19
3.6 SCPS-TP HEADER COMPRESSION.3-25
3.7 MULTIPLE TRANSMISSIONS FOR FORWARD ERROR CORRECTION . 3-31

4 USER DATAGRAM PROTOCOL EXTENSION . 4-1
5 MANAGEMENT INFORMATION BASE (MIB) REQUIREMENTS. 5-1

5.1 TYPES OF MANAGEMENT INFORMATION.5-1
5.2 MIB REQUIREMENTS FOR ROUTE-SPECIFIC INFORMATION . 5-1
5.3 MIB REQUIREMENTS FOR SCPS TRANSMISSION CONTROL PROTOCOL5-5
5.4 MIB REQUIREMENTS FOR SCPS USER DATAGRAM PROTOCOL . 5-7

6 CONFORMANCE REQUIREMENTS . 6-1

6.1 GENERAL REQUIREMENTS.6-1
6.2 TRANSMISSION CONTROL PROTOCOL REQUIREMENTS. 6-1
6.3 USER DATAGRAM PROTOCOL REQUIREMENTS . 6-12
6.4 NETWORK MANAGEMENT REQUIREMENTS.6-14

ANNEX A SYMBOLS AND ABBREVIATIONS. A-1
ANNEX B INFORMATIVE REFERENCES .B-1
ANNEX C PROTOCOL IMPLEMENTATION CONFORMANCE
STATEMENT PROFORMA. C-1
ANNEX D SERVICES OF THE TRANSPORT PROTOCOL. D-1
CCSDS 714.0-B-2 Page vi October 2006
10 © ISO 2010 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
CONTENTS (continued)
Figure Page
3-1 SCPS Capabilities Option. 3-3
3-2 Beginning of Extended Capabilities Signaling. 3-6
3-3 Format for Extended Capabilities. 3-6
3-4 Single Extended SCPS Capabilities Option with Multiple Extended
Capability Binding Spaces. 3-8
3-1 Using Multiple SCPS Capabilities Options to Express Multiple
Extended Capabilities . 3-9
3-2 An Extended SCPS-TP capability Specified by a Binding Space
Identifier in the 256-511 Range. 3-10
3-7 Out-of-Sequence Queue for SNACK Example . 3-23
3-8 SNACK Option Resulting from Out-of-Sequence Queue Example. 3-23
3-9 SNACK Options (without SNACK Bit-Vector) Resulting from
Out-of-Sequence Queue Example . 3-24
3-10 Compressed SCPS-TP Header. 3-29
D-1 SCPS-TP Composite Service Diagram for Connection-Oriented Services. D-22
D-2 Local Service Provider State Diagram. D-23
D-3 Composite SCPS-TP Service State Diagram for Connection-Oriented
Types of Service . D-24
D-4 State Diagram for Unacknowledged Service. D-25

Table
1-1 Values of the N-User_Internet_Protocol_Number Parameter Used by SCPS-TP . 1-6
3-1 SCPS Capabilities Option Bit-Vector Contents. 3-4
3-2 Compressed Header Bit-Vector Contents. 3-26
D-1 SCPS-TP Services and Types of Service. D-2
D-2 SCPS-TP Data Transport Characteristics . D-4
D-3 Specific SCPS-TP Data Transfer Capabilities. D-6
D-4 SCPS-TP Service Request Primitives. D-7
D-5 SCPS-TP Service Confirm and Indication Primitives . D-15

CCSDS 714.0-B-2 Page vii October 2006
(blank page)
12 © ISO 2010 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
1 INTRODUCTION
1.1 PURPOSE
The purpose of this Recommendation is to define the services and protocols that provide the
Space Communications Protocol Specification (SCPS) Transport service. This definition
will allow independent implementations of the protocols in the space and ground segments of
the SCPS Network to interoperate.
1.2 SCOPE
This Recommendation is intended to be applied to all systems that claim conformance to the
SCPS Transport protocols.
1.3 APPLICABILITY
This Recommendation is designed to be applicable to any kind of space mission or
infrastructure, regardless of complexity. It is intended that this Recommendation become a
uniform standard among all CCSDS Agencies.
1.4 RATIONALE
The CCSDS believes it is important to document the rationale underlying the
recommendations chosen, so that future evaluations of proposed changes or improvements
will not lose sight of previous decisions. The concept and rationale for SCPS-TP may be
found in reference [B2].
1.5 ORGANIZATION OF THIS RECOMMENDATION
This Recommendation contains six sections and four annexes. This section presents
introductory material that establishes the context for the remainder of the document. Section 2
contains an overview of the protocols, summarizing the main technical requirements and
describing the approach used to provide the protocols’ services. Sections 3 and 4 present the
specifications for Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)
in the SCPS environment. Section 5 establishes the requirements for maintaining
management information. Section 6 presents conformance requirements for implementations.
The four annexes to this Recommendation provide supporting information. Some of the
annexes contain normative material, while some contain informative material. Annex A is
informative and contains the acronyms and abbreviations used commonly throughout the
document. Annex B is informative and contains the informative references cited throughout
the document. Annex C is normative and contains the proforma for the Protocol
Implementation Conformance Statement (PICS). The PICS unambiguously describes the
capabilities provided by an implementation of the protocol. Annex D is normative and
contains the service specification.
CCSDS 714.0-B-2 Page 1-1 October 2006
CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
1.6 HOW TO READ THIS DOCUMENT
This document makes modifications and extensions to TCP and UDP for use in spacecraft
communications environments, characterized by potentially long delays, unbalanced
forward- and return-link data rates, and potentially high error rates. It is anticipated that
some readers of this document will be protocol implementers, probably with TCP
implementation experience. Other readers will be individuals more familiar with the
particular application environment than with the protocols.
For readers and implementers already familiar with the internals of TCP and UDP, this
document may best be used in the following manner:
1) Review section 6 of this document. It describes the implementation requirements for
TCP and UDP, and gives an indication of those capabilities within TCP and UDP that
have been modified (indicated by text to the effect ‘as amended by a.b.c of this
document’, where a.b.c is a section reference in this document).
Also in section 6 is a list of mission-specific capabilities that, depending on the needs
of the mission, may be beneficial to add to the basic functionality of the protocols.
Section 6 provides an introduction to these capabilities, and pointers back to sections
3 and 4, in which the capabilities are specified. Readers should use section 6 as a
means of identifying the capability set required for their mission(s).
Some of the capabilities required for a mission depend on the availability of other
capabilities. These dependencies, along with a restatement of the implementation
requirements, are documented in table form in the Protocol Implementation
Conformance Statement that appears in annex C. Annex C specifies the format in
which an implementer must document the details of his or her implementation.
2) Review sections 3 and 4, which specify SCPS-TP-unique options and modifications
for TCP and UDP.
3) Review section 5, which identifies the management information requirements.
For readers and implementers who are generally familiar with the operation of TCP and
UDP, but not the internals of the protocols, the following approach to reviewing this
document may be useful:
1) Read over the UDP and TCP RFCs. The UDP specification is quite short (3 pages).
The TCP specification is significantly longer, but also provides a substantial amount
of background information. These documents were written in 1980 and 1981,
respectively.
2) Read section 4 of RFC 1122. This document captures the ‘lessons learned’ from
using TCP and UDP as of 1989. In addition to placing requirements on
implementations of TCP and UDP, it provides a significant amount of explanatory
information and discussion about rationale for particular requirements. RFC 1122
constitutes an extension to the base TCP and UDP specifications, in addition to
describing implementation requirements.
CCSDS 714.0-B-2 Page 1-2 October 2006
14 © ISO 2010 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
3) Read over section 6 of this document. It refers to the TCP and UDP RFCs and to
RFC 1122, and either endorses or revises the requirements put forward in RFC 1122.
Read the ‘Mission-Specific Capabilities’ subsection, and identify whether any of
these capabilities are necessary. If so, review the references identified in each of the
mission-specific capability sections.
4) Finally, read sections 3 through 5.
Readers with little previous familiarity with TCP or UDP should consider reviewing an
introductory text on the subject. One excellent example is TCP/IP Illustrated, Volume 1, by
W. Richard Stevens (Copyright 1994, Addison-Wesley Professional Computing Series).
Chapters 1, 11, and 17-24 are particularly relevant. Note that additional information about
one of the mission-specific capabilities—the modifications to TCP to support Transactions—
is presented in Chapters 1-12 of TCP/IP Illustrated, Volume 3, by W. Richard Stevens
(Copyright 1996, Addison-Wesley Professional Computing Series).
1.7 CONVENTIONS AND DEFINITIONS
1.7.1 OCTET NUMBERING CONVENTION AND NOMENCLATURE
This document does not deal with transmission of any data elements smaller than one octet.
As such, the transmission order of bits within an octet is an issue to be dealt with at lower
layers. However, the relative ordering of octets within a word and the unambiguous
numbering of bits within an octet are relevant here. The order in which multi-octet fields
defined in this document are submitted for transmission is called ‘Big Endian’ byte ordering.
When applied to networking, it is called ‘network byte order’. In this ordering scheme, bit 0
of a 32-bit value is the most significant bit; bit 31 is the least significant bit. The octet
containing bits 0-7 is transmitted first, followed by the octet containing bits 8-15, followed
by the octet containing bits 16-23, and finally the octet containing bits 24-31. Note that ‘Big
Endian’ byte ordering is NOT what some machines (notably the 80x86 class of machines)
use internally. Implementers must ensure that headers are converted to network byte order
for transmission.
The following conventions apply throughout this Recommendation:
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.
CCSDS 714.0-B-2 Page 1-3 October 2006
CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
1.7.2 DEFINITIONS
Address Family: An address family specifies the structural rules required to interpret the
internal fields of an address. The SCPS Network supports three address families: the SCPS
address family, the Internet Protocol (IP) address family, and the Internet Protocol version
Six (IPv6) address family.
Address Type: An address type defines the meaning that the addresses have (that is, whether
they identify end systems or a path between end systems), the number of addresses that
appear in a SCPS Network Protocol header (two addresses if the addresses identify end
systems, only one if the address identifies a path between end systems), and the address
family that is valid for the addresses.
Connection: A connection is defined by information that is named, persistent, and shared
across the systems supporting an instance of communication. For transport protocols, these
systems are the endpoints that terminate the transport protocol, but not intermediate systems.
End System: An addressable network entity within the SCPS Network.
Extended End System Address: The Extended End System Address identifies a single end
system or an end-system group. The Extended End System Address conforms to the
structural rules of either the SCPS Address Family or the IP Address Family. Extended End
System Addresses may be parameters to the primitives of the Unit Data service.
Gateway: A network-addressable system that terminates a protocol at a given layer and
invokes similar services at the same layer of an adjacent network.
Host: A network-addressable system that may send or receive network-layer packets, but
does not forward packets.
Internet Protocol Number: The Internet Protocol Number is the transport protocol
identifier used by Internet Protocols. Values may range from 0 through 255, and valid values
are defined in reference [1].
IP Address Family: The IP Address Family specifies a set of structural rules for the
interpretation of Extended End System Addresses, and is defined in reference [1], and the
possible formats are refined in section 3.2.1.3 of RFC 1122 (reference [2]).
Maximum Segment Size: The maximum amount of user data that can be carried in a
Segment. This value is calculated by subtracting the size of the network, security, and
transport layer headers from the MTU size.
Maximum Transmission Unit: The Maximum Transmission Unit (MTU) specifies the
maximum amount of data that the subnetwork layer will accept in a single subnetwork
service request. The MTU for a route is the minimum of all known MTUs along that route.
CCSDS 714.0-B-2 Page 1-4 October 2006
16 © ISO 2010 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
NOTE – It is anticipated that this value will be known and managed as part of the routing
table information; however, techniques for dynamically discovering the MTU of
a route exist. Refer to RFC 1191, ‘Path MTU Discovery’ (reference [B3]) for
more information.
N-Address: an address in the SCPS Network. The attributes of an N-Address are the
Address Type and the Address Family.
N-Basic_Quality_of_Service parameter: The Basic Quality of Service (QOS) parameter of
the N-UNITDATA service primitives carries information necessary to provide special
network processing services for the datagram. It is a data structure that contains three sub-
parameters: precedence, routing requirements, and a program-specific field.
N-Destination_Address: The N-Destination_Address is a parameter of all of the SCPS
Network service primitives. It is an N-Address that identifies the destination end system of a
packet in the SCPS Network. The N-Destination_Address parameter must be of the
Extended End System address type, and may be of either the IP or the SCPS address family.
Network-Service Data Unit: See N-SDU.
N-Expanded_Quality_of_Service parameter: The Expanded QOS parameter provides a
mechanism for specifying ground-relevant QOS requests. The valid values of this parameter
are defined in RFC 2474 (reference [B7]).
N-SDU: The Network Service Data Unit (N-SDU) is a parameter of the Unit Data service
primitives. It is a variable-length, octet-aligned data unit of arbitrary format. The maximum
length of an N-SDU is 8145 octets.
NOTE – The maximum size of the N-SDU field is limited to the length resulting from
subtracting the maximum length of a SCPS-NP header from the maximum SCPS-
NP PDU length. The maximum length of the SCPS-NP header is 46 octets. The
length field in the SCPS-NP header is 13-bits, which allows an 8191-octet total
packet length. Therefore, the maximum size of an N-SDU that is guaranteed to fit
in a SCPS-NP PDU is 8145 octets. Local restrictions on packet size or
extensions to the protocol may further limit this size, and the maximum
implementations size of N-SDU must be documented by the implementer.
N-Source_Address: The N-Source_Address is a parameter to many of the primitives of the
SCPS network service. It is an N-Address that identifies the end system originating a packet
in the SCPS Network. The N-Source_Address must be of the Extended End System address
type and may be of either the IP or the SCPS address family. The N-Source_Address may
not be a multicast or a broadcast address.
N-Source_Timestamp parameter: The N-Source_Timestamp is a parameter of several
SCPS Network service primitives. This parameter permits the Network Service user to
provide a source timestamp to accompany the N-SDU. The Source Timestamp parameter
consists of a timestamp format field and a timestamp value field.
CCSDS 714.0-B-2 Page 1-5 October 2006
CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
N-User_Internet_Protocol_Number parameter: The N-User_Internet_Protocol_Number
is a parameter to several of the SCPS Network service primitives. The values of this
parameter used by the SCPS-TP are shown in table 1-1.
Table 1-1: Values of the N-User_Internet_Protocol_Number
Parameter Used by SCPS-TP
Internet Protocol
Network Service User Number (decimal)
TCP 6
UDP 17
Compressed TCP 105
Port: An identifier of the transport service user.
Precedence parameter: The precedence parameter is an element of the N-
Basic_Quality_of_Service parameter of the N-UNITDATA service primitives. The
precedence parameter is specified by a network service user to identify the relative
importance of this data compared to other data within the network. It is an integer with a
valid range from 0 to 15, with 0 being the lowest precedence and 15 being the highest. Local
policy may cause the user-specified precedence parameter to be overridden. The network
service user may also supply a null value for the precedence parameter, in which case the
network service would assign a default value for the precedence parameter.
Program Specific parameter: The program-specific parameter is an element of the N-
Basic_Quality_of_Service parameter that provides a mechanism for programs to carry two
bits of information in the SCPS-NP header. This information is interpreted by program-
specific extensions to the SCPS-NP and has a default value of 0.
Pseudo-Header: A pseudo-header, in TCP and UDP, is a collection of information that is
used for the purposes of checksum calculation, but not actually shipped as part of the
transport layer protocol data unit. The information in the pseudo-header consists of the
source and destination addresses, the Internet Protocol Number of the transport protocol, and
the length of the transport protocol data unit.
Router: A network-addressable system that may send, receive, or forward network-layer
packets.
Routing Requirements parameter: The Routing Requirements parameter is an element of
the N-Basic_Quality_of_Service parameter of the N-UNITDATA service primitives. The
Routing Requirements parameter has two currently defined values: ‘normal’ routing and
‘flood’ routing.
CCSDS 714.0-B-2 Page 1-6 October 2006
18 © ISO 2010 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
SCPS Network Address: A SCPS Network Address specifies one of the possible SCPS
Address formats (via the FMT-ID parameter) and the values of the parameters required by
that format.
Segment: A segment is the Protocol Data Unit of the Transmission Control Protocol (TCP).
Service-Access-Point: A Service-Access-Point (SAP) is the point at which the services of a
layer are made available to the layer above it.
Silently Discard: A packet is ‘silently discarded’ if no error message is generated (either to a
local user or to a remote user) as a result of the discard.
NOTE – The practice of silently discarding packets reduces the possibility that a
misconfigured host will uncontrollably generate erroneous traffic. The term
‘silent discard’ differs from ‘discard’ in that certain actions, such as informing
network service users about the discard, are not performed in a silent discard.
When the term ‘discard’ is used, other information must be used to determine
whether the network service user is informed.
T-SDU: The Transport Service Data Unit (T-SDU) is a parameter of several of the SCPS-TP
service primitives. It is a variable-length, octet-aligned data unit of arbitrary format. The
maximum length of a T-SDU is an implementation issue.
Timestamp Format field: The Timestamp Format field of the N-Source_Timestamp
parameter identifies the format of the source timestamp that is supplied by the Network User.
The available formats are specified in reference [10].
Timestamp Value: The Source Timestamp Value field of the N-Source_Timestamp
parameter contains the value of the timestamp that shall accompany the Network Service
Data Unit.
Transport-Service Data Unit: See T-SDU.
1.8 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommendation. At the time of publication, the editions indicated were
valid. All documents are subject to revision, and users of this Recommendation are
encouraged to investigate the possibility of applying the most recent editions of the docu-
ments indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS Recommendations.
CCSDS 714.0-B-2 Page 1-7 October 2006
CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
[1] J. Postel. Internet Protocol. STD 5, September 1981. [RFC 791, RFC 950, RFC 919,
†
RFC 922, RFC 792, RFC 1112]
[2] R. Braden. Hosts Requirements. STD 3, October 1989. [RFC 1122, RFC 1123]
[3] J. Postel. User Datagram Protocol. STD 6, August 1980. [RFC 768]
[4] J. Postel. Transmission Control Protocol. STD 7, September 1981. [RFC 793]
[5] D. Borman, R. Braden, and V. Jacobson. TCP Extensions for High Performance. RFC
1323, May 1992.
[6] P. Karn & C. Partridge. “Round Trip Time Estimation.” In Proceedings of SIGCOMM
’87: Symposium on Communications Architectures and Protocols, August 1987.
[7] V. Jacobson. “Congestion Avoidance and Control.” In Proceedings of SIGCOMM
’88: Symposium on Communications Architectures and Protocols, August 1988.
[8] J. Nagle. Congestion Control in IP/TCP Internetworks. RFC 896, January 1984.
[9] K. McCloghrie and M. Rose. Management Information Base. STD 17, March 1991.
[RFC1213]
[10] Space Communications Protocol Specification (SCPS)—Network Protocol (SCPS-NP).
Recommendation for Space Data System Standards, CCSDS 713.0-B-1. Blue Book.
Issue 1. Washington, D.C.: CCSDS, May 1999.
[11] Space Communications Protocol Specification (SCPS)—Security Protocol (SCPS-SP).
Recommendation for Space Data System Standards, CCSDS 713.5-B-1. Blue Book.
Issue 1. Washington, D.C.: CCSDS, May 1999.
[12] L. S. Brakmo, S. W. O’Malley, and L. L. Peterson. “TCP Vegas: New Techniques for
Congestion Detection and Avoidance.” In Proceedings of SIGCOMM ’94: Symposium
on Communications Architectures and Protocols, August 1994.
[13] R. Braden. T/TCP—TCP Extensions for Transactions—Functional Specification. RFC
1644, July 1994.
[14] R. Ramakrishnan, S. Floyd, and D. Black. The Addition of Explicit Congestion
Notification (ECN) to IP. RFC 3168, September 2001.
[15] M. Mathis, et al. TCP Selective Acknowledgement Options. RFC 2018, October 1996.

†
Internet Request for Comments (RFC) texts are available on line in various locations (e.g., http://ietf.org/rfc/).
In this list, Internet Standards are identified by ‘STD’ followed by the number of the standard, and RFCs are
identified by ‘RFC’ followed by the number of the RFC. RFCs comprised by Internet Standards are given in
square brackets following the citation.
CCSDS 714.0-B-2 Page 1-8 October 2006
20 © ISO 2010 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
2 OVERVIEW
This SCPS Recommendation is designed to support current communication environments
and those of upcoming missions. The modifications to the base protocols are intended to
address the communication environments and resource constraints that space-based systems
face.
The Technical Requirements for the Recommendation include:
– support for communication with full reliability, best-effort reliability, and minimal
reliability;
– efficient operation in a wide range of delay, bandwidth, and error conditions;
– efficient operation in space-based processing environments;
– support for precedence (priority) based handling;
– support for connectionless multicasting;
– support for packet-oriented applications.
The SCPS Transport Protocol (SCPS-TP) refers collectively to the protocols that provide the
full reliability, best-effort reliability, and minimal reliability services. The full reliability
service is provided by TCP. The best-effort service is provided by TCP with minor
modifications. The minimal reliability service is provided by UDP.
The SCPS-TP addresses the environmental requirements with the following extensions:
– TCP for Transactions (RFC 1644, reference [13])—reduces the handshaking
necessary to start a TCP connection and provides ‘reliable datagram’ operation to
handle command-response traffic, for very long delay environments in which it is
desirable to begin data transfer without waiting for a connection handshake;
– Window scaling (RFC 1323, reference [5])—addresses communication environments
that may have more than 65k octets of data in transit at one time;
– Round Trip Time Measurement (RFC 1323, reference [5])—addresses environments
that have high loss, changing delays, or large amounts of data in transit at one time;
– Protect Against Wrapped Sequence Numbers (RFC 1323, reference [5])—addresses
very long delay environments or very high bandwidth missions;
– Selective negative acknowledgment (adapted from RFC 1106, reference [B5])—
addresses high loss environments;
– Selective acknowledgement (RFC 2018, reference [15])—addresses high loss
environments;
– Record Boundary I
...