ISO 15894:2000

Space data and information transfer systems - Protocol specification for space communications - File protocol

Systèmes de transfert des informations et données spatiales — Spécification d'un protocole pour communications spatiales — Protocole de classement

General Information

• Status: Withdrawn
• Publication Date: 04-Oct-2000
• Withdrawal Date: 04-Oct-2000
• ICS: 49.140 - Space systems and operations
• Technical Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Drafting Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 10-May-2011
• Completion Date: 30-Oct-2025

Relations

• Consolidated By: ISO 12100-1:2003/Amd 1:2009 - Safety of machinery - Basic concepts, general principles for design - Part 1: Basic terminology, methodology - Amendment 1
• Effective Date: 06-Jun-2022

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 15894
First edition
2000-09-15
Space data and information transfer
systems — Protocol specification for space
communications — File protocol
Systèmes de transfert des informations et données spatiales —
Spécification d'un protocole pour communications spatiales — Protocole de
classement
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 [e-mail]
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 15894 was prepared by the Consultative Committee for Space Data Systems (CCSDS)
(as CCSDS 717.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 15894:2000(E)
Space data and information transfer systems — Protocol
specification for space communications — File protocol
1 Scope
This International Standard specifies the requirements for the services and protocols of the space communications
protocol specification (SCPS) file transfer 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 addresses those considerations attending communications between space platforms
and ground systems, and between space platforms.
2 Conformance
This International Standard is applicable to all systems that claim conformance to the ISO/CCSDS SCPS file
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 717.0-B-1, May 1999, Recommendation for space data system standards — Space communications
protocol specification (SCPS) — File protocol (SCPS-FP).
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 717.0-B-1.
Pages i to v
This part is information which is relevant to the CCSDS publication only.
Page 1-3
Add the following information to the references indicated in paragraph 1.6:
[3] Document CCSDS 102.0-B-4, November 1995, is equivalent to ISO 13419:1997.
[4] Document CCSDS 714.0-B-1, May 1999, is equivalent to ISO 15893:2000.
4 Revision of publication CCSDS 717.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 717.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)—
FILE PROTOCOL
(SCPS-FP)
CCSDS 717.0-B-1
BLUE BOOK
May 1999
(Blank page)
4 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
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 717.0-B-1 Page i May 1999
CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
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
Recommendations and are not considered binding on any Agency.
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 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
Recommendation nor any ensuing standard is a substitute for a memorandum of
agreement.
No later than five years from its date of issuance, this Recommendation 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 is issued, existing CCSDS-
Recommendation
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 717.0-B-1 Page ii May 1999
6 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
FOREWORD
The Space Communications Protocol Specification (SCPS) File Protocol (SCPS-FP)
provides End-to-End Application-Layer Services for flight missions in the space
environment. It is based on Internet File Transfer Protocol (FTP) and is generally inter-
operable with it. It does, however, extend and modify FTP in order to meet the unique
requirements of space flight operations. This document anticipates reader familiarity with
FTP and, therefore, addresses only those capabilities that have been added to FTP.
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 717.0-B-1 Page iii May 1999
CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
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 717.0-B-1 Page iv May 1999
8 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Communications May Original issue
717.0-B-1 Protocol Specification 1999
(SCPS)—File Protocol
(SCPS-FP)
CCSDS 717.0-B-1 Page v May 1999
CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
CONTENTS
Section Page
1 INTRODUCTION.1-1
1.1 PURPOSE .1-1
1.2 SCOPE .1-1
1.3 APPLICABILITY .1-1
1.4 ORGANIZATION OF RECOMMENDATION .1-1
1.5 TERMINOLOGY.1-2
1.6 REFERENCES.1-2
2 OVERVIEW .2-1
3 TECHNICAL SPECIFICATION.3-1
3.1 INTERNET FTP .3-1
3.2 DATA TRANSFER FUNCTIONS.3-1
3.3 FILE TRANSFER FUNCTIONS.3-8
3.4 DECLARATIVE SPECIFICATIONS .3-15
3.5 STATE DIAGRAMS .3-21
3.6 CONNECTION ESTABLISHMENT .3-21
3.7 INTERFACE TO LOWER PROTOCOL STACK LAYERS.3-22
3.8 MISCELLANEOUS SCPS-FP REQUIREMENTS.3-22
4 MANAGEMENT INFORMATION BASE (MIB) REQUIREMENTS.4-1
4.1 OVERVIEW .4-1
4.2 DATA TRANSFER TYPE .4-1
4.3 TRANSMISSION MODE.4-1
4.4 DATA STRUCTURE .4-1
4.5 AUTORESTART.4-2
4.6 MAXIMUM NUMBER OF AUTOMATIC RESTARTS .4-2
4.7 USE PORT COMMAND ON EACH SEND.4-2
4.8 SUPPRESS SERVER REPLY TEXT .4-2
4.9 SERVER IDLE TIMEOUT.4-3
4.10 BEST EFFORT TRANSPORT SERVICE .4-3
4.11 BEST EFFORT TRANSPORT SERVICE FILL CHARACTER.4-3
CCSDS 717.0-B-1 Page vi May 1999
10 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
CONTENTS (continued)
Section Page
5 CONFORMANCE REQUIREMENTS.5-1
5.1 CONFORMANCE REQUIREMENTS OVERVIEW .5-1
5.2 SCPS-FP CONFORMING MINIMUM IMPLEMENTATION .5-1
5.3 SCPS CONFORMING FULL IMPLEMENTATION .5-3
5.4 FTP INTEROPERABLE IMPLEMENTATION .5-4
5.5 OTHER OPTIONAL IMPLEMENTATIONS.5-5
ANNEX A ACRONYMS AND ABBREVIATIONS .A-1
ANNEX B INFORMATIVE REFERENCES. B-1
ANNEX C SCPS-FP PROTOCOL IMPLEMENTATION CONFORMANCE
STATEMENT PROFORMA .C-1
ANNEX D SCPS-FP SERVICE SPECIFICATION .D-1
Figure
3-1 State Diagram 1.3-21
3-2 State Diagram 2.3-21
D-1 State Diagram 1.D-4
D-2 State Diagram 2.D-5
D-3 State Diagram 3.D-6
Table
3-1 Rollback Algorithm without Autorestart.3-7
3-2 Rollback Algorithm with Autorestart.3-7
3-3 Transport Services Summary .3-22
CCSDS 717.0-B-1 Page vii May 1999
(Blank page)
12 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
1 INTRODUCTION
1.1 PURPOSE
The purpose of this Recommendation is to define the Space Communications Protocol
Specification (SCPS) File Protocol (SCPS-FP). This definition will allow independent
implementations of the SCPS-FP in the space and ground segments of the SCPS Network to
interoperate.
1.2 SCOPE
This Recommendation addresses communications between space platforms and ground
systems, and between space platforms. It is designed to support efficient file-transfer and
file-operation requirements of current and upcoming space missions through extensions and
modifications to Internet File Transfer Protocol (FTP).
1.3 APPLICABILITY
This Recommendation is applicable to space missions and ground systems that claim
conformance to the SCPS-FP. It is intended that this Recommendation become a uniform
standard for all active Member and Observer Agencies of the CCSDS.
1.4 ORGANIZATION OF RECOMMENDATION
This SCPS-FP Recommendation is organized as follows:
– Section 1 provides an introduction to the standard, introduces new protocol
terminology, and documents the normative references.
– Section 2 provides an overview of the SCPS File Protocol.
– Section 3 documents the protocol specifications for a SCPS-FP.
– Section 4 documents the Management Information Base (MIB) requirements for
SCPS-FP.
– Section 5 documents the conformance requirements for SCPS-FP.
– Annex A defines acronyms and abbreviations used in the document.
– Annex B lists informative references.
– Annex C contains the Protocol Implementation Conformance Statement (PICS)
proforma for SCPS-FP.
– Annex D contains the Service Specification.
CCSDS 717.0-B-1 Page 1-1 May 1999
CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
This Recommendation modifies and adds to Internet FTP. It makes normative reference to
the Internet standards that define FTP (references [1] and [2]). It makes informative
reference to other documents (see annex B).
1.5 TERMINOLOGY
The terminology as outlined in Internet Standard 9 (reference [1]), section 2.2, is applicable
to the SCPS-FP with the following additions:
Cyclic Redundancy Check (CRC): A polynomial-based code used for protecting against
recording and communications errors (see reference [B2]).
: A collection of the information necessary to control the operation of the record
control data
read and record update services. This information includes data such as the files to be
read/updated, checksum, option flags, and update data.
network byte order: The order in which the bytes of a word are transmitted. For a 32-bit
word, W1.W2.W3.W4, where W1 is the most significant octet, W1 is transmitted first, W2
next, then W3, and finally W4. The same applies for a 16-bit number, W1.W2, where W1
corresponds to the high 8 bits. W1 is sent first, and then W2.
rollback: Of or pertaining to the act of rolling back (undoing) incomplete changes made to a
file for which the transfer or record operation terminated with errors and thereby restoring the
file to its pre-transfer or pre–record operation state.
user-FP: Same as user-FTP in Internet Standard 9 (reference [1]). Terminology changed in
SCPS-FP specification to remove direct reference to FTP.
server-FP: Same as server-FTP in Internet Standard 9 (reference [1]). Terminology changed
in SCPS-FP specification to remove direct reference to FTP.
NVT-ASCII: The ASCII collation sequence.
1.6 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 717.0-B-1 Page 1-2 May 1999
14 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
†
[1] J. Postel and J. Reynolds. File Transfer Protocol. STD 9, October 1985. [RFC 959]
[2] R. Braden. Hosts Requirements. STD 3, October 1989. [RFC 1122, RFC 1123]
[3] Packet Telemetry. Recommendation for Space Data System Standards, CCSDS 102.0-
B-4. Blue Book. Issue 4. Washington, D.C.: CCSDS, November 1995.
[4] Space Communication Protocol Specification (SCPS)—Transport Protocol (SCPS-TP).
Recommendation for Space Data System Standards, CCSDS 714.0-B-1. Blue Book.
Issue 1. Washington, D.C.: CCSDS, May 1999.
†
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 717.0-B-1 Page 1-3 May 1999
(Blank page)
16 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
2 OVERVIEW
The extensions to FTP and its augmentations as contained in Internet Standards 9 and 3
(references [1] and [2]) are necessitated by technical requirements for transfers of and
operations on files and analogous delimited data sets in the space communications
environment. These technical requirements include
– transfers of command and data files to spacecraft;
– transfers of application software to spacecraft;
– transfers of science or mission data to ground without special level-zero processing;
– limited management of files onboard spacecraft (delete, rename, and directory
services);
– automatic restart of transfers after an interruption;
– reading of portions of files resident on board spacecraft; and
– updates/changes to files on board spacecraft.
The SCPS-TP protocol is characterized by a command/reply dialog on a stream connection.
The client Protocol Interpreter (PI) accepts input from the user, translates user commands to
server commands, and issues the server commands on the control connection. The server PI
parses those commands, looks up commands in a table, and transfers control to the routine
associated with the command. This specification defines procedures for each PI to execute
upon success or failure of commands. When a command has been parsed and processed,
either successfully or unsuccessfully, the server issues a reply message on the control
connection. Commands and replies are short ASCII strings terminated with the ASCII
control sequence .
SCPS-FP is based on Internet FTP, which is described in references [1] and [2]. SCPS-FP
maintains interoperability with Internet FTP on the control connection. This
Recommendation is designed to be scaleable to fit onto the most resource-constrained service
and yet expandable to full Internet compatibility according to mission requirements.
SCPS-FP is a profile of Internet FTP that adds capabilities to the Internet standard as follows:
– automatic restart of a failed transfer;
– read, write, add, change, and delete individual file records;
– interrupt (pause) a file transfer so that it can be restarted later from the interrupt point;
– suppress reply text to improve bandwidth efficiency;
– assure file and record integrity in the case of abnormal connection loss.
These capabilities are designed to yield efficient transfer of file-oriented data sets across the
space link.
CCSDS 717.0-B-1 Page 2-1 May 1999
(Blank page)
18 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
3 TECHNICAL SPECIFICATION
3.1 INTERNET FTP
SCPS-FP adopts the File Transfer Protocol (FTP) as specified in Internet Standards 9 and 3
(references [1] and [2]), with the modifications and extensions specified in section 3 of this
document.
3.2 DATA TRANSFER FUNCTIONS
3.2.1 DATA REPRESENTATION AND STORAGE
3.2.1.1 Data Types
3.2.1.1.1 General
The non-print format controls are applicable to SCPS-FP. EBCDIC and Local data types
may be supported as additional, non-SCPS capabilities.
3.2.1.1.2 ASCII Type
The ASCII data type is optional for SCPS-FP file transfer operations; it does not apply to
SCPS-FP record operations. The ASCII type is not the SCPS-FP default.
3.2.1.1.3 Image Type
The IMAGE data type is the default for SCPS-FP and must be supported by all SCPS-FP
implementations.
3.2.1.2 Data Connection Management
The SCPS-FP user-PI must initiate the use of non-default ports because of the need for
SCPS-TP to hold the connection record for a timeout period to guarantee reliable
communication.
3.2.1.3 Stream Mode
If the structure is a file structure, the EOF is indicated by the sending host’s closing of the
data connection, in which case all bytes are data bytes.
CCSDS 717.0-B-1 Page 3-1 May 1999
CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
3.2.1.4 CCSDS Packets
If the structure is a record structure, indicating the file consists of contiguous CCSDS
Packets, the following provisions are required to enable use of FP restart and record
read/update capabilities.
a) the FP shall issue the STRU command with the Record argument (ASCII character ‘R’);
b) the FP shall issue the TYPE command if necessary to switch to IMAGE data type
before transferring files of CCSDS Packets;
c) the FP shall invoke the record boundary option of SCPS-TP (reference [4]) to delimit
records during transfer;
d) in record operations, record identifiers shall be interpreted as referring to the Packet
Sequence Count field in the record;
e) the protocol shall use the Packet Data Length field to delimit records in the file.
3.2.2 ERROR RECOVERY AND RESTART
3.2.2.1 Stream Mode Restart with IMAGE Data Type
3.2.2.1.1 When a system failure is detected, the receiving Data Transfer Process (DTP)
shall determine the restart marker by querying the file system for the current size of the file.
3.2.2.1.2 Restart markers shall not be imbedded in the data in stream mode.
3.2.2.1.3 There are three cases in which SCPS-FP restart may be accomplished in stream
mode:
a) user-to-server transfer (e.g., STOR):
1) the user-FP shall send ‘SIZE pathname’ to the receiving server-FP;
2) the server-FP shall send ‘213 pathname SIZE rrrr’ to the user-FP, where rrrr is the
size of the file (indicated by pathname) stored locally at the server;
3) to restart the transfer, the user-FP shall reposition its local file system using restart
marker rrrr and send the command ‘REST rrrr’ to the server-FP;
4) the server-FP shall save restart marker rrrr for restart;
b) server-to-user transfer (e.g., RETR):
1) the user-FP shall determine the size (rrrr) of the file as stored by the local file
system;
CCSDS 717.0-B-1 Page 3-2 May 1999
20 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
2) to restart the transfer, the user-FP shall reposition its local file system using restart
marker rrrr and send the command ‘REST rrrr’ to the server-FP;
3) the server-FP shall save restart marker rrrr for restart;
c) server-to-server (‘third-party’) transfer (e.g., PROXY):
1) the user-FP shall send ‘SIZE pathname’ to the receiving server-FP;
2) the receiving server-FP shall send ‘213 pathname SIZE rrrr’ to the user-FP, where
rrrr is the size of the file (indicated by pathname) stored locally at the receiving
server;
3) to restart the transfer, the user-FP shall
– send the command ‘REST rrrr’ to the receiving server-FP;
– send ‘REST ssss’ to the sending server-FP, where ssss = rrrr;
4) each server shall save the received restart markers for restart.
3.2.2.1.4 Immediately after sending the REST command, the user-FP shall send the file
transfer command (such as RETR, STOR or LIST) that was being executed when the system
failure occurred.
3.2.2.1.5 Before the actual data transfer resumes, the server-FP process for the file transfer
command shall advance the file to the restart marker.
3.2.2.1.6 The automatic and manual restart of a CCSDS Packet file transfer (RETR or
STOR of files having the CCSDS Packet structure) shall follow the processing documented
in 3.2.2.2 and 3.2.2.4 with the following additional provisions:
a) restart must be on the CCSDS Packet boundary for transfers of files having the
CCSDS Packet structure;
b) the restart marker shall be the Packet Sequence Count of the last complete Packet
received.
NOTE – General provisions for operations involving the CCSDS Packet structure are
given in 3.2.1.4.
3.2.2.2 Stream Mode Restart with ASCII Data Type
When the data type is ASCII, the restart point is always relative to the start of the transfer
image, not the flat file size in the file system. All other processing is the same as with the
IMAGE data type.
CCSDS 717.0-B-1 Page 3-3 May 1999
CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
3.2.2.3 Automatic Restart
3.2.2.3.1 For SCPS-FP restart cases, the user Protocol Interpreter (user-PI), rather than the
user-FP, shall be responsible for the decision making for
– reestablishing connections,
– re-logging in the user,
– sending the SIZE and/or REST commands,
– interpreting and responding to the replies for these commands, and
– resending the original file transfer command (e.g., RETR, STOR, LIST) to reinitiate
the file transfer.
3.2.2.3.2 To use the autorestart capability, the user-FP and the server-FP must both be in
autorestart mode:
a) the autorestart protocol command (ARST) shall be used to enable autorestart at the
server-FP;
b) the no-autorestart protocol command (NARS) shall be used to disable autorestart at
the server-FP.
NOTE - As documented in 3.3.2, the ARST command indicates to the server that the
client is in autorestart mode and therefore file changes should not be rolled back
when an error occurs (otherwise a partial file that has been transferred will be
wiped out). Partial files are saved if the data connection aborts or times out.
Conversely, the NARS command indicates to the server that the client is not in
autorestart mode and that therefore it should roll back changes when the data
connection aborts or times out.
3.2.2.3.3 When autorestart is enabled by the user, the user-PI shall restart a failed data
transfer (without requiring the user to specify the restart point or command to restart) up to
the maximum number of restarts specified in the MIB parameter fpMaxAutorestarts (see 4.6):
a) the maximum number of restarts shall be set to 3 as a default;
b) the user-FP may notify the user of the failed transfer and request confirmation to
continue with the restart.
NOTE – User notification may be useful in situations where an automatic restart does not
make sense (e.g., spacecraft is out of view).
3.2.2.3.4 Autorestart of a failed transfer in stream mode shall proceed as detailed in 3.2.2.1.
CCSDS 717.0-B-1 Page 3-4 May 1999
22 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
3.2.2.3.5 In cases where the control connection had to be reestablished in order to proceed
with the autorestart, any transfer parameters that were set by the user prior to the start of the
file transfer should be resent to the server to ensure that the state of the transfer parameters at
the server is correct.
NOTE – Block and compressed modes are not required for SCPS-FP. These modes are
not universally interoperable. Error recovery and restart for block and
compressed modes for SCPS-FP are as described in reference [1], section 3.5,
with the added feature that the user-PI can, if enabled, initiate the restart
automatically.
3.2.2.4 Manual Interrupt and Manual Restart
NOTE – Manual interrupt provides the capability for the user-FP to stop a file transfer
temporarily and then restart it at a later time.
3.2.2.4.1 There are three cases for SCPS-FP interrupt in all modes.
a) user-to-server transfer:
1) the user-FP shall send ‘INTR’ to the server-FP;
2) in response, the server-FP shall stop the file transfer and send ‘256 Transfer
Interrupted at rrrr’ to the user-FP, where rrrr is the size of the file stored locally at
the server;
3) the user-FP shall save the restart marker rrrr for restart;
4) the user-FP may reinitiate the transfer process by repositioning its local file
system using restart marker rrrr and sending ‘REST rrrr’ to the server-FP;
b) server-to-user transfer:
1) the user-FP shall send ‘INTR’ to the server-FP;
2) the server-FP shall stop the file transfer and send ‘256 Transfer Interrupted at ssss’
to the user-FP;
3) the user-FP shall ignore the restart marker specified in the INTR reply;
4) the user-FP may reinitiate the transfer process by sending ‘REST rrrr’ to the server-FP,
where rrrr is the amount of data received and stored successfully at the user site;
c) server-to-server (‘third-party’) transfer:
1) the user-FP shall send ‘INTR’ to the sending server-FP;
CCSDS 717.0-B-1 Page 3-5 May 1999
CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
2) the sending server-FP shall stop the file transmission and send ‘256 Transfer
Interrupted at ssss’ to the user-FP;
3) the user-FP shall send ‘INTR’ to the receiving server-FP:
– the user-FP should wait for the sending server-FP to respond with the 256
reply before sending ‘INTR’ to the receiving server-FP;
– if the sending server-FP responds with a code other than 256 (e.g., 226 - file
transfer was completed before interrupt received), then the file transfer should
continue as it normally would in response to the received reply code;
4) in response to ‘INTR’, the receiving server-FP shall stop the file transfer process
and send ‘256 Transfer Interrupted at rrrr’ to the user-FP;
5) the user-FP shall ignore the restart marker in the sending server-FP’s reply and
use the restart marker in the receiving server-FP’s reply when issuing the REST
command;
6) the user-FP may reinitiate the transfer process by sending ‘REST rrrr’ to the
receiving server-FP and sending server-FP.
3.2.2.4.2 To restart the interrupted file transfer, the user-FP shall follow the restart
procedures outlined in 3.2.2.1.
3.2.3 INTEGRITY
3.2.3.1 File Transfer Integrity
3.2.3.1.1 The user-FP and server-FP shall roll back any incomplete changes made to a file
during a non-autorestart RETR or STOR operation that has terminated with errors, thereby
restoring the affected file to its pre-transfer state.
3.2.3.1.2 At the start of a transfer, if the destination filename is in use, FP renames that file
using a temporary name.
The rollback algorithm used shall be as detailed in table 3-1 when autorestart is
3.2.3.1.3
disabled.
CCSDS 717.0-B-1 Page 3-6 May 1999
24 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
Table 3-1: Rollback Algorithm without Autorestart
Destination file existed at
start of transfer Reason for transfer abort Action by FP
No ABOR command Delete partial file
No INTR command Keep partial file
No time-out Delete partial file
Yes ABOR command Restore original file,
delete partial file
Yes INTR command Keep partial file,
delete original file
Yes time-out Restore original file,
delete partial file
3.2.3.1.4 In autorestart mode, when a transfer aborts because of a timeout, the FP actions
shall be as detailed in table 3-2.
Table 3-2: Rollback Algorithm with Autorestart
Destination file existed at
start of transfer Reason for transfer abort Action by FP
No time-out Keep partial file
Yes time-out Keep partial file,
delete original file
3.2.3.2 Record Data Integrity
3.2.3.2.1 The user-FP and server-FP shall roll back any incomplete changes made to a file
during a READ or UPDT operation that has terminated with errors, thereby restoring the
affected file to its pre–record operation state.
To provide a secondary measure of integrity to ensure that a user does not update
3.2.3.2.2
the wrong file inadvertently, the user-FP and server-FP shall employ the following CRC for
the record update service to ensure the data integrity of the accessed files:
a) The encoding shall be defined by the generating polynomial
32 26 23 22 16 12 11 10 8 7 5 4 2
G(x) = x + x + x + x + x + x + x + x + x + x + x + x + x + x + 1
b) Mathematically, the CRC value corresponding to a given file shall be defined by the
following procedure.
1) The n bits in the file are considered to be the coefficients of a mod-2 polynomial
(n-1)
M(x) of degree n-1. Bit 0 of the first octet corresponds to the x term. Bit 7 of
(n-8)
the first octet corresponds to the term. Bit 0 of the second octet corresponds
x
(n-9) (n-16)
to the x term. Bit 7 of the second octet corresponds to the x term, and so
CCSDS 717.0-B-1 Page 3-7 May 1999
CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
on. Bit 7 of the last octet corresponds to the least significant bit in M(x). The last
octet may need to be padded with zero bits to achieve an integral number of
octets.
2) M(x) is divided by G(x) using mod-2 division, producing a remainder R(x) of
degree ≤ 31. This mod-2 division is accomplished using the exclusive OR (XOR)
operation for subtractions.
3) The coefficients of G(x) and R(x) are considered to be 32-bit sequences.
4) The bit sequence is complemented and the result is the CRC.
3.2.3.3 Files of CCSDS Packets
The rollback and CRC procedures for files of contiguous CCSDS Packets are as described in
3.2.3.1 and 3.2.3.2.
NOTE – General provisions for operations involving the CCSDS Packet structure are
given in 3.2.1.4.
3.3 FILE TRANSFER FUNCTIONS
3.3.1 ACCESS CONTROL COMMANDS
Processing for the following access commands for SCPS-FP is as described in section 4.1.1
of Internet Standard 9 (reference [1]):
USER, PASS, CWD, ACCT, CDUP, QUIT.
3.3.2 TRANSFER PARAMETER COMMANDS
3.3.2.1 Processing for the following transfer parameter commands for SCPS-FP is as
described in section 4.1.2 of Internet Standard 9 (reference [1]):
MODE, PORT, PASV, TYPE, STRU.
3.3.2.2 The additional SCPS-FP commands are:
a) ENABLE AUTORESTART (ARST):
– The ARST command shall cause the server-FP to set the MIB parameter
fpAutorestartEnabled to ‘TRUE’ (enabled).
– While autorestart is enabled, partial files shall not be rolled back when an error occurs.
CCSDS 717.0-B-1 Page 3-8 May 1999
26 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
b) ENABLE BEST EFFORT TRANSPORT SERVICE OPTION (BETS):
NOTE – The BETS command is practicable only when SCPS-TP (reference [4])
provides the underlying transport service.
– The BETS command shall cause the server-FP to set the MIB parameter
fpBETSEnabled to ‘TRUE’ (enabled) and save the BETS fill code to use during a
file transfer, if supplied, in the MIB parameter fpBETSFillChar.
– While the BETS option is enabled,
• the sending FP shall request the SCPS-TP to run in BETS mode for RETR and
STOR operations;
• the receiving FP/TP shall accept BETS-mode operation.
– The receiving FP shall inform the user of any gaps in the data and fill the gaps
with the BETS fill code contained in the MIB parameter fpBETSFillChar.
– BETS shall be applied to RETR and STOR operations only.
c) DISABLE AUTORESTART (NARS):
– The NARS command shall cause the server-FP to set the MIB parameter
fpAutorestartEnabled to ‘FALSE’ (disabled).
– While autorestart is disabled, partial files shall be rolled back when an error occurs.
d) DISABLE BEST EFFORT TRANSPORT SERVICE OPTION (NBES):
– The NBES command shall cause the server-FP to set the MIB parameter
fpBETSEnabled to ‘FALSE’ (disabled).
– While the BETS option is disabled,
• the sending FP shall not request BETS-mode operation;
• the receiving FP/TP shall not accept BETS-mode operation.
3.3.3 SCPS-FP SERVICE COMMANDS
3.3.3.1 Processing for the following service commands for SCPS-FP is as described in
section 4.1.3 of Internet Standard 9 (reference [1]) and as amended by sections 4.1.2.7 (LIST)
and 4.1.2.10 (Telnet End-of-Line Code) of RFC 1123 in Internet Standard 3 (reference [2]):
RETR, STOR, RNFR, RNTO, ABOR, DELE, RMD, MKD, LIST, HELP, SITE, STAT,
PWD, STOU, SYST, NOOP, NLST, APPE.
3.3.3.2 In addition, SCPS-FP supports the following commands:
CCSDS 717.0-B-1 Page 3-9 May 1999
CCSDS RECOMMENDATION FOR SCPS FILE PROTOCOL (SCPS-FP)
a) COPY (COPY):
– The COPY command shall cause the server-FP to copy the file specified in the
first pathname (argument 1) to the file specified in the second pathname
(argument 2).
– The server-FP shall report the success or failure of the copy in a reply.
b) IDLE TIMEOUT (IDLE):
– The IDLE command shall cause the server-DTP to set the MIB parameter
fpIdleTimeout to the value specified by the user.
– If the server is inactive for this idle timeout period, the server-FP shall terminate
the process and close the control connection.
c) MANUAL INTERRUPT (INTR):
– The INTR command shall cause the server-DTP to interrupt a file transfer.
– The server-FP shall communicate the poi
...