ISO 18444:2016

INTERNATIONAL ISO
STANDARD 18444
Second edition
2016-11-15
Space data and information transfer
systems — Space link extension —
Application program interface for return
operational control fields service
Systèmes de transfert des informations et données spatiales — Extension de
liaisons spatiales — Interface du programme d'application pour service des
champs de contrôle de retour opérationnel
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 18444 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as CCSDS
915.5-M-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 18444:2013), which has been technically
revised.
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
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 Recommendations and are not in themselves
considered binding on any Agency.
CCSDS Recommendations take two forms: Recommended Standards that are prescriptive
and are the formal vehicles by which CCSDS Agencies create the standards that specify how
elements of their space mission support infrastructure shall operate and interoperate with
others; and Recommended Practices that are more descriptive in nature and are intended to
provide general guidance about how to approach a particular problem associated with space
mission support. This Recommended Practice is issued by, and represents the consensus of,
the CCSDS members. Endorsement of this Recommended Practice is entirely voluntary
and does not imply a commitment by any Agency or organization to implement its
recommendations in a prescriptive sense.
No later than five years from its date of issuance, this Recommended Practice 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 Practice is issued, existing
CCSDS-related member Practices and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such Practices
or implementations are to be modified. Each member is, however, strongly encouraged to
direct planning for its new Practices and implementations towards the later version of the
Recommended Practice.
CCSDS 915.5-M-2 Page ii September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
FOREWORD
This document is a technical Recommended Practice for use in developing ground systems
for space missions and has been prepared by the Consultative Committee for Space Data
Systems (CCSDS). The Application Program Interface described herein is intended for
missions that are cross-supported between Agencies of the CCSDS.
This Recommended Practice specifies service type-specific extensions of the Space Link
Extension Application Program Interface for Transfer Services specified by CCSDS
(reference [3]). It allows implementing organizations within each Agency to proceed with
the development of compatible, derived Standards for the ground systems that are within
their cognizance. Derived Agency Standards may implement only a subset of the optional
features allowed by the Recommended Practice and may incorporate features not addressed
by the Recommended Practice.
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 915.5-M-2 Page iii September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
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 915.5-M-2 Page iv September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Link Extension—Application October Original issue, superseded
915.2-M-1 Program Interface for Return 2008
Channel Frames Service,
Recommended Practice, Issue 1
CCSDS Space Link Extension—Application September Current issue:
915.5-M-2 Program Interface for Return 2015 – updates text to
Operational Control Fields Service, accommodate changes
Recommended Practice, Issue 2 in current version of
SLE service
specification;
– differentiates
applicability by SLE
service specification
version;
– updates references.
NOTE – Substantive changes from the previous issue are marked with change bars in the
inside margin.
CCSDS 915.5-M-2 Page v September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
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-3
1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS . 1-5
1.7 REFERENCES . 1-8

2 OVERVIEW . 2-1

2.1 INTRODUCTION . 2-1
2.2 PACKAGE ROCF SERVICE INSTANCES . 2-1
2.3 PACKAGE ROCF OPERATIONS . 2-5
2.4 SECURITY ASPECTS OF THE SLE ROCF TRANSFER SERVICE . 2-7

3 ROCF SPECIFIC SPECIFICATIONS FOR API COMPONENTS . 3-1

3.1 API SERVICE ELEMENT . 3-1
3.2 SLE OPERATIONS . 3-9
3.3 SLE APPLICATION . 3-9
3.4 SEQUENCE OF DIAGNOSTIC CODES . 3-10

ANNEX A ROCF SPECIFIC INTERFACES (NORMATIVE) . A-1
ANNEX B ACRONYMS (INFORMATIVE) .B-1
ANNEX C INFORMATIVE REFERENCES (INFORMATIVE) . C-1
Figure
1-1 SLE Services and SLE API Documentation . 1-4
2-1 ROCF Service Instances . 2-2
2-2 ROCF Operation Object Interfaces . 2-6

Table
2-1 ROCF Configuration Parameters . 2-4
2-2 ROCF Status Information . 2-5
2-3 Mapping of ROCF Operations to Operation Object Interfaces . 2-7

