ISO 18440:2016

INTERNATIONAL ISO
STANDARD 18440
Second edition
2016-11-15
Space data and information transfer
systems — Space link extension —
Internet protocol for transfer services
Systèmes de transfert des informations et données spatiales — Extension
de liaisons spatiales — Protocole Internet pour services de transfert
Reference number
©
ISO 2016
©  ISO 2016
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Ch. de Blandonnet 8  CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2. www.iso.org/directives
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
ISO 18440 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as CCSDS
913.1-B-2, September 2015) and was adopted (without modifications except those stated in clause 2 of this
International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 13, Space data and information transfer systems.
This second edition cancels and replaces the first edition (ISO 18440:2013), which has been technically
revised.
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
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 913.1-B-2 Page ii September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
FOREWORD
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. CCSDS has processes for identifying patent issues and for securing
from the patent holder agreement that all licensing policies are reasonable and non-
discriminatory. However, CCSDS does not have a patent law staff, and CCSDS shall not be
held responsible for identifying any or all such patent rights.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-4). Current versions of CCSDS documents are maintained at the CCSDS
Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be sent to the CCSDS
Secretariat at the e-mail address indicated on page i.
CCSDS 913.1-B-2 Page iii September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking and
Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– Electronics and Telecommunications Research Institute (ETRI)/Korea.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– South African National Space Agency (SANSA)/Republic of South Africa.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– Swiss Space Office (SSO)/Switzerland.
– United States Geological Survey (USGS)/USA.
CCSDS 913.1-B-2 Page iv September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Link Extension—Internet September Original issue, superseded
913.1-B-1 Protocol for Transfer Services, 2008
Recommended Standard, Issue 1
CCSDS Space Link Extension—Internet September Current issue:
913.1-B-2 Protocol for Transfer Services, 2015 – changes the
Recommended Standard, Issue 2 recommended
algorithm for secure
one-way hash
function from SHA-1
to SHA-256;
– updates references.
NOTE – Substantive changes from the previous issue are marked with change bars in the
inside margin.
CCSDS 913.1-B-2 Page v September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
CONTENTS
Section Page
1 INTRODUCTION. 1-1

1.1 PURPOSE . 1-1
1.2 SCOPE . 1-1
1.3 APPLICABILITY . 1-2
1.4 RATIONALE . 1-2
1.5 DOCUMENT STRUCTURE . 1-2
1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS . 1-4
1.7 REFERENCES . 1-8

2 DESCRIPTION OF THE INTERNET SLE PROTOCOL . 2-1

2.1 INTRODUCTION . 2-1
2.2 ARCHITECTURAL MODEL . 2-1
2.3 AUTHENTICATION LAYER . 2-3
2.4 DATA ENCODING LAYER . 2-4
2.5 TRANSPORT MAPPING LAYER . 2-5
2.6 INTERFACES . 2-11
2.7 SECURITY ASPECTS OF THE INTERNET SLE PROTOCOL . 2-22

3 ISP1 MESSAGES AND PROCEDURES . 3-1

3.1 AUTHENTICATION LAYER . 3-1
3.2 DATA ENCODING LAYER . 3-3
3.3 TRANSPORT MAPPING LAYER . 3-4

4 TML STATE TABLE . 4-1

4.1 INTRODUCTION . 4-1
4.2 NOTATION . 4-1
4.3 STATES . 4-2
4.4 EVENTS . 4-2
4.5 PREDICATES . 4-4
4.6 ACTIONS . 4-4
4.7 STATE TABLE . 4-6

ANNEX A TML DIAGNOSTIC CODES (NORMATIVE) . A-1
ANNEX B DIFFERENCES WITH EARLIER IMPLEMENTATIONS
(INFORMATIVE) .B-1
ANNEX C INDEX TO DEFINITIONS (INFORMATIVE) . C-1
ANNEX D ACRONYMS (INFORMATIVE) . D-1
CCSDS 913.1-B-2 Page vi September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
ANNEX E INFORMATIVE REFERENCES (INFORMATIVE) .E-1
CCSDS 913.1-B-2 Page vii September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
CONTENTS (continued)
Figure Page
1-1 SLE Services and SLE API Documentation . 1-3
2-1 ISP1 Architecture Model . 2-2
3-1 ASN.1 Type for Generation of ‘the Protected’ . 3-2
3-2 ASN.1 Type for the Credentials Parameter . 3-3
3-3 Layout of a TML Message . 3-4
3-4 Layout of a TML Context Message . 3-5

