CAUTION - This text file is provided for the sole purpose of allowing text-string searching. It is NOT a faithful reproduction of the published document: figures, equations, special characters, and character attributes used to convey information are not reproduced in this text file; tables, which may be reproduced as text, may have lost crucial row or column alignment. A Portable Document Format (PDF) version of this document is available in the main document listing. The PDF file contains all elements of the document as published by the CCSDS. The PDF file should be used in all cases where there is a need for faithful reproduction of the information contained in the published document. CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS RECOMMENDATION FOR SPACE DATA SYSTEM STANDARDS SPACE LINK EXTENSION--FORWARD CLTU SERVICE SPECIFICATION CCSDS 912.1-B-1 BLUE BOOK April 2002 [IMAGE]AUTHORITY Issue: Blue Book, Issue 1 Date: April 2002 Location: Oberpfaffenhofen, Germany 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 [E1], 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 M-3) National Aeronautics and Space Administration Washington, DC 20546, USA 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 Recommendation is issued, existing CCSDS-related Agency standards and implementations are not negated or deemed to be non-CCSDS compatible. It is the responsibility of each Agency to determine when such standards or implementations are to be modified. Each Agency is, however, strongly encouraged to direct planning for its new standards and implementations towards the later version of the Recommendation. FOREWORD This document is a technical Recommendation for use in developing ground systems for space missions and has been prepared by the Consultative Committee for Space Data Systems (CCSDS). The Space Link Extension (SLE) Forward Command Link Transmission Unit (CLTU) Service described herein is intended for missions that are cross supported between Agencies of the CCSDS. This Recommendation specifies a data service that extends certain of the space-to-ground communications services previously defined by CCSDS (references [2] and [3]) within the framework established by the CCSDS SLE Reference Model (reference [1]). 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 Recommendation and may incorporate features not addressed by the Recommendation. Through the process of normal evolution, it is expected that expansion, deletion or modification to this document may occur. This Recommendation is therefore subject to CCSDS document management and change control procedures, as defined in reference [E1]. 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. At time of publication, the active Member and Observer Agencies of the CCSDS were: Member Agencies - Agenzia Spaziale Italiana (ASI)/Italy. - British National Space Centre (BNSC)/United Kingdom. - Canadian Space Agency (CSA)/Canada. - Centre National d'Etudes Spatiales (CNES)/France. - Deutsches Zentrum fuer 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 Centre (CRC)/Canada. - 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. - 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. - Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan. - Swedish Space Corporation (SSC)/Sweden. - United States Geological Survey (USGS)/USA. DOCUMENT CONTROL Document Title Date Status and Substantive Changes CCSDS Space Link April Original Issue 912.1-B-1 Extension--Forward 2002 CLTU Service Specification CONTENTS Section Page 1 INTRODUCTION 1-1 1.1PURPOSE OF THIS RECOMMENDATION 1-1 1.2SCOPE 1-1 1.3APPLICABILITY 1-1 1.4RATIONALE 1-2 1.5DOCUMENT STRUCTURE 1-2 1.6DEFINITIONS, NOMENCLATURE, AND CONVENTIONS 1-4 1.7REFERENCES 1-12 2 DESCRIPTION OF THE FORWARD CLTU SERVICE 2-1 2.1OVERVIEW 2-1 2.2SPACE LINK EXTENSION REFERENCE MODEL 2-2 2.3SERVICE MANAGEMENT 2-3 2.4ARCHITECTURE MODEL - FUNCTIONAL VIEW 2-4 2.5ARCHITECTURE MODEL - CROSS-SUPPORT VIEW 2-6 2.6FUNCTIONAL DESCRIPTION 2-8 2.7OPERATIONAL SCENARIO 2-15 3 OPERATIONS AND THEIR PARAMETERS 3-1 3.1GENERAL CONSIDERATIONS 3-1 3.2CLTU-BIND 3-7 3.3CLTU-UNBIND 3-14 3.4CLTU-START 3-17 3.5CLTU-STOP 3-21 3.6CLTU-TRANSFER-DATA 3-24 3.7CLTU-ASYNC-NOTIFY 3-30 3.8CLTU-SCHEDULE-STATUS-REPORT 3-36 3.9CLTU-STATUS-REPORT 3-40 3.10 CLTU-GET-PARAMETER 3-45 3.11 CLTU-THROW-EVENT 3-49 3.12 CLTU-PEER-ABORT 3-53 4 CLTU PROTOCOL 4-1 4.1GENERIC PROTOCOL CHARACTERISTICS 4-1 4.2CLTU SERVICE PROVIDER BEHAVIOR 4-4 CONTENTS (CONTINUED) Section Page ANNEX A DATA TYPE DEFINITIONS A-1 ANNEX B INDEX TO DEFINITIONS B-1 ANNEX C ACRONYMS C-1 ANNEX D CONFORMANCE OPTIONS MATRIX D-1 ANNEX E INFORMATIVE REFERENCES E-1 ANNEX F THROW EVENT DEFINITIONS F-1 ANNEX G PRODUCTION STATUS G-1 Figure 1-1Space Link Extension (SLE) Services Documentation 1-4 2-1Forward TC Space Link Processing SLE-FG 2-4 2-2Forward CLTU Service Production and Provision 2-6 2-3Example of Management and Provision of Forward CLTU Service 2- 7 2-4Forward CLTU Service Provider State Transition Diagram2-10 2-5Communications Realization of Forward CLTU Service 2-13 G-1CLTU Production Status Transitions G-1 Table 2-1Forward CLTU Service Operations 2-9 3-1Setting of Forward CLTU Service Configuration Parameters3-7 3-2CLTU-BIND Parameters 3-8 3-3CLTU-UNBIND Parameters 3-15 3-4CLTU-START Parameters 3-17 3-5CLTU-STOP Parameters 3-21 3-6CLTU-TRANSFER-DATA Parameters 3-24 3-7CLTU-ASYNC-NOTIFY Parameters 3-30 3-8CLTU-SCHEDULE-STATUS-REPORT Parameters 3-36 3-9CLTU-STATUS-REPORT Parameters 3-40 3-10 CLTU-GET-PARAMETER Parameters 3- 45 3-11 Forward CLTU Parameters 3- 47 3-12 CLTU-THROW-EVENT Parameters 3- 50 3-13 CLTU-PEER-ABORT Parameters 3- 53 4-1Behavior of Provider 4-7 4-2Event Description References 4-10 4-3Predicate Definitions 4-10 4-4Boolean Flags 4-11 4-5Compound Action Definitions 4-11 CONTENTS (CONTINUED) Table Page D-1Conformance Matrix for CLTU Service (Operations) D-1 D-2Conformance Matrix for CLTU Service (Other Requirements)D-2 F-1Throw Event Examples F-1 G-1Production Status Changes and Notifications G-2 G-2Effect of Production Status on Operations G-3 1 INTRODUCTION 1.1 PURPOSE OF THIS RECOMMENDATION This Recommendation defines the Command Link Transmission Unit (CLTU) service in conformance with the transfer services specified in reference [1], Cross Support Reference Model--Part 1: SLE Services. The Forward CLTU service is a Space Link Extension (SLE) transfer service that enables a mission to send Command Link Transmission Units (CLTUs) to a spacecraft. 1.2 SCOPE 1.2.1 This Recommendation defines, in an abstract manner, the Forward CLTU service in terms of: 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. 1.2.2 It does not specify: a) individual implementations or products; b) the implementation of entities or interfaces within real systems; c) the methods or technologies required to radiate data to a spacecraft and to acquire telemetry frames from the signals received from the spacecraft for extraction of the Operational Control Field; d) the methods or technologies required for communications; e) the management activities necessary to schedule, configure, and control the Forward CLTU service. 1.3 APPLICABILITY 1.3.1 APPLICABILITY OF THIS RECOMMENDATION This Recommendation provides a basis for the development of real systems that implement the Forward CLTU service. Implementation of the Forward CLTU service in a real system additionally requires the availability of a communications service to convey invocations and returns of Forward CLTU service operations between service users and providers. This Recommendation requires that such a communications service ensure that invocations and returns of operations are transferred: a) in sequence; b) completely and with integrity; c) without duplication; d) with flow control that notifies the application layer in the event of congestion; and e) with notification to the application layer in the event that communications between the Forward CLTU service user and the Forward CLTU service provider are disrupted, possibly resulting in a loss of data. It is the specific intent of this Recommendation to define the Forward CLTU service in a manner that is independent of any particular communications services, protocols, or technologies. 1.3.2 LIMITS OF APPLICABILITY This Recommendation specifies the Forward CLTU service that may be provided 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 Recommendation is to create a standard for interoperability between the tracking stations or ground data handling systems of various agencies and the users of forward services. 1.5 DOCUMENT STRUCTURE 1.5.1 DOCUMENT ORGANIZATION This Recommendation is organized as follows: a) section 1 provides purpose, scope, applicability, and rationale of this Recommendation and lists definitions, nomenclature, conventions, and references used throughout the Recommendation; b) section 2 presents an overview of the Forward CLTU service including a functional description, the service management context, and protocol considerations; c) section 3 specifies the operations of the Forward CLTU service; d) section 4 specifies the dynamic behavior of the Forward CLTU service in terms of the state transitions of the Forward CLTU service provider; e) annex A is a formal specification of Forward CLTU service data types, using the Abstract Syntax Notation One (ASN.1); f) annex B lists all terms used in this document and identifies where they are defined; g) annex C lists all acronyms used within this document; h) annex D provides a conformance matrix that defines what capabilities must be provided for an implementation to be considered compliant with this Recommendation; i) annex E contains a list of informative references; j) annex F contains examples of usage of the CLTU-THROW-EVENT operation; k) annex G explains the relationship of the Forward CLTU service to the status of the forward space link channel. 1.5.2 SLE SERVICES DOCUMENTATION TREE This Recommendation is based on the architectural model for cross support defined in the SLE Reference Model (reference [1]). It expands upon the concept of an SLE transfer service as interactions between SLE Mission User Entities (MUEs) and an SLE transfer service provider for the purpose of providing the Forward CLTU transfer service. This Recommendation 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 Communications Services; c) Part 3: Ground Domain Services. The basic organization of the SLE services documentation is shown in figure 1-1. The documents are described in the following paragraphs. [IMAGE] Figure 1-1: Space Link Extension (SLE) Services Documentation a) Standard Terminology, Conventions and Methodology (TCM) for Defining Data Services (reference [E3]): a Report identifying selected international standards relevant for the definition of data services; b) Cross Support Concept - Part 1: Space Link Extension Services (reference [E4]): a Report introducing the concepts of cross support and SLE services; c) Cross Support Reference Model--Part 1: Space Link Extension Services (reference [1]): a Recommendation that defines the framework and terminology for the specification of SLE services; d) SLE Service Management Specification Suite; a set of Recommendations that establish the basis for SLE service management (reference [E5] is the primary Recommendation in that set); e) Forward SLE Transfer Service Specifications; a set of Recommendations that will provide specification of all forward link SLE transfer services (this Recommendation is one of the specifications in that set); f) Return SLE Transfer Service Specifications; a set of Recommendations that will provide specification of all return link SLE transfer services. 1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS 1.6.1 DEFINITIONS 1.6.1.1 Definitions from OSI Basic Reference Model This Recommendation makes use of a number of terms defined in reference [7]. The use of those terms in this Recommendation shall be understood in a generic sense; i.e., in the sense that those terms are generally applicable to technologies that provide for the exchange of information between real systems. Those terms are: a) abstract syntax; b) application entity; c) application layer; d) flow control; e) Open System Interconnection (OSI); f) real system; g) service access point (SAP). 1.6.1.2 Definitions from OSI Abstract Syntax Notation One This Recommendation makes use of the following terms defined in reference [6]: a) Abstract Syntax Notation One (ASN.1); b) object identifier; c) (data) type; d) (data) value. NOTE In annex A of this Recommendation, ASN.1 is used for specifying the abstract syntax of the invocations and returns of the operations of the Forward CLTU service. The use of ASN.1 as a descriptive language is intended to support the specification of the abstract Forward CLTU service; it is not intended to constrain implementations. In particular, there is no requirement for implementations to employ ASN.1 encoding rules. ASN.1 is simply a convenient tool for formally describing the abstract syntax of the invocations and returns of the Forward CLTU service. 1.6.1.3 Definitions from OSI Directory - Part 2: Models This Recommendation makes use of the following terms defined in reference [8]: a) distinguished name (DN); b) relative distinguished name (RDN). 1.6.1.4 Definitions from CCSDS Telecommand Channel Service This Recommendation makes use of the following terms defined in reference [2]: a) acquisition sequence; b) command link transmission unit (CLTU); c) carrier modulation mode (CMM); d) idle sequence; e) physical layer operations procedure (PLOP). 1.6.1.5 Definitions from CCSDS Telecommand Data Routing Service This Recommendation makes use of the following term defined in reference [3]: command link control word (CLCW). 1.6.1.6 Definitions from CCSDS SLE Reference Model This Recommendation makes use of the following terms defined in reference [1]: a) abstract binding; b) abstract object; c) abstract port; d) abstract service; e) CLTU channel; f) Forward CLTU service; g) invoker; h) Mission Data Operation System (MDOS); i) Mission User Entity (MUE); j) offline delivery mode; k) online delivery mode; l) operation; m) performer; n) physical channel; o) service agreement; p) service provider (provider); q) service user (user); r) SLE Complex; s) SLE Complex Management; t) SLE data channel; u) SLE functional group (SLE-FG); v) SLE protocol data unit (SLE-PDU); w) SLE service data unit (SLE-SDU); x) SLE service package; y) SLE System; z) SLE transfer service instance; aa) SLE transfer service production; bb) SLE transfer service provision; cc) SLE Utilization Management; dd) space link; ee) space link data channel; ff) space link data unit (SL-DU); gg) space link session. 1.6.1.7 Additional Definitions 1.6.1.7.1 General For the purposes of this Recommendation, the following definitions also apply. 1.6.1.7.2 Association An association is a cooperative relationship between an SLE service-providing application entity and an SLE service-using application entity. An association is formed by the exchange of SLE protocol data units through use of an underlying communications service. 1.6.1.7.3 Communications Service A communications service is a capability that enables an SLE service-providing application entity and an SLE service-using application entity to exchange information. NOTE - If an SLE service user and an SLE service provider are implemented using different communications services, then interoperability between them is possible only by means of a suitable gateway. Adherence to this Recommendation ensures, at least in principle, that it is possible to construct such a gateway. 1.6.1.7.4 Confirmed Operation A confirmed operation is an operation that requires the performer to return a report of its outcome to the invoker. 1.6.1.7.5 Initiator The initiator is the object that issues the request to bind to another object (the responder). 1.6.1.7.6 Invocation The invocation of an operation is the making of a request by an object (the invoker) to another object (the performer) to carry out the operation. 1.6.1.7.7 Parameter A parameter of an operation is data that may accompany the operation's invocation or return. NOTE - The term parameter is also used to refer to mission- dependent configuration information used in production or provision of the service. 1.6.1.7.8 Performance The performance of an operation is the carrying out of the operation by an object (the performer). 1.6.1.7.9 Port Identifier A port identifier identifies a source or a destination in a communications system. NOTE - See 2.6.4.6 for more information. 1.6.1.7.10 Responder The responder is the object that receives a request to bind and completes the binding (if possible) with the initiator in order for a service association to exist between the two objects. 1.6.1.7.11 Return The return of an operation is a report, from the performer to the invoker, of the outcome of the performance of the operation. 1.6.1.7.12 Service Instance Provision Period The service instance provision period is the time during which a service instance (i.e., the capability to transfer one or more SLE data channels of a given type) is scheduled to be provided. 1.6.1.7.13 Unconfirmed Operation An unconfirmed operation is an operation that does not require a report of its outcome to be returned to the invoker by the performer. 1.6.2 NOMENCLATURE The following conventions apply throughout this Recommendation: a) the words 'shall' and 'must' imply a binding and verifiable specification; b) the word 'should' implies an optional, but desirable, specification; c) the word 'may' implies an optional specification; d) the words 'is', 'are', and 'will' imply statements of fact. 1.6.3 CONVENTIONS 1.6.3.1 Specification of Operations 1.6.3.1.1 General Section 3 of this Recommendation specifies the operations that constitute the Forward CLTU service. The specification of each operation is divided into subsections as follows: 1.6.3.1.2 Purpose Subsection The Purpose subsection briefly describes the purpose and functioning of the operation. Additionally, it indicates whether the operation may be invoked by the user, provider, or both; whether the operation is confirmed or unconfirmed; and whether there are any constraints on when the operation may be invoked. 1.6.3.1.3 Invocation, Return, and Parameters Subsection The Invocation, Return, and Parameters subsection describes the parameters associated with each operation, including their semantics. A table accompanying the description of each operation lists all parameters associated with the operation and, for both the invocation and return, whether the parameter is always present, always absent, or conditionally present. For parameters that are conditionally present, the parameter description specifies the conditions for the presence or absence of the parameter. The condition is generally based on the value of another parameter in the same invocation or return; for example, in return of an operation, the parameter diagnostic is present if and only if the value of the parameter result is 'negative result'. For a conditional parameter in a return, the condition may be based on the value of a parameter in the corresponding invocation. In the table, the following convention is used to indicate whether a parameter is always present, always absent, or conditionally present: M Always present (Mandatory) C Conditionally present Blank Always absent NOTE - Even though a parameter may be characterized as always present, its description may specify that its value is permitted to be 'null' or 'unused' or the like. 1.6.3.1.4 Effects Subsection The Effects subsection describes the effects an operation has on the invoker, the performer, the association between them, or any combination thereof. The details of how those effects occur or the mechanisms used are outside the scope of this Recommendation. 1.6.3.2 Typographic Conventions 1.6.3.2.1 Operation Names Names of Forward CLTU service operations always appear in uppercase and begin with the characters 'CLTU-' (e.g., CLTU- TRANSFER-DATA). 1.6.3.2.2 Parameter Names In the main text, names of parameters of Forward CLTU service operations generally appear in lowercase and are always typeset in a fixed-width font (e.g., responder-port-identifier). In annex A, the corresponding name is generally formed by omitting any hyphens contained in the name and using mixed-case (e.g., responderPortIdentifier). 1.6.3.2.3 Value Names The values of many parameters discussed in this Recommendation are represented by names. In the main text, these names are shown in single quotation marks (e.g., 'no such service instance'). The corresponding name in annex A is generally formed by omitting any hyphens or white space contained in the name and using mixed-case (e.g., noSuchServiceInstance). The actual value associated with the name is constrained by the type of the parameter taking on this value. Parameter types are specified in annex A of this Recommendation. NOTE - The name of a value does not imply anything about type. For example, the value 'no such service instance' has the appearance of a character string but might be assigned to a parameter whose type is 'integer'. 1.6.3.2.4 State Names This Recommendation specifies the states of Forward CLTU service providers. States may be referred to by number (e.g., state 3) or by name. State names are always shown in single quotation marks (e.g., 'active'). 1.6.3.2.5 SLE-PDU Names The names of SLE-PDUs appear in mixed-case (e.g., cltuBindInvocation). 1.6.3.2.6 Data Type Definitions Data type definitions for the Forward CLTU service are presented in annex A in the form of a set of ASN.1 modules. Regardless of the conventions used elsewhere in this Recommendation, the text of the ASN.1 modules is typeset entirely in a fixed-width font. 1.6.3.3 Other Conventions This Recommendation uses the conventions specified in reference [1]. 1.7 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 documents indicated below. The CCSDS Secretariat maintains a register of currently valid CCSDS Recommendations. NOTE - A list of informative references forms annex E of this Recommendation. [1]Cross Support Reference Model -- Part 1: Space Link Extension Services. Recommendation for Space Data System Standards, CCSDS 910.4-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 1996. [2]Telecommand Part 1--Channel Service. Recommendation for Space Data System Standards, CCSDS 201.0-B-3. Blue Book. Issue 3. Washington, D.C.: CCSDS, June 2000. [3]Telecommand Part 2--Data Routing Service. Recommendation for Space Data System Standards, CCSDS 202.0-B-3. Blue Book. Issue 3. Washington, D.C.: CCSDS, June 2001. [4]Telecommand Part 2.1--Command Operation Procedures. Recommendation for Space Data System Standards, CCSDS 202.1-B- 2. Blue Book. Issue 2. Washington, D.C.: CCSDS, June 2001. [5]Time Code Formats. Recommendation for Space Data System Standards, CCSDS 301.0-B-3. Blue Book. Issue 3. Washington, D.C.: CCSDS, January 2002. [6]Information Technology--Open Systems Interconnection-- Specification of Abstract Syntax Notation One (ASN.1). International Standard, ISO/IEC 8824:1990. 2nd ed. Geneva: ISO, 1990. [7]Information Technology--Open Systems Interconnection--Basic Reference Model: The Basic Model. International Standard, ISO/IEC 7498-1. 2nd ed. Geneva: ISO, 1994. [8]Information Technology--Open Systems Interconnection--The Directory: Models. International Standard, ISO/IEC 9594- 2:1998. 3rd ed. Geneva: ISO, 1998. 2 DESCRIPTION OF THE FORWARD CLTU SERVICE 2.1 OVERVIEW The Forward CLTU service enables the user of the service to send Command Link Transmission Units (CLTUs) to a spacecraft via an established forward space link channel. A forward space link channel is a physical channel carrying an asynchronous stream of CLTUs (reference [1]). The service user submits CLTUs, encapsulated in Space Link Extension (SLE) Service Data Units (SLE-SDUs), by means of the CLTU-TRANSFER-DATA operation. Production of the Forward CLTU service by the provider entails processing the CLTUs transferred by the user through the necessary transformations to modulate the Radio Frequency (RF) carrier channel providing uplink communications with the spacecraft. The Forward CLTU service transmits the CLTUs in the order in which they are submitted by the service user. The provider may perform checks to determine if the CLTU complies with applicable constraints, e.g., that the length of the CLTU is within the maximum size set by service management. However, the provider does not interpret, interrogate, or modify the contents of a CLTU. CLTUs are transmitted bit for bit as received from the service user. CLTUs may or may not conform to the format defined in reference [2]. The Forward CLTU service may be used to uplink any octet- aligned bit pattern. The operations defined in section 3 of this Recommendation enable a single Forward CLTU service user to interact with a Forward CLTU service provider to: a) establish an association between the user and the provider; b) send annotated CLTUs to the provider; c) obtain notifications and reports regarding status, configuration, and performance of the service; d) temporarily stop and later re-start the sending of CLTUs; e) release an association. The Sequence Controlled (AD) and Expedited (BD) Services, as defined in the Command Operation Procedures (COP) Recommendation (reference [4]) are accomplished by higher layer SLE services. The Forward CLTU service is provided only in the online delivery mode, as defined in reference [1]. The offline delivery mode is the subject of further study. The provision of Forward CLTU service for access to one physical channel by one service user constitutes one instance of service. Only a single service instance of the Forward CLTU service may exist per physical channel at a time. 2.2 SPACE LINK EXTENSION REFERENCE MODEL 2.2.1 INTRODUCTION The Forward CLTU service is specified within the framework defined by the SLE Reference Model (reference [1]). The following paragraphs summarize selected concepts from the SLE reference model. 2.2.2 ABSTRACT OBJECT An abstract object is a functional entity that interacts with other abstract objects. Objects are of different types, which determine their function and behavior. An object is characterized by its interfaces (one or more), which are called abstract ports, and the operations that are made available through those interfaces. 2.2.3 ABSTRACT SERVICE An abstract service is the capability provided by a set of operations that an abstract object exposes at one or more of its abstract ports.1 2.2.4 ABSTRACT BINDING When two abstract ports have an association established between them, they are said to be bound. The act of establishing such an association is called abstract binding. One object (the initiator) invokes a bind operation which is accepted (or rejected) by another object (the responder). 2.2.5 SERVICE USER/PROVIDER An object that offers a service to another by means of one or more of its ports is called a service provider (provider). The other object is called a service user (user). An object may be a provider of some services and a user of others. The terms user and provider are used to distinguish the roles of two interacting objects. In this Recommendation, when two objects are involved in provision of a service, the object closer to the space link is considered to be the provider of the service, and the object further from the space link is considered to be the user. 2.2.6 OPERATION An operation is a procedure or task that one object (the invoker) can request of another (the performer) through a bound port pair. The terms invoker and performer are used to describe the interaction between two objects as the operations that constitute the service occur. One object invokes an operation that is performed by the other. For most services, each object invokes some operations and performs others. 2.3 SERVICE MANAGEMENT 2.3.1 INTRODUCTION Service management determines the number and schedule of Forward CLTU service instances to be provided, the resources required to enable those service instances, and the initial configuration of all service instances and their supporting resources. SLE service management is the subject of separate CCSDS Recommendations. The SLE Reference Model (reference [1]) distinguishes between service provision and service production: a) service provision makes available to the user the operations necessary to obtain the service; b) service production transforms the Forward CLTU data channel to the RF carrier channel. 2.3.2 CONFIGURATION Service Management provides initial values of configuration parameters. Certain configuration parameters are associated with provision of Forward CLTU service while others are associated with production. Configuration parameters that are associated with the production, such as bit rate and modulation index, can potentially impact SLE Complex resources. Consequently, only service management may modify production configuration parameter values. The Forward CLTU service user may modify some provision configuration parameters through operations specified in this Recommendation. 2.4 ARCHITECTURE MODEL - FUNCTIONAL VIEW 2.4.1 FORWARD TC SPACE LINK PROCESSING SLE FUNCTIONAL GROUP The Forward Telecommand (TC) Space Link Processing SLE Functional Group (SLE-FG) (shown in figure 2-1) produces the Forward CLTU service. As described in reference [1], the Forward TC Space Link Processing SLE-FG consumes one CLTU data channel consisting of a stream of CLTU SLE-SDUs. The SLE-SDUs that encapsulate the CLTUs contain control and annotation data that specify radiation time and other parameters to aid in processing the data (see 3.6). The Forward TC Space Link Processing SLE-FG uses these data to extract the CLTUs and inject them into the asynchronous physical channel. NOTE - Per physical forward channel, only a single instance of the Forward CLTU service is supported at any point in time. [IMAGE] Figure 2-1: Forward TC Space Link Processing SLE-FG The Forward TC Space Link Processing SLE-FG performs the following functions with respect to the Forward CLTU service: a) consumes one CLTU data channel and extracts CLTUs encapsulated in SLE Service Data Units (SLE-SDUs); b) consumes one Operational Control Field (OCF) data channel and extracts the Command Link Control Words (CLCWs). Based on the values in the CLCWs, the Forward CLTU service determines whether the physical channel is available; NOTE - CLCWs may be ignored, as an option set by Service Management. See 3.1.10 and table 3-11. c) performs the following: 1) generates the acquisition sequence and idle sequence on the physical channel in accordance with the PLOP in effect; 2) utilizes the underlying antenna steering capabilities provided by the ground element; 3) modulates the CLTUs as a stream of bits on the ground-to- space RF channel; and 4) radiates the signal to the spacecraft. 2.4.2 FORWARD CLTU SERVICE PRODUCTION AND PROVISION Forward CLTU production is concerned with radiating CLTUs extracted from a stream of SLE-SDUs according to the CLTU control and annotation information in the SLE-SDU and according to the configuration set up by service management. Forward CLTU service provision is concerned with receiving a stream of SLE-SDUs from a Forward CLTU service user. Service provision addresses such matters as when service is provided (e.g., service start and stop times), and how service is provided (e.g., which events are notified to the user). The SLE-SDUs consumed by the Forward CLTU service are sent by the service user by means of the Forward CLTU service operations defined in section 3. These operations also provide additional functionality to facilitate the provision of service, i.e., enabling the exchange of SLE-SDUs across a remote interface. The service operations are realized as SLE protocol data units (SLE- PDUs) which are exchanged between the Forward CLTU service provider and the Forward CLTU service user by means of an underlying communications service. The general relationship between SL-DUs, SLE-SDUs, and SLE-PDUs is illustrated in figure 2-2. NOTE - SLE-SDUs correspond to the parameters of the CLTU- TRANSFER-DATA and CLTU-ASYNC-NOTIFY operations defined in section 3. SL-DUs correspond to the radiated CLTUs. [IMAGE] Figure 2-2: Forward CLTU Service Production and Provision Production of the Forward CLTU service by the provider occurs during the space link session; in general, service production will largely overlap with service provision. Production status affects the provision of the service, as specified in sections 3 and 4, and reviewed in annex G. 2.5 ARCHITECTURE MODEL - CROSS-SUPPORT VIEW The management and control of the production and provision of the SLE transfer services is described in general terms in reference [1]. Figure 2-3 shows an example operational scenario and the related binding of the Forward CLTU transfer service ports and SLE management ports. This example shows an SLE Complex with one Forward Space Link Processing SLE-FG instance; it is providing one instance of Forward CLTU service to a Mission Data Operations System (MDOS). As this figure shows, only a single Mission User Entity can use the Forward CLTU service provided by a single Forward Space Link Processing SLE-FG. [IMAGE] Figure 2-3: Example of Management and Provision of Forward CLTU Service 2.6 FUNCTIONAL DESCRIPTION 2.6.1 INTRODUCTION This subsection describes the Forward CLTU service with respect to scheduling, configuration, underlying services, provider states and protocol considerations. 2.6.2 SCHEDULING AND CONFIGURATION The management of the SLE Complex that is providing the Forward CLTU service negotiates with SLE Utilization Management of the MDOS to establish mutually agreed upon SLE service packages. Among other things, SLE service packages specify the services to be provided, the schedules of service instances, and the resources needed to enable those services. Service packages also specify the initial values of the mission- dependent parameters required for service production and provision. Forward CLTU service production parameters include such things as bit rate, modulation index, and subcarrier frequency. Provision parameters include such things as scheduled start and stop times of the Forward CLTU service instance. Service production is guaranteed to occur only as needed to support service packages that have been scheduled and mutually agreed upon by SLE Complex Management and SLE Utilization Management. Service provision occurs only within the bounds of the agreed upon schedule of service instances and only during those periods when there is an association between the service provider and the service user. 2.6.3 UNDERLYING SERVICES The CLTU service does not depend on any other SLE transfer service. Provision of the CLTU Transfer service does depend on: a) service management for scheduling, resources, and configuration; the schedule for a Forward CLTU service instance must be compliant with the schedule of the underlying equipment such as antennas, etc. The Forward CLTU service relies on service management actions for establishment of the space link, management of the PLOP and, when possible, recovery from production interruption; b) the availability of a suitable communications service to enable the exchange of information between the CLTU service user and provider; and c) the functioning of CLTU production resources (e.g., modulator(s), up-converter) to produce the forward physical channel. 2.6.4 PROTOCOL DESCRIPTION 2.6.4.1 CLTU Operations The operations that constitute the Forward CLTU service are listed in table 2-1. Section 3 of this Recommendation contains the detailed specification of these operations. Table 2-1: Forward CLTU Service Operations Service Invok Purpose Con- Operation ed By firme d CLTU-BIND User To establish an association Yes with the provider CLTU-UNBIND User To release an association Yes previously established by a CLTU-BIND operation CLTU-START User To request that the SLE Yes service provider prepare to accept CLTU-TRANSFER-DATA operations CLTU-STOP User To request that the SLE Yes service provider stop service provision and production. CLTU-TRANSFER- User To transfer a CLTU to the Yes DATA service provider CLTU-ASYNC- Provi To notify the user of an event No NOTIFY der affecting production or provision of the Forward CLTU service CLTU-SCHEDULE- User To request that the provider Yes STATUS-REPORT send a status report immediately or periodically, or stop reporting CLTU-STATUS- Provi To send a status report to the No REPORT der user CLTU-GET- User To ascertain the value of an Yes PARAMETER SLE service parameter (see table 3-11) CLTU-THROW-EVENT User To forward an event that Yes requires Complex Management to take the actions defined for this event CLTU-PEER-ABORT User To notify the peer system that No or the local system detected an Provi error that requires the der association to be terminated 2.6.4.2 States of the Service Provider Once a Forward CLTU service instance is created, the Forward CLTU service provider is in one of three states, as follows: a) State 1 ('unbound'): In state 1, all resources required to enable the provision of the Forward CLTU service have been allocated, and all objects required to provide the service have been instantiated. However, no association yet exists between the user and the provider (i.e., the Forward CLTU transfer service provider port is not bound). b) State 2 ('ready'): In state 2, an association has been established between the user and the provider, and they may interact by means of the operations described in section 3 of this Recommendation. However, sending of CLTUs from the user to the provider (by means of the CLTU-TRANSFER-DATA operation) is not permitted. The user may enable the delivery of CLTUs by means of the appropriate service operation (CLTU-START), which, in turn, will cause the provider to transition to state 3 ('active'). c) State 3 ('active'): State 3 resembles state 2 ('ready'), except that now the user can send CLTUs and the provider is enabled to radiate CLTUs to the spacecraft. The service continues in this state until the user invokes the CLTU-STOP operation to cause the provider to suspend transmission of CLTUs and transition back to state 2. A simplified state transition diagram for the Forward CLTU service provider is shown in figure 2-4. A detailed state transition matrix is provided in section 4. [IMAGE] Figure 2-4: Forward CLTU Service Provider State Transition Diagram 2.6.4.3 Terminating an Association An association is released normally when a CLTU-UNBIND is issued by the user (the initiator of the association) and accepted by the provider. An association may be aborted by either the user or the provider by means of the CLTU-PEER-ABORT operation. An association may also be aborted because of a failure in the underlying communications system. Such failures are signaled to the local application by the 'protocol abort' event described in 4.1.5. 2.6.4.4 Effects of Association Termination The production of CLTUs stops immediately following the termination of an association, except for a CLTU in the process of being radiated. Any buffered CLTUs are discarded. The only exception to this occurs when the association is terminated due to a protocol abort, and the protocol-abort-mode option has been set to 'continue'; in this case, production of CLTUs continues, and buffered CLTUs are not discarded. When an association is terminated, no further operations can be exchanged between the user and the provider. The systems may re- establish an association via a new CLTU-BIND operation, if that is consistent with the schedule for provision of service. Status information is not preserved after an association terminates and is not available to the new association with the following exceptions: a) statistics reported by means of the CLTU-STATUS-REPORT operation, such as the number of CLTUs processed (see 3.9), shall be accumulated for the entire service instance provision period; b) parameters that serve to relate notifications on an activity to operations that triggered this activity will not be altered when the association is released or aborted. 2.6.4.5 Buffering The Forward CLTU service buffers the CLTUs for the primary purpose of maintaining radiation of a steady stream of CLTUs despite variable latency over the ground communications channel. All transfers of CLTUs from the service user to the service provider must occur within the scheduled service instance provision period. 2.6.4.6 Technology-specific Aspects--Interoperability and the Underlying Communications Service This Recommendation defines the Forward CLTU service. Provision of the Forward CLTU service in a real system also requires a specification of how the service is mapped to a communications service, such that all invocations and returns of the Forward CLTU service operations can be exchanged between the user and the provider. In order not to restrict the applicability of this Recommendation to a specific communications technology, as few assumptions as possible have been made about the characteristics of the underlying communications service (see 1.3.1). The service interface between the user and the provider is specified in this Recommendation in terms of the operations that the service provides. Those operations are realized by mapping the service operation invocations and returns to protocol data units that can be conveyed by means of the underlying communications service. This Recommendation conceptualizes such mapping in two parts: a) Forward CLTU service operation invocations and returns (defined in section 3) are mapped to SLE-PDUs (defined in annex A); b) SLE-PDUs are mapped to protocol data units that can be conveyed by means of the underlying communications service. The mapping of Forward CLTU service operation invocations and returns to SLE-PDUs is specified by this Recommendation. The mapping of SLE-PDUs to an underlying communications service is intentionally outside the scope of this Recommendation (e.g., so that the Forward CLTU service may be mapped to more than one communications technology). In order to achieve interoperability, the user and provider must conform not only to this Recommendation but also to an agreed upon specification of the mapping of the Forward CLTU service to the underlying communications service. The specification of a mapping of the Forward CLTU service onto a particular communications service must address such points as: a) selection of communications network(s) to ensure connectivity; b) compatible configuration of protocol stacks (e.g., timeout values); c) specification of port-identifiers, and their translation onto the communications technology; d) specification of security related information. Figure 2-5 illustrates a communications realization of the Forward CLTU service that results from such a mapping. The specification of such mappings is the subject of separate CCSDS Recommendations. [IMAGE] Figure 2-5: Communications Realization of Forward CLTU Service Because the operations of the Forward CLTU service are relatively simple, once an association is in place between the service user and the service provider, the technology specific elements involved in the exchange of SLE-PDUs are generally minor. However, the way an association is established (i.e., the binding) tends to vary significantly depending on the communications technology in use. Nonetheless, the CLTU-BIND and CLTU-UNBIND operations as specified in this document are intended to be 'technology neutral'. This neutrality is achieved as described in the following paragraphs. For purposes of the communications mapping, the endpoints of an SLE association are identified by port identifiers, namely, an 'initiator port identifier' and a 'responder port identifier'. The port identifiers represent all the technology-specific addressing information needed to establish communications between the user and provider and to route SLE-PDUs between them. The initiator port identifier identifies the endpoint that will invoke the CLTU-BIND operation (initiator). The responder port identifier identifies the endpoint that will perform the CLTU- BIND operation (responder). Generally speaking, the information represented by a port identifier consists of: a) information needed to route data between two real systems over a communications channel or network; and b) information needed to route data within a real system to a particular application entity. For example, the information represented by a port identifier might be the combination of an Internet Protocol (IP) network address and a Transmission Control Protocol (TCP) port number or the combination of an OSI network address and an associated set of service access points (SAPs). The exact relationship between SLE port identifiers and communications ports provided by the underlying communications service must be specified by the mapping of the Forward CLTU service to the underlying communications service. In order for an SLE association to be established, SLE Complex Management and SLE Utilization Management must agree beforehand on the responder port identifier for the association. The responder needs the information represented by the responder port identifier to ensure that resources are allocated to recognize and respond to a CLTU-BIND invocation for that association. The initiator needs the information to ensure that the CLTU-BIND invocation will be communicated to the appropriate responder. In general, it is not necessary for SLE Complex Management and SLE Utilization Management to agree beforehand on the initiator port identifier for the association. Rather, the initiator should communicate that information to the responder in conjunction with the CLTU-BIND invocation. The exact means by which the initiator port identifier is provided to the responder is technology-specific and must be specified by the mapping of the Forward CLTU service to the underlying communications service. The responder port identifier is included as a parameter of the CLTU-BIND operation. Generally speaking, that is unnecessary; it is only necessary that SLE applications communicate the information represented by the port identifiers to the underlying communications service. The responder port identifier is provided as a parameter of the CLTU-BIND operation to allow for the possibility that the implementation of a gateway might be simplified by the inclusion of this parameter in the CLTU-BIND operation. The information represented by the responder port identifier is technology-specific. In order to define the CLTU-BIND operation in a way that is not technology-specific, the responder-port- identifier parameter of the CLTU-BIND operation is defined to be a logical name. A logical name is an arbitrary identifier that has an appropriately chosen and agreed upon translation to technology-specific information. Prior to the start time of a service instance, SLE Complex Management and SLE Utilization must mutually agree upon the value of the responder port identifier (and its translation) applicable to that service instance. The actual process of translating logical names to technology- specific information is considered a local matter. The translation methodology may rely on simple techniques such as look-up tables or may use more elaborate mechanisms such as naming or directory services. The above discussion describes the case that both the user and provider applications are implemented using the same communications service. It is possible to achieve interoperability even if the user and provider use different communications services. However, in that case interoperability requires the use of an appropriate gateway. 2.7 OPERATIONAL SCENARIO Prior to the actual provision of service, start and stop times for both the space link session and the associated Forward CLTU service instance are negotiated between SLE Complex Management and SLE Utilization Management. Configuration and other information needed to enable the service are also agreed. Some time before the scheduled start time of the Forward CLTU service instance, the service instance is created by SLE Complex Management. Initially, the service provider is in state 1 ('unbound'). At the scheduled start time of the space link session, the SLE Complexes involved establish the forward link to the spacecraft and initiate the production of Forward CLTU service and, if applicable, of the underlying FTCF and Forward CLTU services. Typically (but not necessarily) the start time of the service instance will precede by a small margin the start time of the space link session to allow the user to bind to the service before the start of the space link session. The following illustrates a typical sequence of operations between the user and the provider of the Forward CLTU service. A complete definition of the operations is found in section 3; the formal specification of provider behavior is presented in section 4. a) The user invokes the CLTU-BIND operation to establish an association. b) The provider, when configured to monitor uplink status by examining the No RF Available and/or No Bit Lock flags returned from the spacecraft in the Command Link Control Word (CLCW), performs the necessary operations to receive the Operational Control Field (OCF) as provided by the Return Frame Processing SLE-FG. c) The provider monitors equipment readiness, the status of the physical channel and (when configured to do so) the uplink status. When production status changes to 'operational' the provider sends CLTU-ASYNC-NOTIFY to the user. NOTE - Modulation of the uplink signal with acquisition sequence and idle sequence, in accordance with the PLOP in effect, is under the control of service management. d) The user sends CLTU-START, and the provider transitions to state 3, 'active'. e) The user sends a CLTU-TRANSFER-DATA operation to the provider. The provider verifies the invocation, and if acceptable, buffers the CLTU until the specified earliest- radiation-time is reached. f) Additional CLTUs may be sent by the user and buffered. NOTE - The user may perform steps, d), e) and f), invoking CLTU-START and CLTU-TRANSFER-DATA, before the production status becomes operational as described in step c). g) At the time specified for start of radiation, if production status is operational, the first CLTU is injected into the physical channel and modulated onto the RF carrier. The signal is radiated to the spacecraft. If no start time was specified in the CLTU-TRANSFER-DATA operation, the CLTU is radiated as soon as received, or whenever the production status becomes operational, if that is later. h) Successive CLTUs are processed in similar fashion after the delay period (if any) specified in the preceding CLTU is satisfied. i) The user transfers the last CLTU to the provider. j) The provider completes processing the buffered CLTUs. When the provider's CLTU buffer is empty, it sends CLTU-ASYNC-NOTIFY to inform the user. k) The user sends CLTU-STOP and the provider transitions to state 2, 'ready'. l) The user performs CLTU-UNBIND to release the association. 3 OPERATIONS AND THEIR PARAMETERS 3.1 GENERAL CONSIDERATIONS NOTES 1 This subsection specifies the processing of valid (i.e., recognized) SLE-PDUs. It defines common aspects of the operations of the Forward CLTU service. 2 Handling of invalid SLE-PDUs is specified in 0. 3.1.1 RESULT OF OPERATIONS 3.1.1.1 All confirmed operations shall report on the outcome of the operation in a return. 3.1.1.2 With the exception of CLTU-UNBIND, all returns shall include a result parameter that indicates whether the outcome of the operation was successful ('positive result') or unsuccessful ('negative result'). 3.1.1.3 In the event of a 'negative result', the return shall also include a diagnostic parameter that is descriptive of the reason for the 'negative result'. NOTE - Possible values of the diagnostic parameter are listed in the description of each operation. 3.1.1.4 A diagnostic of 'other reason' shall be returned only if no other value in the list adequately describes the reason for the 'negative result'. 3.1.2 PARAMETER TYPES The types of all parameters shall conform to the abstract syntax specified in annex A. NOTE - Some parameter types in annex A are chosen so that possible future extensions of the range of allowed values of a parameter will not cause a type mismatch. For example, parameters that logically are of the 'enumerated' type are specified as being of the 'named integer' type. 3.1.3 PARAMETER CHECKING 3.1.3.1 Validity checks shall be performed on the values of parameters associated with an operation. NOTE - Rules governing the validity of parameter values are included in the specification of individual operations. General reasons for regarding a parameter value as invalid are specified in the following paragraphs. 3.1.3.2 A parameter shall be treated as invalid if: a) its value is outside the range or not in the set of values currently permitted by service management for the given parameter; NOTE - A conformant implementation shall be capable of supporting the full range or set as specified in annex A. b) its value is in conflict with the value of another parameter in the same invocation (e.g., if in CLTU-TRANSFER-DATA the time specified in the earliest-radiation-time parameter is later than the time specified in the latest-radiation-time parameter); c) its value is in conflict with the current provider configuration (e.g., the minimum delay time between CLTUs parameter as set by service management is longer than the delay- time value the CLTU-TRANSFER-DATA invocation contains). 3.1.3.3 If a parameter value is not valid, the operation shall not be performed, and, for confirmed operations other than CLTU- UNBIND, a report of 'negative result' shall be returned to the invoker. 3.1.3.4 Except as noted in 3.2.2.11, checks for invalid parameters or for other conditions that can cause a report of 'negative result' should be performed in the order in which diagnostics are listed in the descriptions of the operations, and the diagnostic parameter should be set to the value defined for the first problem found. 3.1.3.5 In the case that an implementation does not adhere to the sequence of checks as specified by the sequence of diagnostic values, such implementation shall specify the sequence in which checks are actually performed. 3.1.4 ACCESS CONTROL 3.1.4.1 The Forward CLTU service shall implement access control based on the identity of the initiator and responder. Access control is performed at two levels: a) the initiator must be registered at the responder and the responder must be registered at the initiator; b) the initiator and responder must be authorized for the given service instance. 3.1.4.2 The initiator shall have access to a registry of authorized responders and the responder shall have access to a registry of authorized initiators. These registries shall be maintained by SLE Complex Management and SLE Utilization Management, respectively. 3.1.4.3 Service management shall specify the authorized initiator and responder for each service instance. 3.1.4.4 The initiator and responder shall indicate their identity by setting the parameters initiator-identifier and responder-identifier in the CLTU-BIND operation to the values assigned by service management. 3.1.5 AUTHENTICATION NOTE - Requirements for security depend on the application and on the SLE system environment (e.g., whether closed or public networks are used or if access is only from physically restricted areas). In many environments, security may be provided by the communications service transparently to the SLE application. This Recommendation does not preclude the use of security features that are provided by the communications service or the local environment, nor does it assume the availability of such features. 3.1.5.1 The Forward CLTU service shall provide the following options with respect to level of authentication: a) 'all'--all Forward CLTU invocations and returns, except the invocation of CLTU-PEER-ABORT, shall be authenticated; b) 'bind'--only the CLTU-BIND invocation and return shall be authenticated; c) 'none'--no Forward CLTU invocations or returns shall be authenticated. 3.1.5.2 SLE Complex Management and SLE Utilization Management shall agree on the level of authentication to be required for an association between a user and the Forward CLTU service provider and configure both entities accordingly. 3.1.5.3 SLE Complex Management and SLE Utilization Management shall agree on the algorithms used to generate and check credentials parameters and make these algorithms known to the service user and provider, together with associated parameters such as passwords or keys as necessary for the adopted algorithms. NOTES 1 The specification of the algorithms themselves is outside the scope of this Recommendation. 2 The initiator-identifier and responder-identifier parameters of the CLTU-BIND operation identify the user and provider, respectively, and therefore the applicable authentication level and the algorithms necessary to generate and check credentials. 3.1.5.4 For operations for which authentication of credentials is required by terms of the agreement between SLE Complex Management and SLE Utilization Management: a) invocations shall include an invoker-credentials parameter to permit the performer to authenticate the invocation; and b) returns shall include a performer-credentials parameter to permit the invoker to authenticate the return. 3.1.5.5 For operations for which authentication of credentials is not required, the invoker-credentials or performer-credentials parameter should be set to the value 'unused' to signify that the invocation or return does not carry credentials. 3.1.6 THREADED APPLICATIONS NOTES 1 Multi-threading has evolved to a widely used technique to optimize systems' performance. To support applications that may be implemented using multiple threads of execution, the parameter invoke-ID is specified for all confirmed operations except CLTU- BIND and CLTU-UNBIND. 2 The invoke-ID parameter allows the invoker to correlate a particular return to the invocation that prompted it. 3 Confirmed operations that include the invoke-ID parameter are non-blocking operations; those that do not are blocking operations. Unconfirmed operations are always non-blocking. 3.1.6.1 After invoking a blocking operation, the invoker shall not invoke another operation for the same service instance until the return from the blocking operation is received; except that, if the return is not received in a timely manner, the invoker may invoke CLTU-PEER-ABORT to terminate the association. 3.1.6.2 After invoking a non-blocking operation, the invoker may invoke another operation without waiting for the return from the first invocation. 3.1.6.3 The value of the invoke-ID parameter shall be an invoker-supplied arbitrary integer value that shall be returned, unchanged, by the performer. 3.1.6.4 The invocation of a non-blocking operation shall be rejected with the diagnostic 'duplicate invoke-ID' if it includes an invoke-ID whose value is the same as that of another invocation that is awaiting confirmation within the context of the same service instance. 3.1.6.5 To ensure that the Forward CLTU service behaves in a predictable manner, the effects of operations shall be as though the operations were performed in the order that their invocations were received by the performer. 3.1.6.6 The invoker may choose not to exploit the non-blocking capability and always wait for the return from a non-blocking operation before invoking another operation. NOTE - An invoker wishing to operate in blocking mode (i.e., to invoke a new operation only after the return from the previous operation has been received) may use a constant value for the invoke-ID parameter. As long as a return is still outstanding, the performer will reject any further invocations. 3.1.6.7 Compliance with this Recommendation does not require the performer to process invocations concurrently; however, the performer must accept invocations from a non-blocking invoker and buffer and serialize them by local means not visible externally. 3.1.7 MANDATORY PARAMETERS All providers shall be able to accept and respond to parameters specified as mandatory in annex D. NOTE - All parameters of operations are mandatory except where stated differently in annex D. The actual presence of a parameter in a particular invocation or return may be conditional based on the value of another parameter in the same invocation or return. For some parameters, a value of 'null' is allowed, as discussed in the description of the relevant operations. 3.1.8 TIME 3.1.8.1 The time reference for all parameters containing a time value shall be based on Coordinated Universal Time (UTC). 3.1.8.2 The type of parameters containing a time value shall be the CCSDS Day Segmented (CDS) time code format (reference [5]) with a resolution of microseconds, an epoch of 1958-01-01 and a 16-bit day segment. 3.1.8.3 All time values shall be expressed to a precision of at least one-tenth (0.1) of a second. 3.1.8.4 All time value shall be accurate to within one-tenth (0.1) of a second or better. 3.1.9 DELIVERY MODES 3.1.9.1 Forward Online Delivery 3.1.9.1.1 Forward online delivery service provision shall occur at the same time as service production, i.e., during a space link session. 3.1.9.1.2 CLTUs supplied by the service user shall be buffered by the service provider until they are processed. 3.1.9.1.3 The timing of CLTU processing shall be determined by the order of CLTUs in the buffer and any annotation data provided with the CLTUs. NOTE - The forward online delivery mode is defined in this Recommendation. 3.1.9.2 Forward Offline Delivery 3.1.9.2.1 Service provision and service production shall not overlap. 3.1.9.2.2 CLTUs supplied by the service user during service provision shall be buffered by the provider in persistent storage until service production. NOTE - The forward offline delivery mode is outside the scope of this version of this Recommendation. 3.1.10 SETTING OF PARAMETERS 3.1.10.1 A Forward CLTU provider shall permit setting of the service configuration parameters as specified in table 3-1. 3.1.10.2 The range or set of values a parameter may assume is constrained by specification of its data type (see annex A). 3.1.10.3 Service management may further constrain the allowed values for a given service instance. 3.1.11 PROVIDER BUFFERING REQUIREMENTS 3.1.11.1 The service package shall specify the amount of buffering the provider must maintain. 3.1.11.2 The amount of buffer space shall be specified in terms of the number of octets that can be stored. 3.1.11.3 The service provider shall buffer only complete CLTUs. 3.1.12 ACCOUNTING SUMMARY Statistical information to be collected over a period of time shall always refer to the service instance provision period. Table 3-1: Setting of Forward CLTU Service Configuration Parameters Parameter Service CLTU- CLTU- CLTU- Managemen START SCHEDULE- THROW- t Operatio STATUS- EVENT n REPORT Operatio Operatio n (NOTE n 3) bit-lock-required X delivery-mode X expected-cltu- X identification expected-event- X invocation- identification maximum-cltu- X length modulation- X frequency modulation-index X notification-mode X plop-in-effect X protocol-abort- X mode reporting-cycle X return-timeout- X period rf-available- X required subcarrier-to-bit- X rate-ratio NOTES 1 Further details on protocol-abort-mode are discussed in 4.1.5. The notification-mode parameter is described in 3.7.2.3. Other parameters are presented and described in table 3-11. A complete list of parameters that may affect service production may be found in references [E5] and [E6]. 2 The user can ascertain the current value of the parameters presented in table 3-11 by means of the CLTU-GET-PARAMETER operation. 3 The ability to modify selected service configuration parameters using the CLTU-THROW-EVENT operation is allowed but not mandated in this Recommendation. 3.2 CLTU-BIND 3.2.1 PURPOSE 3.2.1.1 The initiator shall invoke the CLTU-BIND operation to establish an association between the initiator and responder as defined in 1.6.1.7.2. 3.2.1.2 The responder shall confirm the CLTU-BIND operation. 3.2.1.3 Except as provided in 3.2.1.4, the initiator shall not invoke any further CLTU operations on this service instance until the bind is confirmed. 3.2.1.4 If the return from the invocation of CLTU-BIND is not received after a sufficiently long time (to be determined by service management), the initiator may attempt to recover by invoking the CLTU-PEER-ABORT operation (see 3.12) followed by another CLTU-BIND. 3.2.1.5 The CLTU-BIND operation is valid only in state 1 ('unbound') and shall be invoked only by the user. 3.2.2 INVOCATION, RETURN, AND PARAMETERS 3.2.2.1 General The parameters of the CLTU-BIND operation shall be present in the invocation and return as specified in table 3-2. Table 3-2: CLTU-BIND Parameters Parameter Invocati Return on invoker-credentials M performer-credentials M initiator-identifier M responder-identifier M responder-port-identifier M service-type M version-number M C service-instance-identifier M result M diagnostic C 3.2.2.2 invoker-credentials The invoker-credentials parameter shall provide information that enables the performer to authenticate the CLTU-BIND invocation (see 3.1.5). 3.2.2.3 performer-credentials The performer-credentials parameter shall provide information that enables the invoker to authenticate the return from the performance of CLTU-BIND (see 3.1.5). 3.2.2.4 initiator-identifier The initiator-identifier parameter shall identify the authority on whose behalf the SLE application is initiating an association. NOTES 1 The initiator-identifier parameter permits the responding SLE application to determine if this user is registered at this responder and which authentication scheme is to be applied. 2 In case authentication based on credentials is used, this information may be redundant since the initiator-identifier value is normally one constituent of the invoker-credentials parameter. However, its encoding may differ and it may be convenient to have this parameter also available in 'clear text' form. 3.2.2.5 responder-identifier The responder-identifier parameter shall identify the authority on whose behalf the responding SLE application is acting. NOTES 1 The responder-identifier parameter permits the initiator to determine if the responder from which the CLTU-BIND return originates is registered at this initiator. 2 The initiator uses this parameter, if applicable, after having successfully authenticated the CLTU-BIND return to determine if this return originates from the intended responder. 3.2.2.6 responder-port-identifier The responder-port-identifier parameter shall specify the port identifier of the responding SLE application entity with which the initiator seeks to establish an association. NOTES 1 The value of the responder-port-identifier parameter is a logical name that can be translated into the technology-specific addressing information required to establish a connection with the responder using the agreed upon communications service. See 2.6.4.6 for more information. 2 SLE Complex Management and SLE Utilization Management must have previously agreed on the responder-port-identifier and its translation that is applicable to a particular instance of service. 3 The responder-port-identifier parameter is included in the CLTU-BIND invocation to support its possible use by particular kinds of gateways. 3.2.2.7 service-type The service-type parameter shall specify the type of service that will be present if the bind operation succeeds.2 3.2.2.8 version-number 3.2.2.8.1 The version-number parameter shall identify the version number of the Forward CLTU service specification that is to govern this association if the CLTU-BIND succeeds. 3.2.2.8.2 version-number is conditionally present in the return based on the result parameter: a) if the value of result is 'positive result', version-number shall be present in the return; b) if the value of result is 'negative result', version-number shall not be present. 3.2.2.8.3 If the value of result is 'positive result', the responder shall either: a) accept the version proposed by the initiator by putting the same version number into the positive return; or b) if the responder implementation supports version negotiation, propose a lower (earlier) version number by putting the lower version number in the positive return. 3.2.2.8.4 If the responder implementation does not support the requested version and does not support a lower version (or does not support version negotiation), the responder shall reject the bind with the diagnostic parameter set to 'version not supported'. 3.2.2.8.5 If the responder proposes a lower version in the return than supported by the initiator, the initiator shall unbind the association. 3.2.2.8.6 The version-number value of the Forward CLTU service defined by this issue of this Recommendation shall be '1'. NOTE - The version negotiation process as outlined above is only feasible as long as a future version of the Forward CLTU service retains the specification of the CLTU-BIND operation. 3.2.2.9 service-instance-identifier The service-instance-identifier parameter shall uniquely identify this service instance within the scope of the service-providing SLE Complex. NOTE - The service-instance-identifier parameter takes the form of a Distinguished Name (see reference [8]). The attributes of the Distinguished Name should include the SLE service agreement and the SLE service package applicable to this instance of service. More details on the way the service-instance-identifier is built can be found in reference [E5]. 3.2.2.10 result 3.2.2.10.1 The result parameter shall specify the result of the CLTU-BIND invocation and shall contain one of the following values: a) 'positive result'--the CLTU-BIND invocation is accepted by the responder and the association is established; b) 'negative result'--the CLTU-BIND invocation is rejected by the responder for the reason specified in the diagnostic parameter. 3.2.2.11 diagnostic 3.2.2.11.1 If result is 'negative result', diagnostic shall be present and shall contain one of the following values: a) 'access denied'--an initiator with the initiator-identifier value presented in the CLTU-BIND invocation is not registered at the responder; b) 'service type not supported'--the service-type value in the CLTU-BIND invocation does not identify a service type supported by the responder; c) 'version not supported'-- 1) the responder does not support the requested version, and 2) the responder implementation does not permit version negotiation or the responder does not support any version of the service lower than the one requested by the initiator; d) 'no such service instance'--the requested service instance is not defined by any agreed upon service package known to the responder; e) 'already bound'--the service instance is already bound via a different association; f) 'service instance not accessible to this initiator'--the service instance identified by the value of the service-instance- identifier parameter has not been created for use by the initiator specified in the initiator-identifier parameter; g) 'inconsistent service type'--the service-type value in the CLTU-BIND invocation is not consistent with the service type of this service instance; i.e., it is not 'fwdCltu; h) 'invalid time'--the CLTU-BIND operation was invoked outside the service instance provision period agreed to in the service package; i) 'out of service'--the responder has been taken out of service for an indefinite period by management action, i.e., production-status is 'halted'; j) 'other reason'--the reason for the negative result will have to be found by other means. NOTE - Initiators should consider that, under some conditions, CLTU-BIND might fail with no return, e.g., if responder-port-identifier has an incorrect value. 3.2.2.11.2 If result is 'positive result', diagnostic shall not be present. 3.2.3 EFFECTS 3.2.3.1 If result is 'positive result': a) an association between the user and the provider shall be established; b) the provider shall transition from state 1 ('unbound') to state 2 ('ready'); c) upon receipt of the positive return, the user may proceed to invoke other Forward CLTU service operations to initialize the service and enable data transfer (e.g., CLTU-SCHEDULE-STATUS- REPORT and CLTU-START). 3.2.3.2 If result is 'negative result': a) the association between the user and the provider shall not be established; b) the provider shall remain in state 1 ('unbound'); c) upon receipt of the negative return: 1) the initiator should examine the diagnostic parameter for the cause; 2) the initiator may attempt to re-invoke the CLTU-BIND. 3.3 CLTU-UNBIND 3.3.1 PURPOSE 3.3.1.1 The initiator shall invoke the CLTU-UNBIND to release an association previously established by CLTU-BIND (see 0). 3.3.1.2 The responder shall confirm the CLTU-UNBIND operation. 3.3.1.3 Except as provided in 3.3.1.4, the initiator shall not invoke any further Forward CLTU operations for this service instance until the return from CLTU-UNBIND is received; nor shall it perform any further operations invoked by the responder; nor shall it return to the responder any further reports of the outcome of operations invoked by the responder. NOTE - The initiator may invoke the CLTU-UNBIND operation even if it did not yet receive all returns from previously invoked operations. The initiator should be aware that the responder may choose not to send any further returns as soon as it has received the CLTU- UNBIND invocation. It may then happen that the CLTU- UNBIND return is not received before one of the missing returns causes a 'missing return' timeout (see 4.1.3). 3.3.1.4 If the return from the CLTU-UNBIND invocation is not received after a sufficiently long time (to be determined by service management), the initiator shall invoke the CLTU-PEER- ABORT operation (see 3.12). NOTE - The 'sufficiently long time' as determined by service management can be estimated by invoking the CLTU- GET-PARAMETER operation and selecting 'return-timeout- period' as the value of cltu-parameter. 3.3.1.5 The CLTU-UNBIND operation is valid only in state 2 ('ready') and shall be invoked only by the user. 3.3.2 INVOCATION, RETURN, AND PARAMETERS 3.3.2.1 General The parameters of the CLTU-UNBIND operation shall be present in the invocation and return as specified in table 3-3. Table 3-3: CLTU-UNBIND Parameters Parameter Invoca Return tion invoker-credentials M performer-credentials M unbind-reason M result M 3.3.2.2 invoker-credentials The invoker-credentials parameter shall provide information that enables the performer to authenticate the CLTU-UNBIND invocation (see 3.1.5). 3.3.2.3 performer-credentials The performer-credentials parameter shall provide information that enables the invoker to authenticate the return from the performance of CLTU-UNBIND (see 3.1.5). 3.3.2.4 unbind-reason The unbind-reason parameter shall specify why the CLTU-UNBIND operation is being invoked and shall contain one of the following values: a) 'end'--the initiator has completed the transfer of its data and is releasing the association normally: the provider may end the service instance and release its resources allocated to this service instance; NOTE - Further invocation of the CLTU-BIND operation is not permitted even if the service instance provision period has not expired, since the service provider may release the resources allocated to that service instance. b) 'suspend'--the initiator is suspending this service usage for an unspecified period of time: the initiator may attempt to re-bind to the responder to continue data transfer at any time prior to the end of the provision period scheduled for this service instance; c) 'version not supported'--the initiator does not support the version of the Forward CLTU service proposed by the responder in the return from CLTU-BIND: this value of unbind-reason shall be used only if the CLTU-UNBIND is the first operation invoked following the CLTU-BIND; d) 'other reason'--the reason for the release will have to be found by other means. 3.3.2.5 result The result parameter shall specify the result of the CLTU-UNBIND invocation and shall always contain the following value: 'positive result'--the CLTU-UNBIND invocation is accepted by the responder and the association is released. NOTE - The result parameter is returned for the CLTU-UNBIND operation even though the only permitted value is 'positive result', for consistency with other confirmed operations. 3.3.3 EFFECTS 3.3.3.1 The CLTU-UNBIND operation shall have the following effects: a) the association between the initiator and the responder shall be released, and the initiator and the responder shall cease to communicate with each other; b) the provider shall transition to state 1 ('unbound'). 3.3.3.2 If unbind-reason is 'end', the provider may terminate the service instance and release its resources. 3.3.3.3 If unbind-reason is not 'end': a) the initiator may attempt to re-bind at any time prior to the end of the provision period scheduled for this service instance; b) the provider shall maintain accumulated statistics such as are reported in CLTU-STATUS-REPORT for the duration of the service instance provision period; c) parameters that serve to relate notifications on an activity to operations that triggered that activity shall not be altered when the association is released. 3.4 CLTU-START 3.4.1 PURPOSE 3.4.1.1 The user shall invoke the CLTU-START operation to request that the Forward CLTU service provider prepare to receive CLTU-TRANSFER-DATA invocations (see 3.6). 3.4.1.2 The Forward CLTU service provider shall confirm the CLTU-START operation. 3.4.1.3 The CLTU-START operation shall allow the Forward CLTU service provider to return to the user the times scheduled for start and stop of production. 3.4.1.4 CLTU-START is valid only in state 2 ('ready') and shall be invoked only by the user. 3.4.2 INVOCATION, RETURN AND PARAMETERS 3.4.2.1 General The parameters of the CLTU-START operation shall be present in the invocation and return as specified in table 3-4. Table 3-4: CLTU-START Parameters _______________________________ 1 The concept of an abstract service is to be distinguished from the concept of an (N)-service as defined in the OSI Basic Reference Model (reference [7]). The definition of (N)-service is in terms of the capability provided by one layer in the OSI architecture to the layer above it. The definition of abstract service is in terms of the capability provided by one abstract object to another abstract object. In a cross support scenario, where one Agency is providing an SLE service to another Agency, the object that provides the service typically is associated with one Agency, and the object that uses the service typically is associated with the other Agency. 2For the CLTU-BIND operation, the service-type parameter is redundant, because the only valid value of service-type is 'fwdCltu'. However, it is anticipated that future work by CCSDS will result in CLTU-BIND being superseded by a generic SLE-BIND operation that is invoked with any one of several SLE service types. The CLTU-BIND service-type parameter is provided in an attempt to facilitate such a change.