CCSDS 915.5-M-2 Page vi September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
1 INTRODUCTION
1.1 PURPOSE
The Recommended Practice Space Link Extension—Application Program Interface for
Transfer Services—Core Specification (reference [3]) specifies a C++ API for CCSDS Space
Link Extension Transfer Services. The API is intended for use by application programs
implementing SLE transfer services.
Reference [3] defines the architecture of the API and the functionality on a generic level,
which is independent of specific SLE services and communication technologies. It is thus
necessary to add service type-specific specifications in supplemental Recommended
Practices. The purpose of this document is to specify extensions to the API needed for
support of the Return Operational Control Fields (ROCF) service defined in reference [2].
1.2 SCOPE
This specification defines extensions to the SLE API in terms of:
a) the ROCF-specific functionality provided by API components;
b) the ROCF-specific interfaces provided by API components; and
c) the externally visible behavior associated with the ROCF interfaces exported by the
components.
It does not specify:
a) individual implementations or products;
b) the internal design of the components; and
c) the technology used for communications.
This specification defines only interfaces and behavior that must be provided by
implementations supporting the Return Operational Control Fields service in addition to the
specification in reference [3].
CCSDS 915.5-M-2 Page 1-1 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
1.3 APPLICABILITY
The Application Program Interface specified in this document supports two generations of
Return Operational Control Fields service, namely:
a) Generation 2 identified by the version number 1 in the BIND operation, as specified
by reference [C8];
b) Generation 3 identified by the version number 4 in the BIND operation, as specified
by reference [2].
NOTES
1 The use of the term ‘Generation’ follows the definition in the API Core Specification
(reference [3]) where it is used to classify all SLE Transfer Services.
2 Support for Generation 1 is not valid in this book because the ROCF initial issue was
written as part of Generation 2 of the RAF, RCF and CLTU specific version 1
recommendations.
Support for Generation 2 of the service is included for backward compatibility purposes for a
limited time and may not be continued in future versions of this specification.
Provisions within this Recommended Practice that are specific for a specific generation are
marked as:
– [G2:] for provisions specific to Generation 2;
– [G3:] for provisions specific to Generation 3.
Provisions that apply to all generations are not marked.
1.4 RATIONALE
This Recommended Practice specifies the mapping of the ROCF service specification to
specific functions and parameters of the SLE API. It also specifies the distribution of
responsibility for specific functions between SLE API software and application software.
The goal of this Recommended Practice is to create a standard for interoperability between:
a) application software using the SLE API and SLE API software implementing the SLE
API; and
b) service user and service provider applications communicating with each other using
the SLE API on both sides.
CCSDS 915.5-M-2 Page 1-2 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
This interoperability standard also allows exchangeability of different products implementing
the SLE API, as long as they adhere to the interface specification of this Recommended
Practice.
1.5 DOCUMENT STRUCTURE
1.5.1 ORGANIZATION
This document is organized as follows:
– section 1 provides purpose and scope of this specification, identifies conventions, and
lists definitions and references used throughout the document;
– section 2 provides an overview of the ROCF service and describes the API model
extension including support for the ROCF service defined in reference [2];
– section 3 contains detailed specifications for the API components and for applications
using the API;
– annex A provides a formal specification of the API interfaces and data types specific
to the ROCF service;
– annex B lists all acronyms used within this document;
– annex C lists informative references.
1.5.2 SLE SERVICE DOCUMENTATION TREE
The SLE suite of Recommended Standards is based on the cross support model defined in the
SLE Reference Model (reference [1]). The SLE services constitute one of the three types of
Cross Support Services:
a) Part 1: SLE Services;
b) Part 2: Ground Domain Services; and
c) Part 3: Ground Communications Services.
The SLE services are further divided into SLE Service Management and SLE transfer
services.
The basic organization of the SLE services and SLE documentation is shown in figure 1-1.
The various documents are described in the following paragraphs.
CCSDS 915.5-M-2 Page 1-3 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
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
SLE API for Transfer Services
Core Specification Summary of
Concept and
Rationale
Forward Return
Application
SLE Service SLE Service
Programmer’s
Specifications Specifications
Guide
Recommended Recommended
Legend: Report (Green) Report (Yellow)
Standard (Blue) Practice (Magenta)