Table
2-1 Primitives of the AL Interface . 2-11
2-2 Parameters of the Primitive AL-SLE-PDU . 2-11
2-3 Primitives of the DEL Interface . 2-12
2-4 Parameters of the Primitive DEL-SLE-PDU . 2-12
2-5 Primitives of the TML Data Transfer Interface . 2-12
2-6 Parameters of the Primitive TML-SLE-PDU. 2-13
2-7 Primitives of the TML Association Control Interface . 2-13
2-8 Parameters of the Primitive TML-CONNECT . 2-13
2-9 Parameters of the Primitive TML-PEER-ABORT . 2-14
2-10 Parameters of the Primitive TML-PROTOCOL-ABORT . 2-15
2-11 Primitives of the TML Listener Interface . 2-15
2-12 Parameters of the Primitive TML-START-LISTEN . 2-15
2-13 Parameters of the Primitive TML-STOP-LISTEN . 2-16
2-14 Primitives Used for the TCP-Interface . 2-19
2-15 Parameters of the Primitive TCP-PASSIVE-OPEN . 2-19
2-16 Parameters of the Primitive TCP-CONNECT . 2-20
2-17 Parameters of the Primitive TCP-DATA . 2-21
3-1 TML Message Type Identifiers . 3-5

CCSDS 913.1-B-2 Page viii September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
1 INTRODUCTION
1.1 PURPOSE
The Space Link Extension (SLE) Reference Model (reference [1]) identifies a set of SLE
Transfer Services that enable missions to send forward space link data units to a spacecraft
and to receive return space link data units from a spacecraft. A subset of these services is
specified by the SLE Transfer Service Recommended Standards (references [2], [3], [4], [5],
and [6]). The SLE Transfer Service Recommended Standards specify
a) the operations necessary to provide the transfer service;
b) the parameter data associated with each operation;
c) the behaviors that result from the invocation of each operation; and
d) the relationship between, and the valid sequence of, the operations and resulting
behaviors.
However, they deliberately do not specify the methods or technologies required for
communications.
The purpose of this Recommended Standard is to define a protocol for transfer of SLE
Protocol Data Units (PDUs) defined in the SLE Transfer Service Recommended Standards
using the Internet protocols TCP (Transmission Control Protocol, reference [7]) and IP
(Internet Protocol, reference [8]) for data transfer and the Abstract Syntax Notation One
(ASN.1, references [9] and [10]) for data encoding. This protocol is referred to as the
Internet SLE Protocol One (ISP1).
1.2 SCOPE
This Recommended Standard defines a protocol for transfer of SLE PDUs between an SLE
user and an SLE provider system in terms of:
a) the procedures used to establish and release associations;
b) the messages exchanged on an established association;
c) the procedures used to monitor the status of data communication connections; and
d) the methods used to ensure that data are converted between different formats and
representations on different platforms.
It does not specify:
a) individual designs, implementations, or products;
b) the configuration of the data communications infrastructure, including configuration
of the TCP and IP protocols;
CCSDS 913.1-B-2 Page 1-1 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
c) the means by which addresses (IP addresses and TCP port numbers) are agreed,
assigned, and communicated.
This Recommended Standard responds to the requirements imposed by the Recommended
Standards for SLE transfer services that were available when this Recommended Standard
was released. The protocol specified in this Recommended Standard conforms to the
requirements on data communication services set forth in those Recommended Standards.
1.3 APPLICABILITY
1.3.1 APPLICABILITY OF THIS RECOMMENDED STANDARD
This Recommended Standard provides a basis for the development of real systems that
implement the Internet SLE Protocol. It is applicable for systems acting as an SLE service
user or SLE service provider.
1.3.2 LIMITS OF APPLICABILITY
This Recommended Standard specifies the Internet SLE Protocol that may be applied by an
SLE System for inter-Agency cross support. It is neither a specification of, nor a design for,
real systems that may be implemented for the control and monitoring of existing or future
missions.
1.4 RATIONALE
The goal of this Recommended Standard is to create a standard for interoperability between
the tracking stations and/or ground data handling systems of various agencies and the users of
SLE transfer services based on the technologies TCP/IP and ASN.1.
1.5 DOCUMENT STRUCTURE
1.5.1 ORGANIZATION
This document is organized as follows:
a) section 1 presents the purpose, scope, applicability and rationale of this
Recommended Standard and lists the definitions, conventions, and references used
throughout the Recommended Standard;
b) section 2 describes the Internet SLE Protocol by means of an architectural model
identifying individual protocol layers and the interfaces to higher layers;
c) section 3 specifies the messages exchanged via ISP1 and the procedures to be applied
for connection establishment and release and for data transfer;
CCSDS 913.1-B-2 Page 1-2 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
d) section 4 specifies the state table for the protocol;
e) annex A provides ISP1-specific diagnostic codes for the SLE PEER-ABORT
operation;
f) annex B describes differences with earlier implementations of ISP1;
g) annex C lists all terms used in this document and identifies where they are defined;
h) annex D lists all acronyms used within this document;
i) annex E contains a list of informative reference documents.
1.5.2 SLE SERVICES DOCUMENTATION TREE
This Recommended Standard is part of a suite of documents specifying the SLE services.
The SLE services constitute one of the three types of Cross Support Services:
a) Part 1: SLE Services;
b) Part 2: Ground Domain Services;
c) Part 3: Ground Communications Services.
The basic organization of the SLE services documentation is shown in figure 1-1. The
various documents are described in the following subsections.
Space Link Extension
Cross Support
Cross Support Concept SLE Executive
Reference Model
Part 1: SLE Services Summary
Part 1: SLE Services
SLE Transfer Services
Forward SLE Service Return SLE Service Internet Protocol for SLE Service
Specifications Specifications Transfer Services Management Suite
Recommended Recommended
Legend: Report (Green) Report (Yellow)
Standard (Blue) Practice (Magenta)

