ISO 15893:2000

INTERNATIONAL ISO
STANDARD 15893
First edition
2000-09-15
Space data and information transfer
systems — Protocol specification for space
communications — Transport protocol
Systèmes de transfert des informations et données spatiales —
Spécification d'un protocole pour communications spatiales — Protocole de
transport
Reference number
©
ISO 2000
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.
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.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2000 – 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 3.
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 International Standard may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
International Standard ISO 15893 was prepared by the Consultative Committee for Space Data Systems (CCSDS)
(as CCSDS 714.0-B-1) and was adopted (without modifications except those stated in clause 3 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:2000(E)
Space data and information transfer systems — Protocol
specification for space communications — Transport protocol
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 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.
2 Conformance
This International Standard is applicable to all systems that claim conformance to the ISO/CCSDS SCPS transport
protocol.
3 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-1, May 1999, Recommendation for space data system standards — 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-1.
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 in paragraph 1.8:
[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.
4 Revision of publication CCSDS 714.0-B-1
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-1. To this end, NASA
will act as a liaison body between CCSDS and ISO.
(Blank page)
2 © ISO 2000 – All rights reserved

RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
SPACE COMMUNICATIONS
PROTOCOL SPECIFICATION (SCPS)—
TRANSPORT PROTOCOL
(SCPS-TP)
CCSDS 714.0-B-1
BLUE BOOK
May 1999
(Blank page)
4 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
AUTHORITY
Issue: Blue Book, Issue 1
Date: May 1999
Location: Newport Beach, California, 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 reference [B1], and the
record of Agency participation in the authorization of this document can be obtained from the
CCSDS Secretariat at the address below.
This Recommendation is published and maintained by:
CCSDS Secretariat
Program Integration Division (Code MT)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 714.0-B-1 Page i May 1999
CCSDS RECOMMENDATION 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 member space Agencies. 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
and are not considered binding on any Agency.
Recommendations
This Recommendation is issued by, and represents the consensus of, the CCSDS Plenary
body. Agency endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever an Agency establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommendation. Establishing such a standard does not
preclude other provisions which an Agency may develop.
o Whenever an Agency establishes a CCSDS-related standard, the Agency will provide
other CCSDS member Agencies with the following information:
-- The itself.
standard
-- 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
Recommendation nor any ensuing standard is a substitute for a memorandum of
agreement.
No later than five years from its date of issuance, this will be reviewed by
Recommendation
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 Recommendation is issued, existing CCSDS-
related Agency standards and implementations are not negated or deemed to be non-CCSDS
compatible. It is the responsibility of each Agency to determine when such standards or
implementations are to be modified. Each Agency is, however, strongly encouraged to direct
planning for its new standards and implementations towards the later version of the
Recommendation.
CCSDS 714.0-B-1 Page ii May 1999
6 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION 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-1 Page iii May 1999
CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
At time of publication, the active Member and Observer Agencies of the CCSDS were
Member Agencies
– 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.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– National Aeronautics and Space Administration (NASA)/USA.
– National Space Development Agency of Japan (NASDA)/Japan.
– Russian Space Agency (RSA)/Russian Federation.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– 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.
– Communications Research Laboratory (CRL)/Japan.
– Danish Space Research Institute (DSRI)/Denmark.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Federal Service of Scientific, Technical & Cultural Affairs (FSST&CA)/Belgium.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Industry Canada/Communications Research Centre (CRC)/Canada.
– Institute of Space and Astronautical Science (ISAS)/Japan.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Oceanic & Atmospheric Administration (NOAA)/USA.
– National Space Program Office (NSPO)/Taipei.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
CCSDS 714.0-B-1 Page iv May 1999
8 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Communications May 1999 Original issue
714.0-B-1 Protocol Specification
(SCPS)—Transport
Protocol (SCPS-TP)
CCSDS 714.0-B-1 Page v May 1999
CCSDS RECOMMENDATION 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-5
3.4 ERROR RECOVERY.3-11
3.5 SELECTIVE NEGATIVE ACKNOWLEDGMENT OPTION.3-14
3.6 SCPS-TP HEADER COMPRESSION .3-20
3.7 MULTIPLE TRANSMISSIONS FOR FORWARD ERROR CORRECTION.3-26
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 PROTOCOL .5-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-13
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-1 Page vi May 1999
10 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
CONTENTS (continued)
Figure Page
3-1 SCPS Capabilities Option .3-3
3-2 Out-of-Sequence Queue for SNACK Example.3-18
3-3 SNACK Option Resulting from Out-of-Sequence Queue Example .3-18
3-4 SNACK Options (without SNACK Bit-Vector) Resulting from
Out-of-Sequence Queue Example.3-19
3-5 Compressed SCPS-TP Header .3-24
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-21
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-1 Page vii May 1999
(Blank page)
12 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION 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-1 Page 1-1 May 1999
CCSDS RECOMMENDATION 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
CCSDS 714.0-B-1 Page 1-2 May 1999
14 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
constitutes an extension to the base TCP and UDP specifications, in addition to
describing implementation requirements.
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-1 Page 1-3 May 1999
CCSDS RECOMMENDATION 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-1 Page 1-4 May 1999
16 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION 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-1 Page 1-5 May 1999
CCSDS RECOMMENDATION 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
An identifier of the transport service user.
Port:
: The precedence parameter is an element of the N-
Precedence parameter
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.
: The program-specific parameter is an element of the N-
Program Specific parameter
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.
A pseudo-header, in TCP and UDP, is a collection of information that is
Pseudo-Header:
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.
A network-addressable system that may send, receive, or forward network-layer
Router:
packets.
The Routing Requirements parameter is an element of
Routing Requirements parameter:
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.
: A SCPS Network Address specifies one of the possible SCPS
SCPS Network Address
Address formats (via the FMT-ID parameter) and the values of the parameters required by
that format.
CCSDS 714.0-B-1 Page 1-6 May 1999
18 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
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.
[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]
†
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-1 Page 1-7 May 1999
CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
[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.
CCSDS 714.0-B-1 Page 1-8 May 1999
20 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION 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;
– Record Boundary Indication the ability to mark and reliably carry end-of-record
—
indications for packet-oriented applications;
CCSDS 714.0-B-1 Page 2-1 May 1999
CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
– Best Effort Communication—the ability for an application to select correct, in-
sequence, but possibly incomplete delivery of data;
– Header compression (adapted from RFC 1144, reference [B6])—addresses low-
bandwidth environments;
– Low-loss congestion control or optional non-use of congestion control;
– Retransmission strategies for space environments that accommodate loss due to data
corruption, link outages, and congestion.
CCSDS 714.0-B-1 Page 2-2 May 1999
22 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
3 SCPS-TP EXTENSIONS TO STANDARD TCP
3.1 RELATIONSHIP BETWEEN SCPS-TP AND TCP
SCPS-TP adopts the Transmission Control Protocol (TCP) as specified in Internet Standard 7
(reference [4]) and its supporting RFCs, with the modifications and options specified in
section 3 of this document.
NOTE – Section 6 of this document summarizes requirements for implementing TCP in
the SCPS environment.
3.2 CONNECTION MANAGEMENT
3.2.1 INITIAL SEQUENCE NUMBER SELECTION
A SCPS-TP conforming implementation is not required to use a clock as the basis for Initial
Sequence Number (ISN) selection. As long as ISN selection is robust against a possible
crash, increases slightly faster than the maximum possible transmission rate, and does not
wrap too quickly, then the algorithm used for ISN selection meets the intent of the
requirement and is acceptable (refer to reference [4], RFC 793, section 3.3, and reference [2],
RFC 1122, section 4.2.2.9).
NOTE – The ISN does not have to be updated at every clock tick. Rather, it only needs to
be computed at the time a connection is established.
3.2.2 PRECEDENCE HANDLING
3.2.2.1 Security
The TCP shall convey a user’s security requests and replies to the security provider and shall
report responses and indications as required.
NOTES
1 Security is handled external to the TCP, at a protocol layer that is conceptually lower
in the ‘stack’.
2 All other references to security in this document shall be considered non-normative.
3.2.2.2 Precedence
3.2.2.2.1 The precedence parameter used in TCP is as defined in the SCPS Network
Protocol (reference [10]), the intent being that connection shall be allowed at the higher of
the precedence levels requested by the two ports attempting to connect.
CCSDS 714.0-B-1 Page 3-1 May 1999
CCSDS RECOMMENDATION FOR SCPS TRANSPORT PROTOCOL (SCPS-TP)
3.2.2.2.2 If the TCP is operating over a network protocol that does not support precedence,
or supports fewer precedence levels than are defined in [10], then a locally defined mapping
between the user-specified precedence level and the system-supported precedence levels
shall be performed.
3.2.2.2.3 The following paragraphs describe specific actions for handling the precedence
parameter in SCPS-TP:
a) an endpoin
...