Figure 1-1: SLE Services and SLE API Documentation
a) Cross Support Reference Model—Part 1: Space Link Extension Services, a
Recommended Standard that defines the framework and terminology for the
specification of SLE services.
b) Cross Support Concept—Part 1: Space Link Extension Services, a Report introducing
the concepts of cross support and the SLE services.
c) Space Link Extension Services—Executive Summary, an Administrative Report
providing an overview of Space Link Extension (SLE) Services. It is designed to
assist readers with their review of existing and future SLE documentation.
d) Forward SLE Service Specifications, a set of Recommended Standards that provide
specifications of all forward link SLE services.
e) Return SLE Service Specifications, a set of Recommended Standards that provide
specifications of all return link SLE services.
CCSDS 915.5-M-2 Page 1-4 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
f) Internet Protocol for Transfer Services, a Recommended Standard providing the
specification of the wire protocol used for SLE transfer services.
g) SLE Service Management Specifications, a set of Recommended Standards that
establish the basis of SLE service management.
h) Application Program Interface for Transfer Services—Core Specification, a
Recommended Practice document specifying the generic part of the API for SLE
transfer services.
i) Application Program Interface for Transfer Services—Summary of Concept and
Rationale, a Report describing the concept and rationale for specification and
implementation of a Application Program Interface for SLE Transfer Services.
j) Application Program Interface for Return Services, a set of Recommended Practice
documents specifying the service type-specific extensions of the API for return link
SLE services.
k) Application Program Interface for Forward Services, a set of Recommended Practice
documents specifying the service type-specific extensions of the API for forward link
SLE services.
l) Application Program Interface for Transfer Services—Application Programmer’s
Guide, a Report containing guidance material and software source code examples for
software developers using the API.
1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS
1.6.1 DEFINITIONS
1.6.1.1 Definitions from SLE Reference Model
This Recommended Practice makes use of the following terms defined in reference [1]:
a) Return Operational Control Fields service (ROCF service);
b) operation;
c) service provider (provider);
d) service user (user);
e) SLE transfer service instance;
f) SLE transfer service production;
g) SLE transfer service provision.
CCSDS 915.5-M-2 Page 1-5 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
1.6.1.2 Definitions from ROCF Service
This Recommended Practice makes use of the following terms defined in reference [2]:
a) association;
b) communications service;
c) confirmed operation;
d) delivery mode;
e) global VCID;
f) invocation;
g) latency limit;
h) lock status;
i) notification;
j) offline processing latency;
k) parameter;
l) performance;
m) permitted global VCID set;
n) port identifier;
o) production status;
p) return;
q) service instance provision period;
r) transfer buffer;
s) unconfirmed operation;
t) virtual channel.
1.6.1.3 Definitions from ASN.1 Specification
This Recommended Practice makes use of the following term defined in reference [5]:
a) Object Identifier;
b) Octet String.
CCSDS 915.5-M-2 Page 1-6 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
1.6.1.4 Definitions from UML Specification
This Recommended Practice makes use of the following terms defined in reference [C7]:
a) Attribute;
b) Base Class;
c) Class;
d) Data Type;
e) Interface;
f) Method.
1.6.1.5 Definitions from API Core Specification
This Recommended Practice makes use of the following terms defined in reference [3]:
a) Application Programming Interface;
b) Component.
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;
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;
CCSDS 915.5-M-2 Page 1-7 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
– Background;
– Rationale;
– Discussion.
1.6.3 CONVENTIONS
This document applies the conventions defined in reference [3].
The ROCF-specific model extensions in section 2 are presented using the Unified Modeling
Language (UML) and applying the conventions defined in reference [3].
The ROCF-specific specifications for API components in section 3 are presented using the
conventions specified in reference [3].
The ROCF-specific data types and interfaces in annex A are specified in the notation of the
C++ programming language using the conventions defined in reference [3].
1.7 REFERENCES
The following publications contain provisions which, through reference in this text,
constitute provisions of this document. At the time of publication, the editions indicated
were valid. All publications are subject to revision, and users of this document are
encouraged to investigate the possibility of applying the most recent editions of the
publications indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS publications.
NOTE – A list of informative references is provided in annex C.
[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 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.
[3] Space Link Extension—Application Program Interface for Transfer Services—Core
Specification. Issue 2. Recommendation for Space Data System Practices (Magenta
Book), CCSDS 914.0-M-2. Washington, D.C.: CCSDS, September 2015.
[4] Programming Languages—C++. 3rd ed. International Standard, ISO/IEC 14882:2011.
Geneva: ISO, 2011.
CCSDS 915.5-M-2 Page 1-8 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
[5] Information Technology—Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation. 4th ed. International Standard, ISO/IEC 8824-1:2008. Geneva: ISO,
2008.
CCSDS 915.5-M-2 Page 1-9 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
2 OVERVIEW
2.1 INTRODUCTION
This section describes the extension of the SLE API model in reference [3] for support of the
ROCF service. Extensions are needed for the API components API Service Element and
SLE Operations.
In addition to the extensions defined in this section, the component API Proxy must support
encoding and decoding of ROCF-specific protocol data units.
2.2 PACKAGE ROCF SERVICE INSTANCES
2.2.1 GENERAL
The ROCF extensions to the component API Service Element are defined by the package
ROCF Service Instances. Figure 2-1 provides an overview of this package. The diagram
includes classes from the package API Service Element specified in reference [3], which
provide applicable specifications for the ROCF service.
The package adds two service instance classes:
a) ROCF SI User, supporting the service user role; and
b) ROCF SI Provider, supporting service provider role.
These classes correspond to the placeholder classes I_SI User and I_SI
Provider defined in reference [3].
Both classes are able to handle the specific ROCF operations.
For the class ROCF SI User, this is the only extension of the base class SI User.
The class ROCF SI Provider adds two new interfaces:
a) IROCF_SIAdmin by which the application can set ROCF-specific configuration
parameters; and
b) IROCF_SIUpdate by which the application must update dynamic status
information, required for generation of status reports.
These interfaces correspond to the placeholder interfaces I_SIAdmin and
I_SIUpdate defined in reference [3].
ROCF-specific configuration parameters are defined by the internal class ROCF
Configuration. The class ROCF Status Information defines dynamic status parameters
maintained by the service instance.
CCSDS 915.5-M-2 Page 2-1 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
All specifications provided in this section refer to a single service instance. If more than one
service instance is used, each service instance must be configured and updated independently.
2.2.2 COMPONENT CLASS ROCF SI USER
The class defines a ROCF service instance supporting the service user role. It ensures that
SLE PDUs passed by the application and by the association are supported by the ROCF
service and handles the ROCF operation objects defined in 2.3. It does not add further
features to those provided by the base class SI User.