Figure 1-1: SLE Services and SLE API Documentation
a) Cross Support Concept—Part 1: Space Link Extension Services (reference [E1]), a
Report introducing the concepts of cross support and the SLE services;
CCSDS 913.1-B-2 Page 1-3 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
b) Cross Support Reference Model—Part 1: Space Link Extension Services (reference [1]),
a Recommended Standard that defines the framework and terminology for the
specification of SLE services;
c) Forward SLE Service Specifications, a set of Recommended Standards that will
provide specification of all forward link SLE services;
d) Return SLE Service Specifications, a set of Recommended Standards that will provide
specification of all return link SLE services;
e) Internet Protocol for Transfer Services, this Recommended Standard;
f) SLE Service Management Specifications, a set of Recommended Standards that
establish the basis of SLE service management.
1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS
1.6.1 DEFINITIONS
1.6.1.1 Definitions from the SLE Reference Model
This Recommended Standard makes use of the following terms defined in reference [1]:
a) initiator;
b) operation;
c) responder;
d) service user (user);
e) service provider (provider);
f) SLE protocol data unit (SLE-PDU);
g) SLE transfer service instance (service instance).
1.6.1.2 Definitions from SLE Transfer Service Specifications
This Recommended Standard makes use of the following terms defined in references [2], [3],
[4], [5], and [6]:
a) association;
b) communications service;
c) confirmed operation;
d) invocation;
CCSDS 913.1-B-2 Page 1-4 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
e) parameter (of an operation);
f) port identifier;
g) return;
h) unconfirmed operation.
1.6.1.3 Definitions from TCP/IP
This Recommended Standard makes use of the following terms defined in references [7] and
[8]:
a) Internet Protocol (IP);
b) IP address;
c) port (of TCP);
d) port number;
e) Transmission Control Protocol (TCP);
f) segment (of TCP);
g) socket.
1.6.1.4 Definitions from Abstract Syntax Notation One
This Recommended Standard makes use of the following terms defined in references [9] and [10]:
a) Abstract Syntax Notation One (ASN.1);
b) Basic Encoding Rules (BER);
c) Distinguished Encoding Rules (DER);
d) encoding rules (of ASN.1);
e) encoding;
f) module (of ASN.1).
1.6.1.5 Definitions from OSI Basic Reference Model
This Recommended Standard makes use of the following terms defined in reference [14]:
a) abstract syntax;
b) primitive;
CCSDS 913.1-B-2 Page 1-5 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
c) (protocol) layer;
d) transfer syntax.
1.6.1.6 Additional Definitions
1.6.1.6.1 General
For the purposes of this Recommended Standard, the following definitions also apply.
1.6.1.6.2 (SLE) Application
An application is a software entity in an SLE user system or an SLE provider system that
makes use of the ISP1 protocol, as distinguished from the software implementing the
protocol layers defined in this Recommended Standard. The application is considered to
implement the ‘higher layers’ defined in the architectural model in section 2.
1.6.1.6.3 Local Application
The local application is the application implementing the higher layers interfacing with a
given instance of an ISP1 implementation.
1.6.1.6.4 Peer Application
The peer application is the application that communicates with the local application via the
ISP1 protocol. The peer application is typically located on a remote network, but may also be
located on the local network, or even on the same host as the local application.
1.6.1.6.5 Application Identifier
The application identifier is the authority identifier of the application by which the
application is identified in the BIND invocation and the BIND return.
NOTE – For an initiating SLE application, the application identifier is the initiator-
identifier, and for a responding SLE application, the application identifier is the
responder-identifier.
1.6.2 NOMENCLATURE
1.6.2.1 Normative Text
The following conventions apply for the normative specifications in this Recommended
Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
CCSDS 913.1-B-2 Page 1-6 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
1.6.2.2 Informative Text
In the normative sections of this document, informative text is set off from the normative
specifications either in notes or under one of the following subsection headings:
– Overview;
– Background;
– Rationale;
– Discussion.
1.6.3 CONVENTIONS
The Internet SLE Protocol is specified by a layered architecture model in which the interfaces
between the layers are defined using abstract service primitives, roughly following the
concepts in the OSI Basic Reference Model (reference [14]).
A service primitive is a signal optionally associated with a set of parameters that is generated
by one layer and consumed by another (adjacent) layer. The direction in which the
information is passed is defined by one of the following:
request a primitive that is passed from the higher layer to the lower layer;
indication a primitive that is passed from the lower layer to the higher layer;
response a primitive generated by the higher layer in response to an indication of the
same type;
confirmation a primitive generated by the lower layer in response to a request of the same
type.
For every service primitive, the following specifications are provided:
a) the name of the primitive;
b) the uses of the primitive (request, indication, response, confirmation);
c) the parameters associated with each of these uses.
CCSDS 913.1-B-2 Page 1-7 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
In addition, the conditions under which the source emits a primitive and the tasks that the
receiver shall perform are described.
In this Recommended Standard, primitive names are capitalized and are followed by the
specific use in lowercase letters. The primitive name is prefixed by the identifier of the layer
that defines the interface, e.g., ‘TML-CONNECT-indication’. In the state table in section 4,
the prefix is omitted in order to avoid clashes with the notation used in these tables.
1.7 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Standard. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Standard
are encouraged to investigate the possibility of applying the most recent editions of the
documents indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS Recommended Standards.
NOTE – A list of informative references is provided in annex E.
[1] Cross Support Reference Model—Part 1: Space Link Extension Services. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 910.4-B-2.
Washington, D.C.: CCSDS, October 2005.
[2] Space Link Extension—Return All Frames Service Specification. Issue 3.
Recommendation for Space Data System Standards (Blue Book), CCSDS 911.1-B-3.
Washington, D.C.: CCSDS, January 2010.
[3] Space Link Extension—Return Channel Frames Service Specification. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 911.2-B-2.
Washington, D.C.: CCSDS, January 2010.
[4] Space Link Extension—Return Operational Control Fields Service Specification. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 911.5-B-2.
Washington, D.C.: CCSDS, January 2010.
[5] Space Link Extension—Forward CLTU Service Specification. Issue 3.
Recommendation for Space Data System Standards (Blue Book), CCSDS 912.1-B-3.
Washington, D.C.: CCSDS, July 2010.
[6] Space Link Extension—Forward Space Packet Service Specification. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 912.3-B-2.
Washington, D.C.: CCSDS, July 2010.
[7] J. Postel. Transmission Control Protocol. STD 7. Reston, Virginia: ISOC, September
1981.
[8] J. Postel. Internet Protocol. STD 5. Reston, Virginia: ISOC, September 1981.
CCSDS 913.1-B-2 Page 1-8 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
[9] Information Technology—Abstract Syntax Notation One (ASN.1): Specification of Basic
Notation. 4th ed. International Standard, ISO/IEC 8824-1:2008. Geneva: ISO, 2008.
[10] Information Technology—ASN.1 Encoding Rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). 4th
ed. International Standard, ISO/IEC 8825-1:2008. Geneva: ISO, 2008.
[11] Information Technology—Open Systems Interconnection—The Directory—Part 8:
Public-Key and Attribute Certificate Frameworks. 7th ed. International Standard,
ISO/IEC 9594-8:2014. Geneva: ISO, 2014.
[12] Secure Hash Standard (SHS). Federal Information Processing Standards Publication
180-4. Gaithersburg, Maryland: NIST, March 2012.
[13] Time Code Formats. Issue 4. Recommendation for Space Data System Standards (Blue
Book), CCSDS 301.0-B-4. Washington, D.C.: CCSDS, November 2010.
[14] Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. 2nd ed. International Standard, ISO/IEC 7498-1:1994. Geneva: ISO, 1994.
CCSDS 913.1-B-2 Page 1-9 September 2015
TML Association
Control Interface
TML Listener Interface
Internet SLE Protocol Layer
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
2 DESCRIPTION OF THE INTERNET SLE PROTOCOL
2.1 INTRODUCTION
This section describes a layered model of a system supporting the Internet SLE Protocol One
and introduces the main concepts by describing each layer and the interfaces between the
layers. Detailed specifications are provided in section 3, which references the concepts,
layers, and interfaces described by this model. It is stressed that this model has the sole
purpose of supporting the specifications in this Recommended Standard and is not intended
to suggest any specific design of a real implementation.
The discussion in this section assumes that the reader is familiar with the CCSDS
Recommended Standards for Space Link Extension transfer services provided by references
[2], [3], [4], [5], and [6], and assumes a general background on the Internet protocols,
especially on TCP (reference [7]).
2.2 ARCHITECTURAL MODEL
The architectural model used to specify the Internet SLE Protocol is shown in figure 2-1.
Higher Layers
Authentication Layer (AL)
Data Encoding Layer (DEL)
Transport Mapping Layer (TML)
Transmission Control Protocol (TCP)
Internet Protocol (IP)
CCSDS 913.1-B-2 Page 2-1 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
Figure 2-1: ISP1 Architecture Model
The Higher Layers represent the functionality specified by the Recommended Standards for
SLE transfer services (references [2], [3], [4], [5], and [6]), including in particular:
a) preparation of SLE protocol data units to be sent to the peer application;
b) analysis and processing of the SLE protocol data units received from the peer
application;
c) implementation of the state tables defined in the applicable Recommended Standard
for the SLE transfer service being provided or used.
The Internet SLE Protocol Layer is further decomposed into the following sub-layers:
a) The Authentication Layer (AL) is responsible for generating and analyzing the
credentials specified in the Recommended Standards for SLE transfer services. For
this purpose this Recommended Standard specifies use of the simple authentication
scheme defined in reference [11] and the Secure Hash Function (SHA-256) defined in
reference [12].
b) The Data Encoding Layer (DEL) is responsible for encoding of SLE protocol data
units received from higher layers and decoding of protocol data units received from
the peer application. For this purpose, this Recommended Standard specifies use of
the ASN.1 syntax defined by reference [9] and of the ASN.1 Basic Encoding Rules
(BER) defined by reference [10].
c) The Transport Mapping Layer (TML) handles the interface to the Transmission
Control Protocol (TCP) specified by reference [7].
ISP1 maps one TCP connection to one ISP1 association, which is used by the higher layers
for one SLE association as specified by the Recommended Standards for SLE transfer
services. ISP1 provides data encoding and decoding services but does not process SLE
protocol data units in any other respect.
For implementations assuming the responder role, the Transport Mapping Layer provides a
service to listen for incoming TCP connection requests. It therefore provides an interface by
which higher layers can request to start and stop listening for a specified SLE responder port
identifier, which the TML maps to an IP address and a TCP port number.
Except for the interface to control listening, all interfaces refer to one association only. ISP1
association establishment and release involves only the Transport Mapping Layer. Once the
association has been established, all SLE protocol data units are passed through the Data
Encoding Layer and the Authentication Layer.
ISP1 requires a number of configuration parameters for its operation, which are identified in
the following subsections. This Recommended Standard does not specify how these
parameters are defined, agreed, stored, and made available to the implementation of the ISP1.
CCSDS 913.1-B-2 Page 2-2 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
2.3 AUTHENTICATION LAYER
The ISP1 Authentication Layer (AL) receives SLE protocol data units from the higher layers
and adds the credentials parameter if required. Likewise, it receives decoded protocol data
units from the Data Encoding Layer and verifies that the credentials match the security
attributes of the peer application. If authentication is not used for a given service instance or
for a given PDU, the Authentication Layer passes the protocol data unit to the next layer
without modification or analysis.
For generation and analysis of the credentials, the Authentication Layer uses the simple
authentication scheme specified by reference [11], which is based on a secret password and a
message digest generated from that password, the time at which the credentials were
generated, and a random number. For the secure one-way hash function, required for this
scheme, the Secure Hash Function (SHA-256) specified by reference [12] is used.
If authentication fails for a PDU received from the peer application, the Authentication Layer
informs the higher layers, which are expected to handle this event as specified by the
Recommended Standards for SLE transfer services.
The Authentication Layer requires the following service instance configuration parameter for
its operation:
– authentication-level, defined by the Recommended Standards for SLE transfer
services, which can have the values
a) ‘all’: all invocations and returns, except the invocation of PEER-ABORT, shall
be authenticated;
b) ‘bind’: only the BIND invocation and return shall be authenticated;
c) ‘none’: no invocation or return shall be authenticated.
If the authentication-level is set to ‘all’ or ‘bind’ the Authentication Layer requires the
following additional configuration parameters:
a) the identifier of the local application;
b) the password of the local application;
c) the identifier of the peer application;
d) the password of the peer application;
e) the maximum time allowed between generation of the credentials by the invoker of an
SLE operation and verification of the credentials by the performer.
CCSDS 913.1-B-2 Page 2-3 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
NOTE – If the local application assumes the initiator role for the BIND operation, the
identifier of the local application is the initiator-identifier and the identifier of the
peer application is the responder-identifier defined by the Recommended
Standards for SLE transfer services. Otherwise, the identifier of the local
application is the responder-identifier and the identifier of the peer application is
the initiator-identifier.
2.4 DATA ENCODING LAYER
The ISP1 Data Encoding Layer (DEL) is responsible for the encoding and decoding of all
SLE protocol data units, except for the PEER-ABORT invocation PDU. For this purpose it
uses the ASN.1 types defined by the Recommended Standards for SLE transfer services and
applies the Basic Encoding Rules (BER) defined by reference [10].
NOTE – This Recommended Standard assumes that the PEER-ABORT operation is
implemented by direct interaction between the TML and higher layers. Handling
of the PEER-ABORT operation by the TML is described in 2.5.5.
The DEL receives SLE PDUs from the Authentication Layer, encodes the PDU and passes
the encoded PDU as a data buffer to the Transport Mapping Layer. Likewise, it receives
encoded PDUs from the Transport Mapping Layer, decodes them, and passes the decoded
PDU to the Authentication Layer.
When receiving a BIND invocation PDU from either the AL or the TML, DEL uses the
parameters service-type and version-number to identify the ASN.1 modules to use for all
PDUs subsequently exchanged on the same association. If the service type or version number
is not supported, the DEL informs the higher layers, which are expected to apply the
procedures specified by the Recommended Standards for SLE transfer services.
NOTE – This Recommended Standard assumes that the DEL uses the parameters of the
BIND operation to identify the ASN.1 modules to use for encoding and decoding,
because no additional configuration parameters are then needed. However, the
intention is not to prevent an implementation from applying any other suitable
approach as long as it is ensured that the ASN.1 specification used is the one
specified in the Recommended Standard that is identified by the service-type and
version-number parameters in the BIND invocation.
In case of errors (e.g., decoding failure), the DEL informs the higher layers, which are
expected to abort the association using the PEER-ABORT operation.
CCSDS 913.1-B-2 Page 2-4 September 2015
SPACE LINK EXTENSION—INTERNET PROTOCOL FOR TRANSFER SERVICES
2.5 TRANSPORT MAPPING LAYER
2.5.1 INTRODUCTION
The ISP1 Transport Mapping Layer handles the interface to TCP/IP. It provides the
following services:
a) mapping of logical port identifiers to TCP sockets (IP addresses and TCP port
numbers);
b) establishment and release of TCP connections;
c) transfer of SLE PDUs;
d) execution of the PEER-ABORT using features available with TCP;
e) monitoring of the status of TCP connections.
In addition, this Recommended Standard defines a special connection establishment
procedure, which is intended to support fast recovery from failures, provided that a responder
uses redundant hosts.
2.5.2 TML MESSAGES
2.5.2.1 General
As the TCP user interface is based on the concept of a byte stream, this Recommended
Standard defines a simple message format for transmission of SLE PDUs and exchange of
protocol control information between two communicating TMLs. The following types of
messages are defined:
a) an S
...