Figure 2-1: ROCF Service Instances
CCSDS 915.5-M-2 Page 2-2 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
2.2.3 COMPONENT CLASS ROCF SI PROVIDER
2.2.3.1 General
The class defines a ROCF service instance supporting the service provider role. It exports
the interfaces IROCF_SIAdmin for configuration of the service instance after creation and
IROCF_SIUpdate for update of dynamic status parameters during operation.
2.2.3.2 Responsibilities
2.2.3.2.1 Service Specific Configuration
The service instance implements the interface IROCF_SIAdmin to set the ROCF-specific
configuration parameters defined by the class ROCF Configuration. The methods of this
interface must be called after creation of the service instance. When all configuration
parameters (including those set via the interface ISLE_SIAdmin) have been set, the method
ISLE_SIAdmin::ConfigCompleted() must be called. This method verifies that all
configuration parameters values are defined and are in the range defined in reference [2].
In addition, the interface IROCF_SIAdmin provides read access to the configuration parameters.
2.2.3.2.2 Update of Dynamic Status Parameters
The class implements the interface IROCF_SIUpdate. The methods of this interface update
status parameters defined by the class ROCF Status Information. In order to ensure that the
status information is always up to date, all changes of status parameters must be reported to the
service instance during its complete lifetime, independent of the state of the service instance.
In addition, the class derives some of the parameters in ROCF Status Information from
ROCF PDUs exchanged between the service provider and the service user. The method used
to update each of the parameters is defined in 2.2.5.
The interface IROCF_SIUpdate provides read access to all status parameters.
2.2.3.2.3 Handling of the ROCF–GET-PARAMETER Operation
The class responds autonomously to ROCF–GET–PARAMETER invocations. It generates
the appropriate ROCF–GET–PARAMETER return using the parameters maintained by the
classes ROCF Configuration and ROCF Status Information.
2.2.3.2.4 Status Reporting
The class generates ROCF–STATUS–REPORT invocations when required using the
parameters maintained by the class ROCF Status Information.
CCSDS 915.5-M-2 Page 2-3 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
2.2.3.2.5 Processing of ROCF Protocol Data Units
The class ensures that SLE PDUs passed by the application and by the association are
supported by the ROCF service and handles the ROCF operation objects defined in 2.3.
2.2.4 INTERNAL CLASS ROCF CONFIGURATION
The class defines the configuration parameters that can be set via the interface
IROCF_SIAdmin. These parameters are defined by reference [2]. Table 2-1 describes how
the service instance uses these parameters.
Table 2-1: ROCF Configuration Parameters
Parameter Used for
delivery-mode
handling of the transfer buffer (enables / disables discarding of
data)
checking of PDUs
ROCF–GET–PARAMETER returns
latency-limit
handling of the transfer buffer in the timely online and complete
online delivery modes
ROCF–GET–PARAMETER returns
permitted-global-VCID-
ROCF–GET–PARAMETER returns
list
checking of ROCF-START invocations
permitted-control-word-
ROCF–GET–PARAMETER returns
type-set
checking of ROCF-START invocations
permitted-TC-VCID-set
ROCF–GET–PARAMETER returns
checking of ROCF-START invocations
permitted-update-mode-set
ROCF–GET–PARAMETER returns
checking of ROCF-START invocations
transfer-buffer-size
handling of the transfer buffer
ROCF–GET–PARAMETER returns
2.2.5 INTERNAL CLASS ROCF STATUS INFORMATION
The class defines dynamic status parameters handled by the service instance. The parameters
are defined by reference [2]. Table 2-2 describes how the service element updates each of the
parameters and how it uses the parameters.
CCSDS 915.5-M-2 Page 2-4 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
Table 2-2: ROCF Status Information
Parameter Update Used for
count of telemetry frames processed for OCF status reports
number-of-frames-
extraction
processed
set by a method of IROCF_SIUpdate
count of ROCF–TRANSFER–DATA invocations status reports
number-of-ocfs-
transmitted
delivered
frame-sync-lock- set by a method of IROCF_SIUpdate status reports
status
symbol-sync-lock- set by a method of IROCF_SIUpdate status reports
status
status reports
subcarrier-lock- set by a method of IROCF_SIUpdate
status
carrier-lock- set by a method of IROCF_SIUpdate status reports
status
status reports
production-status set by a method of IROCF_SIUpdate
requested-global- extracted from ROCF-START-return with a GET-
positive result PARAMETER
VCID
requested-control- extracted from ROCF-START-return with a GET-
positive result PARAMETER
word-type
extracted from ROCF-START-return with a GET-
requested-TC-VCID
positive result PARAMETER
requested-update- extracted from ROCF-START-return with a GET-
positive result PARAMETER
mode
2.3 PACKAGE ROCF OPERATIONS
Figure 2-2 shows the operation object interfaces required for the ROCF service. The package
ROCF Operations adds operation objects for the following ROCF operations:
a) ROCF–START;
b) ROCF–TRANSFER–DATA;
c) ROCF–SYNC–NOTIFY;
d) ROCF–STATUS–REPORT; and
e) ROCF–GET–PARAMETER.
For other operations the API uses the common operation objects defined in reference [3].
CCSDS 915.5-M-2 Page 2-5 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
<>
<> <>
ISLE_ConfirmedOperation ISLE_Operation
(from SLE Operations) (from SLE Operations)
<>
<>
<>
<>
<> <>
<>
ISLE_PeerAbort ISLE_TransferBuffer
(from SLE Operations) (from SLE Operations)
<> <>
IROCF_StatusReport IROCF_SyncNotify
<>
IROCF_TransferData
<>
<>
<>
<>
<>
<>
ISLE_Unbind
<>
<>
(from SLE Operations) IROCF_GetParameter
<>
<>
ISLE_Bind
IROCF_Start
(from SLE Operations)
<> <>
ISLE_Stop ISLE_ScheduleStatusReport
(from SLE Operations) (from SLE Operations)

Figure 2-2: ROCF Operation Object Interfaces
Table 2-3 maps ROCF operations to operation object interfaces.
CCSDS 915.5-M-2 Page 2-6 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
Table 2-3: Mapping of ROCF Operations to Operation Object Interfaces
ROCF Operation Operation Object Interface Defined in Package
ROCF–BIND ISLE_Bind SLE Operations
ROCF–UNBIND ISLE_Unbind SLE Operations
ROCF–START IROCF_Start ROCF Operations
ROCF–STOP ISLE_Stop SLE Operations
ROCF–TRANSFER–DATA IROCF_TransferData ROCF Operations
ROCF–SYNC–NOTIFY ROCF Operations
IROCF_SyncNotify
[TRANSFER-BUFFER] (see note) ISLE_TransferBuffer SLE Operations
ROCF–SCHEDULE–STATUS– SLE Operations
ISLE_ScheduleStatusRe
REPORT
port
ROCF–STATUS–REPORT IROCF_StatusReport ROCF Operations
ROCF–GET–PARAMETER IROCF_GetParameter ROCF Operations
ROCF–PEER–ABORT ISLE_PeerAbort SLE Operations
NOTE – TRANSFER-BUFFER is a pseudo-operation used to handle the transfer buffer
defined in reference [2].
2.4 SECURITY ASPECTS OF THE SLE ROCF TRANSFER SERVICE
2.4.1 SECURITY BACKGROUND/INTRODUCTION
The SLE transfer services explicitly provide authentication and access control. Additional
security capabilities, if required, are levied on the underlying communication services that
support the SLE transfer services. The SLE transfer services are defined as layered
application services operating over underlying communication services that must meet certain
requirements but which are otherwise unspecified. Selection of the underlying
communication services over which real SLE implementations connect is based on the
requirements of the communicating parties and/or the availability of CCSDS-standard
communication technology profiles and proxy specifications. Different underlying
communication technology profiles are intended to address not only different performance
requirements but also different security requirements. Missions and service providers are
expected to select from these technology profiles to acquire the performance and security
capabilities appropriate to the mission. Specification of the various underlying
communication technologies, and in particular their associated security provisions, are
outside the scope of this Recommendation.
CCSDS 915.5-M-2 Page 2-7 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
The SLE ROCF transfer service transfers data that originates on a mission spacecraft. As
such, the SLE ROCF transfer service has custody of the data for only a portion of the end-to-
end data path between mission spacecraft and MDOS. Consequently the ability of an SLE
transfer service to secure the transfer of mission spacecraft data is limited to that portion of
the end-to-end path that is provided by the SLE transfer service (i.e., the terrestrial link
between the MDOS and the ground termination of the space-ground link to the mission
spacecraft). End-to-end security must also involve securing the data as it crosses the space-
ground link, which can be provided by some combination of securing the mission data itself
(e.g., encryption of the mission data within CCSDS space packets) and securing the space-
ground link (e.g., encryption of the physical space-ground link). Thus while the SLE ROCF
transfer service plays a role in the end-to-end security of the data path, it does not control and
cannot ensure that end-to-end security. This component perspective is reflected in the security
provisions of the SLE transfer services.
2.4.2 STATEMENTS OF SECURITY CONCERNS
2.4.2.1 Overview
This subsection identifies ROCF transfer service support for capabilities that responds to
these security concerns in the areas of data privacy, data integrity, authentication, access
control, availability of resources, and auditing.
2.4.2.2 Data Privacy (also known as Confidentiality)
This SLE ROCF transfer service specification does not define explicit data privacy
requirements or capabilities to ensure data privacy. Data privacy is expected to be ensured
outside of the SLE transfer service layer, by the mission application processes that
communicate over the SLE transfer service, in the underlying communication service that lies
under the SLE transfer service, or some combination of both. For example, mission
application processes might apply end-to-end encryption to the contents of the CCSDS space
link data units carried as data by the SLE transfer service. Alternatively or in addition, the
network connection between the SLE entities might be encrypted to provide data privacy in
the underlying communication network.
2.4.2.3 Data Integrity
The SLE ROCF transfer service defines and enforces a strict sequence of operations that
constrain the ability of a third party to inject operation invocations or returns into the transfer
service association between a service user and provider (see 4.2.2 in reference [2]). This
constrains the ability of a third party to seize control of an active ROCF transfer service
instance without detection.
The SLE ROCF transfer service requires that the underlying communication service transfer
data in sequence, completely and with integrity, without duplication, with flow control that
CCSDS 915.5-M-2 Page 2-8 September 2015
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE ROCF SERVICE
notifies the application layer in the event of congestion, and with notification to the
application layer in the event that communication between the service user and the service
provider is disrupted (see 1.3.1 in reference [2]). No specific mechanisms are identified, as
they will be an integral part of the underlying communication service.
2.4.2.4 Authentication
This SLE ROCF transfer service specification defines authentication requirements (see 3.1.5
in reference [2]), and defines initiator-identifier, responder-identifier,
invoker-credentials, and performer-credentials parameters of the service
operation invocations and returns that are used to perform SLE transfer service
authentication. The procedure by which SLE transfer service operation invocations and
returns are authenticated is described in annex F of the Cross Support Service Green Book
(reference [C2]). The SLE transfer service authentication capability can be selectively set to
authenticate at one of three levels: authenticate every invocation and retu
...