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.


<pre>
                               CONSULTATIVE
                               COMMITTEE FOR
                            SPACE DATA SYSTEMS



                         RECOMMENDATION FOR SPACE
                           DATA SYSTEM STANDARDS


                    +----------------------------------+
                    |                                  |
                    |    ADVANCED ORBITING SYSTEMS,    |
                    |     NETWORKS AND DATA LINKS:     |
                    |                                  |
                    |   ARCHITECTURAL SPECIFICATION    |
                    |                                  |
                    +----------------------------------+



                              CCSDS 701.0-B-2

                                 BLUE BOOK


                               November 1992




                                 AUTHORITY



                *******************************************
                *   Issue:     Blue Book, Issue 2         *
                *   Date:      November  1992             *
                *   Location:  Annapolis, Maryland, USA   *
                *******************************************





This Recommendation reflects the consensus technical agreement of the
following member Agencies of the Consultative Committee for Space Data
Systems (CCSDS):

o    British National Space Centre (BNSC)/United Kingdom.
o    Canadian Space Agency (CSA)/Canada.
o    Central Research Institute of Machine Building (TsNIIMash)/ Russian
     Federation.
o    Centre National D'Etudes Spatiales (CNES)/France.
o    Deutsche Forschungsanstalt fuer Luft- und Raumfahrt e.V.(DLR)/Germany.
o    European Space Agency (ESA)/Europe.
o    Instituto de Pesquisas Espaciais (INPE)/Brazil.
o    National Aeronautics and Space Administration (NASA)/USA.
o    National Space Development Agency of Japan (NASDA)/Japan.


The following observer Agencies also concur with this Recommendation:

o    Chinese Academy of Space Technology (CAST)/People's Republic of China.
o    Central Research Institute of Physics (CRIP)/Hungary.
o    Department of Communications, Communications Research Centre (DOC-
     CRC)/Canada.
o    Institute of Space and Astronautical Science (ISAS)/Japan.


This Recommendation is published and maintained by:

   CCSDS Secretariat
   Program Integration Division (Code-OI)
   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
cancelled.

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, which is a technical Recommendation prepared by the
Consultative Committee for Space Data Systems (CCSDS), is intended for use
by participating space Agencies in their development of "Advanced Orbiting
Systems".

The CCSDS has previously developed a set of layered Telemetry and
Telecommand Recommendations which meet the common requirements of
conventional missions, as characterized by the bidirectional (but
asymmetric) transfer of data between moderately complex space and ground
systems, serving a moderate number of users, at low-to-medium data rates.

This document extends the previous set of CCSDS Recommendations for
conventional missions, to accommodate extra services needed by Advanced
Orbiting Systems.  Target Advanced Orbiting Systems include manned and man-
tended space stations, unmanned space platforms, free-flying spacecraft,
and new space transportation systems, many of which require a richer
repertoire of data handling services than are provided by the conventional
Recommendations.

This Recommendation allows the implementing organizations within each
Agency to proceed coherently with the development of compatible Standards
for the flight and ground elements associated with Advanced Orbiting
Systems that are within their cognizance. Agency Standards derived from
this Recommendation may implement only a subset of the optional features
allowed herein, or may incorporate features not addressed by the
Recommendation.

Through the process of normal evolution, it is expected that expansion,
deletion, or modification of this document may occur. This Recommendation
is therefore subject to CCSDS document management and change control
procedures which are defined in Reference [1].





                             DOCUMENT CONTROL

     Document/Title           Date        Status and Substantive Changes

CCSDS 701.0-B-1,          October 1989  Original Issue
Recommendation for
Space Data Systems
Standards: Advanced
Orbiting Systems,
Networks and Data
Links: Architectural     November 1992  1.Supersedes Issue-1
Specification, Issue 1                  2.No substantive technical
                                           changes - primarily
CCSDS 701.0-B-2,                           incorporates numerous small
Recommendation for                         clarifications resulting from
Space Data Systems                         formal protocol validation and
Standards: Advanced                        early implementation
Orbiting Systems,                          experience:
Networks and Data                          a.refines Insert service
Links: Architectural                         addressing by introducing a
Specification, Issue 2                       "LinkID";
                                           b.adds the APID as a mandatory
                                             parameter for Path service;
                                             c.adds the PCID as a mandatory
                                             parameter for Multiplexing
                                             service;
                                           d.adds the VCDU Loss Flag as a
                                             mandatory parameter for the
                                             VCA service;
                                           e.describes operation of the
                                            Bitstream Data Loss Flag;
                                          f.corrects editorial errors in
                                              Figures 5-9 and 5-15;
                                          g.provides clearer discussion
                                              of the Bit Transition
                                                    Generator;
                                           h.defines SCID naming domain
                                                   conventions.
                                              3.Adds a more complete
                                            specification of the VCDU
                                              Header Error Control.
                                           4.Adds a new Annex on Packet
                                                   Timetagging.
                                             5.Deletes references to
                                            undeveloped documentation
                                              (SLAP, Management and
                                                   Signalling).

  NOTE: All text changes from the previous issue are flagged with change
        bars in the margin.  Deleted text is indicated by a single short
        dash ("-") in the margin.




                                 CONTENTS


Sections                                                  Page

      REFERENCES                                                      viii

1     INTRODUCTION                                                    1-1

      1.1   PURPOSE OF THIS DOCUMENT                                  1-1
      1.2   SCOPE OF THIS DOCUMENT                                    1-1
      1.3   APPLICABILITY OF THIS DOCUMENT                            1-2
      1.4   INTERFACES WITH CONVENTIONAL SYSTEMS                      1-2
      1.5   ORGANIZATION AND STATUS OF THIS DOCUMENT                  1-3
      1.6   BIT NUMBERING CONVENTION AND NOMENCLATURE                 1-4

2     SYSTEM OVERVIEW                                                 2-1

      2.1   SCOPE OF THE CCSDS PRINCIPAL NETWORK                      2-1
      2.2   CROSS SUPPORT                                             2-2
      2.3   OVERVIEW OF SERVICES WITHIN THE CCSDS
            PRINCIPAL NETWORK                                         2-3
      2.4   ARCHITECTURE OF THE SPACE LINK SUBNET                     2-11
      2.5   ARCHITECTURE OF THE CCSDS PATH SERVICE                    2-17
      2.6   ARCHITECTURE OF THE CCSDS INTERNET SERVICE                2-20
      2.7   MANAGEMENT OF THE CCSDS PRINCIPAL NETWORK                 2-21

3     PATH SERVICE AND PROTOCOL SPECIFICATION                         3-1

      3.1   INTRODUCTION                                              3-1
      3.2   SERVICE INTERFACE SPECIFICATION                           3-6
      3.3   PATH PROTOCOL SPECIFICATION                               3-11
      3.4   MANAGEMENT OF THE PATH SERVICE                            3-14

4     CCSDS INTERNET SERVICE AND PROTOCOL SPECIFICATION               4-1

      4.1   INTERNET SERVICE DEFINITION                               4-1
      4.2   INTERNET PROTOCOL SPECIFICATION                           4-1
      4.3   INTERNET PROTOCOL CONFORMANCE STATEMENT                   4-1

5     SPACE LINK SUBNETWORK SERVICE AND PROTOCOL
      SPECIFICATION                                                   5-1

      5.1   INTRODUCTION                                              5-1
      5.2   SPACE LINK SUBNETWORK PERFORMANCE REQUIREMENTS            5-10
      5.3   VIRTUAL CHANNEL LINK CONTROL SUBLAYER                     5-12
      5.4   VIRTUAL CHANNEL ACCESS SUBLAYER                           5-32
      5.5   MANAGEMENT OF THE SPACE LINK SUBNETWORK                   5-69

6     SPACE LINK ARQ PROCEDURE:  SERVICE DEFINITION                   6-1

      6.1   INTRODUCTION                                              6-1
      6.2   OPERATIONAL CONCEPT AND ORGANIZATION OF THE SLAP          6-1
      6.3   SLAP SERVICE INTERFACE SPECIFICATION                      6-4
      6.4   REQUIREMENTS FOR THE SLAP PROTOCOL                        6-9

7     CROSS SUPPORT OPTIONS                                           7-1

      7.1   CROSS SUPPORT CONCEPTS                                    7-1
      7.2   CPN SERVICE OPTIONS                                       7-2
      7.3   CROSS SUPPORT PROTOCOL OPTIONS MATRIX                     7-14


ANNEX A     ADDENDUM ON CCSDS PACKET TIMETAGGING                      A-1

ANNEX B     ACRONYMS AND TERMINOLOGY                                  B-1

INDEX                                                                 I-1


Figures                                                             Page

2-1   CCSDS Principal Network Elements                                2-1
2-2   CCSDS Principal Network Service Model                           2-5
2-3   Simplified CCSDS Principal Network Service Model                2-6
2-4   Space Link Subnet Data Flow                                     2-13
2-5   CCSDS Path Service Architecture                                 2-18
3-1   Path Service Architecture                                       3-1
3-2   Path Layer Organization                                         3-3
3-3   Example of a Logical Data Path                                  3-4
3-4   CP_PDU (CCSDS Packet) Structure                                 3-12
5-1   Space Link Sublayering Relationships                            5-1
5-2   Space Link Subnet Architecture                                  5-2
5-3   Internal Organization of the VCLC Sublayer                      5-13
5-4   Encapsulation Protocol Data Unit                                5-26
5-5   Multiplexing Protocol Data Unit, M_PDU                          5-28
5-6   Bitstream Protocol Data Unit, B_PDU                             5-31
5-7   Internal Organization of the VCA Sublayer                       5-33
5-8   Internal VCA Interfaces with the Slap                           5-41
5-9   VCA Internal Functional Organization                            5-44
5-10  VCDU/CVCDU Structural Components                                5-52
5-11  Virtual Channel Data Unit Format                                5-53
5-12  VCDU Fields over Which Parity Is Generated                      5-60
5-13  Slap Protocol Data Unit                                         5-61
5-14  Physical Channel Access Protocol Data Unit                      5-61
5-15  Relationship Between the VCDU, CVCDU, CADU and PCA_PDU          5-62
6-1   Symmetric Slap Operation                                        6-2
6-2   Organization of the Slap Sending/Acceptance Functions           6-5
7-1   Cross Support Configurations                                    7-2
7-2   Generic CPN Service Options Profile                             7-4
7-3   Path Service Options Profile                                    7-5
7-4   Internet Service Options Profile                                7-6
7-5   Encapsulation Service Options Profile                           7-7
7-6   Multiplexing Service Options Profile                            7-9
7-7   Bitstream Service Options Profile                               7-10
7-8   Virtual Channel Access Service Options Profile                  7-11
7-9   Virtual Channel Data Unit Service Options Profile               7-12
7-10  Insert Service Options Profile                                  7-13
A-1   Secondary Header Format                                         A-3

Tables                                                              Page

5-1   Allowed Concurrent VCLC Service Combinations                    5-4
5-2   Error Protection Requirements of SLS Grades of Service          5-6
5-3   Allowable Types and Grades of Service                           5-7
5-4   Packet Channel/Application Process Identifier Allocations       5-9
5-5   VCLC_SAP Address Parameters                                     5-9
5-6   Minimum Required Performance of SLS Grades of Service           5-12
7-1   Cross Support Options Matrix                                    7-15




                                REFERENCES


[1]    "Procedures Manual for the Consultative Committee for Space Data
       Systems", CCSDS A00.0-Y-5, Yellow Book, Issue 5 (Washington, D.C.:
       CCSDS, May 1992 or later issue).

[2]    "Packet Telemetry", Recommendation for Space Data Systems
       Standards, CCSDS 102.0-B-3, Blue Book, Issue 3 (Washington, D.C.:
       CCSDS, November 1992 or later issue).

[3]    "Telemetry Channel Coding", Recommendation for Space Data Systems
       Standards, CCSDS 101.0-B-3, Blue Book, Issue 3 (Washington, D.C.:
       CCSDS, May 1992 or later issue).

[4]    "Telecommand Part 3--Data Management Service", Recommendation for
       Space Data Systems Standards, CCSDS 203.0-B-1, Blue Book, Issue 1
       (Washington, D.C.: CCSDS, January 1987 or later issue).

[5]    "Telecommand Part 2--Data Routing Service", Recommendation for
       Space Data Systems Standards, CCSDS 202.0-B-2, Blue Book, Issue 2
       (Washington, D.C.: CCSDS, November 1992 or later issue).

[6]    "Telecommand Part 1--Channel Service", Recommendation for Space
       Data Systems Standards, CCSDS 201.0-B-1, Blue Book, Issue 1
       (Washington, D.C.: CCSDS, January 1987 or later issue).

[7]    "Audio, Video and Still-Image Communications Services",
       Recommendation for Space Data Systems Standards, CCSDS 704.0-R-2,
       Red Book, Issue 2 (Washington, D.C.: CCSDS, May 1993 or later
       issue).

[8]    "Advanced Orbiting Systems, Networks and Data Links: Summary of
       Concept, Rationale and Performance", Report Concerning Space Data
       Systems Standards, CCSDS 700.0-G-3, Green Book, Issue 3
       (Washington, D.C.: CCSDS, November 1992 or later issue).

[9]    "Advanced Orbiting Systems, Networks and Data Links:  Formal
       Definition of CPN Protocols, Methodology and Approach", Report
       Concerning Space Data Systems Standards, CCSDS 705.0-G-2, Green
       Book, Issue 2 (Washington, D.C.: CCSDS, May 1993 or later issue).

[10]   "Advanced Orbiting Systems, Networks and Data Links:  Abstract Data
       Type Library", Recommendation for Space Data Systems Standards,
       CCSDS 705.1-R-2, Red Book, Issue 2 (Washington, D.C.: CCSDS, May
       1993 or later issue).

[11]   "Advanced Orbiting Systems, Networks and Data Links:  Formal
       Specification of the Path Service and Protocol", Recommendation for
       Space Data Systems Standards, CCSDS 705.2-R-2, Red Book, Issue 2
       (Washington, D.C.: CCSDS, May 1993 or later issue).

[12]   "Advanced Orbiting Systems, Networks and Data Links:  Formal
       Specification of the VCLC Service and Protocol", Recommendation for
       Space Data Systems Standards, CCSDS 705.3-R-2, Red Book, Issue 2
       (Washington, D.C.: CCSDS, May 1993 or later issue).

[13]   "Advanced Orbiting Systems, Networks and Data Links:  Formal
       Specification of the VCA Service and Protocol", Recommendation for
       Space Data Systems Standards, CCSDS 705.4-R-2, Red Book, Issue 2
       (Washington, D.C.: CCSDS, May 1993 or later issue).

[14]   "Radio Frequency and Modulation Systems; Part 1: Earth Stations and
       Spacecraft", Recommendation for Space Data Systems Standards, CCSDS
       401.0-B, Blue Book (Washington, D.C.: CCSDS, September 1989 or
       later issue).  Note: Since this Reference does not currently cover
       data relay satellites, the following document shall be substituted
       for Reference [14]: STDN 101.2, "Space Network (SN) Users' Guide"
       [formerly titled "Tracking and Data Relay Satellite System (TDRSS)
       Users' Guide"], Revision 6, (Greenbelt, Maryland: NASA Goddard
       Space Flight Center, September 1988 or later issue).

[15]   "Information Processing Systems--Open Systems Interconnection--
       Basic Reference Model", ISO 7498 (Geneva: ISO, 1984).

[16]   "Information Processing Systems--Data Communications--Protocol for
       Providing the Connectionless-Mode Network Service", ISO 8473
       (Geneva: ISO, 1988).

[17]   "Information Technology--Telecommunications and Information
       Exchange Between Systems--Network Service Definition for Open
       Systems Interconnection", ISO 8348 (Geneva: ISO, 1992).

[18]   "Information Processing Systems--Data Communications--Network
       Service Definition--Addendum 1: Connectionless Mode Transmission",
       ISO 8348 ADI (Geneva: ISO, 1987).

[19]   "Information Processing Systems--Data Communications--Protocol for
       Providing the Connectionless-Mode Network Service--Addendum 3:
       Provision of the Underlying Service Assumed by ISO 8473 over
       Subnetworks which Provide the OSI Data Link Service", ISO 8473 AD3
       (Geneva: ISO, 1989).

[20]   "Time Code Formats", Recommendation for Space Data Systems
       Standards, CCSDS 301.0-B-2, Blue Book, Issue 2 (Washington, D.C.:
       CCSDS, April 1990 or later issue).




1  INTRODUCTION

1.a   This document is a Recommendation of the Consultative Committee for
      Space Data Systems (CCSDS).  The CCSDS is an international
      standardization body which is chartered with developing standard
      solutions to data handling problems that are common to many types of
      space missions;  its operating principles and procedures are defined
      in Reference [1].


1.1  PURPOSE OF THIS DOCUMENT

1.1.a The purpose of this document is to establish a CCSDS Recommendation
      for the architecture of the space/ground and space/space data
      handling systems which are embedded within a category of complex,
      networked space missions called "Advanced Orbiting Systems".

1.1.b This document specifies an architectural framework within which the
      Agencies participating in the CCSDS may implement compatible space
      mission data handling systems, so that opportunities for inter-
      Agency cross support and cooperation are maximized.  It defines the
      top-level characteristics of the systems architecture, but not
      necessarily all of the detailed specifications that would be
      required to implement a concrete system.  Where appropriate, the
      CCSDS may extend or supplement this document with more detailed
      specifications as the need is identified.

1.1.c This Recommendation primarily addresses those data handling
      operations which are unique to space missions.  It therefore focuses
      on data transmission through special-purpose space data links, and
      their associated interface networks.  Wherever possible and
      technically appropriate, interfaces with the commercial networking
      environment are provided so that the emerging infrastructure of
      commercial Open Systems Interconnection (OSI) may be exploited.


1.2  SCOPE OF THIS DOCUMENT

1.2.a Between 1982 and 1986, in response to the mission requirements of
      that era, CCSDS developed a series of technical Recommendations
      (References [2] through [6]) for the standardization of common data-
      system functions across a spectrum of "Conventional" missions.

1.2.b To meet the needs of the "Advanced Orbiting Systems" of the 1990s
      and beyond, CCSDS is extending its previous Recommendations to
      provide a more diverse and flexible set of data handling services.
      Advanced Orbiting Systems include manned and man-tended space
      stations, unmanned space platforms, free-flying spacecraft and new
      space transportation systems, many of which need services to
      concurrently transmit multiple digital data types (including audio
      and video) through space/ground and ground/space data channels.

1.2.c This Recommendation specifies the architecture, services and
      protocols to be used within a "CCSDS Principal Network" (CPN) that
      supports CCSDS Advanced Orbiting Systems.  The scope of the CPN is
      addressed in section 2.


1.3  APPLICABILITY OF THIS DOCUMENT

1.3.a This Recommendation serves as a guideline for the development of
      compatible internal Agency standards for advanced orbiting data
      systems.  Systems embraced by this Recommendation are foreseen to
      enter development during the 1990s and include:  manned and man-
      tended space stations;  unmanned space platforms;  free-flying
      spacecraft;  and new space transportation systems.

1.3.b This Recommendation is not retroactive, nor does it commit any
      Agency to implement the recommended concepts at any future time.
      Nevertheless, all CCSDS Agencies accept the principle that all
      future implementations of advanced orbiting data systems which are
      used in inter-Agency cross support situations will be based on this
      Recommendation.

1.3.c The recommendations in this document are to be invoked through the
      normal standards programs of each member Agency, and are applicable
      to those missions for which cross support based on capabilities
      described in this Recommendation is anticipated.  Where mandatory
      capabilities are clearly indicated in sections of the
      Recommendation, they must be implemented when this document is used
      as a basis for cross support.  Where options are allowed or implied,
      implementation of these options is subject to specific bilateral
      cross support agreements between the Agencies involved.

1.4  INTERFACES WITH CONVENTIONAL SYSTEMS

1.4.a This Recommendation draws heavily upon previous CCSDS
      Recommendations for the asymmetric flow of Telemetry and Telecommand
      data within Conventional space systems, as defined in References [2]
      through [6].  Where feasible, appropriate elements of the previous
      Recommendations are used directly.  In other cases, upward-
      compatible extensions of the previous Recommendations are defined to
      satisfy new requirements, such as the integration of digitized audio
      and video (Reference [7])  into space data streams.

1.4.b By virtue of this upward compatibility, it should be noted that this
      Recommendation does not preclude "mixed" mission configurations
      whereby Conventional space systems are operated in conjunction with
      Advanced Orbiting Systems.  For example:

1.4.c   the space-located elements of CCSDS Advanced Orbiting Systems may
        interface with independent free-flying spacecraft whose data-
        communications systems conform to Conventional CCSDS
        Recommendations.  These interfaces are technically supported via
        the various Service Access Points identified in Section 2, but may
        not be specifically addressed within this Recommendation;

1.4.d   some missions may wish to operate hybrid configurations;  e.g., a
        Conventional CCSDS Telecommand uplink as described in References
        [4], [5], and [6] may be paired with an Advanced Orbiting Systems
        downlink.  (Note that this configuration would not satisfy the
        integration of digitized audio and video into the uplink data
        stream.) Such hybrid configurations are technically supported by
        the data structures defined in Section 5 of this Recommendation,
        but they are the subject of detailed negotiations between Projects
        and CCSDS cross support organizations.  A discussion of hybrid
        Telecommand operations is contained in Reference [8].


1.5  ORGANIZATION AND STATUS OF THIS DOCUMENT

1.5.a This document, which is the main Recommendation for CCSDS Advanced
      Orbiting Systems, contains a definition of the CCSDS Principal
      Network and specifications of its associated services and protocols.
      It is supplemented by CCSDS Reports (References [8] and [9]), which
      are not part of the Recommendation, and by implementation-oriented
      service and protocol definitions (References [10] through [13]),
      which are written in a formal specification language.

1.5.b The main Recommendation contains this introduction (Section 1) plus
      six technical sections and two Annexes as follows:

1.5.c   Section 2 contains a description of the CCSDS Principal Network
        (CPN), including a broad definition of the services it provides.
        In case of conflict, the specifications contained in Sections 3
        through 7 shall take precedence over the descriptive material in
        Section 2.

1.5.d   Section 3 contains the controlling technical specification for a
        CCSDS "Path service", and its associated protocol, which supports
        one method for transferring user data through the CPN.  A formal
        definition of the Path protocol is contained in Reference [11].

1.5.e   Section 4 contains the controlling technical specification for a
        CCSDS "Internet Service", and its associated protocol, which
        supports another method for transferring user data through the
        CPN.

1.5.f   Section 5 contains the controlling technical specification for a
        CCSDS "Space Link Subnetwork", and its associated services and
        protocols, which supports a variety of methods for transferring
        data through space/space and space/ground channels.  A formal
        definition of the Space Link Subnet protocol is contained in
        References [12] and [13].

1.5.g   Section 6 contains an architectural overview of a space link
        retransmission protocol, which supports the reliable transfer of
        data through space channels.  (The CCSDS Secretariat should be
        consulted for information concerning the detailed service and
        protocol specifications for this "Space Link ARQ Procedure".)

1.5.h   Section 7 contains a summary of the requirements which a Project
        must satisfy in order to be compatible with this Recommendation
        for the purpose of obtaining cross support from other
        organizations.

1.5.i   Annex A contains a definition of the mechanisms to be used for
        CCSDS packet timetagging.

1.5.j   Annex B contains a list of the acronyms and terminology used
        throughout the main Recommendation.  First-time readers are
        strongly urged to become familiar with the contents of this Annex,
        which is augmented by the index.

1.5.k A supporting CCSDS Report, Reference [8], summarizes key operational
      concepts of the CCSDS Principal Network.  It provides general
      rationale and tutorial information, and presents supporting analysis
      of space data channel performance implications.  First-time readers
      are strongly urged to become familiar with the contents of this
      Report.


1.6  BIT NUMBERING CONVENTION AND NOMENCLATURE

1.6.a In this document, the following convention is used to identify each
      bit in an N-bit field.  The first bit in the field to be transmitted
      (i.e., the most left justified when drawing a figure) is defined to
      be "Bit 0";  the following bit is defined to be "Bit 1" and so on up
      to "Bit N-1".  When the field is used to express a binary value
      (such as a counter), the Most Significant Bit (MSB) shall be the
      first transmitted bit of the field, i.e., "Bit 0".

1.6.b In accordance with standard data-communications practice, data
      fields are often grouped into 8-bit "words" which conform to the
      above convention.  Throughout this Recommendation, such an 8-bit
      word is called an "octet".

1.6.c By CCSDS convention, all "spare" bits shall be permanently set to
      value "zero".


                                  [IMAGE]


2  SYSTEM OVERVIEW

2.1  SCOPE OF THE CCSDS PRINCIPAL NETWORK

2.1.a  This Recommendation defines a conceptual model for a CCSDS
       Principal Network (CPN). A CPN serves as, or is embedded within,
       the Project data handling networks which provide end-to-end data
       flow in support of space mission users. A CPN consists of an
       "Onboard Network" in an orbiting segment connected via a CCSDS
       "Space Link Subnetwork" either to a "Ground Network", or to an
       Onboard Network in another orbiting segment. The conceptual context
       of a CPN is shown in Figure 2-1 in both a space/ground and a
       space/space configuration.




                                  [IMAGE]


      Figure 2-1:  CCSDS Principal Network Elements


2.1.b  Recognizing the uniqueness of data transfer through special-purpose
       space data channels, this Recommendation specifies the full suite
       of services and protocols operating within the Space Link
       Subnetwork (SLS). It also specifies the end-to-end services and
       protocols required for the transfer of user data across the entire
       CPN. It does not make recommendations regarding the internal
       protocols operating within the Onboard and Ground Networks, nor
       does it define or make recommendations concerning extended services
       beyond the conceptual bounds of the CPN.

2.1.c  Within the SLS, this Recommendation assumes the use of space/ground
       data channels as defined in Reference [14]. Although it is possible
       that many space/space data channels may also be embraced by this
       Recommendation, its applicability to general space/space
       communications has not been determined.

2.1.d  Two end-to-end service options are offered to users for the
       packetized transfer of data across the CPN: "Path" service and
       "Internet" service. The CPN extends to the points at which the Path
       or Internet data-transfer protocols are terminated, and, as such,
       locations of the end points of the CPN are not explicitly defined
       by CCSDS. Note that this does not preclude the use of CCSDS data
       transfer protocols as extended end-to-end protocols outside the
       bounds of the CPN, in which case Project organizations may use them
       within "extended" Onboard or Ground Networks.

2.1.e  As far as the scope of the CCSDS Onboard or Ground Networks is
       concerned, they may consist of:

2.1.f   multiple interconnected subnetworks traversed by Internet and/or
        Path protocol data units;  or

2.1.g   a single subnetwork traversed by Internet and/or Path protocol
        data units;  or

2.1.h   a data link traversed by Internet and/or Path protocol data units;
        or

2.1.i   an internal communication within a data system using Internet
        and/or Path protocol data units.


2.2  CROSS SUPPORT

2.2.a  CCSDS seeks to provide a communication systems architecture that
       facilitates opportunities for inter-Agency "cross support", which
       is defined as the capability for one space Agency to
       bidirectionally transfer another Agency's data between ground and
       space systems, using its own transmission resources. Cross support
       takes place at the level of data structures that are created by one
       Agency and handed over to another Agency for transmission. This is
       achieved by exposing standard service interfaces to the (otherwise
       private) communications infrastructure which is provided by the
       cooperating Agencies. The addresses of such service interfaces on
       the CPN are called "Service Access Points" (SAPs).

2.2.b  The cross support concept for CCSDS Advanced Orbiting Systems is
       based upon the following precepts:

2.2.c     each Agency has its own private network implementation;

2.2.d     the cross support services that are provided must be independent
          of the physical implementation of an Agency's network;

2.2.e     the cross support services should be arranged so as to support
          the transfer of data structures created at different layers of
          the CPN protocol architecture;  i.e., flexible service interfaces
          should be offered;

2.2.f     incomplete data structures, or data structures containing
          detected but uncorrectable errors, are not required to be
          delivered in cross support situations (though in case of
          nondelivery, error reports may be provided using optional service
          parameters).

2.2.g  To realize this concept, CCSDS specifies the exposed service
       interfaces at which the various services can be obtained, the
       corresponding interface primitives to be implemented to access
       them, and their associated data structures.

2.2.h  The requirements which a Project organization must satisfy in order
       to be compatible with this Recommendation, and their cross support
       implications, are defined in Section 7.

2.2.i  The service interfaces defined in this Recommendation are abstract
       service interfaces: a specific implementation is not intended, and
       therefore such an implementation is the subject of local Agency or
       Project agreements.


2.3  OVERVIEW OF SERVICES WITHIN THE CCSDS PRINCIPAL NETWORK

2.3.a  A conceptual model of a typical space mission CPN data-flow
       configuration is shown in Figure 2-2. Here, examples of the various
       user services offered by the Onboard and Ground Networks, and the
       Space Link Subnetwork, are indicated. Note that data may flow in
       either direction (from space to ground, or from ground to space) in
       association with any of the services. Also note that, although
       Figure 2-2 does not depict the space-to-space configuration, the
       concept is identical.

2.3.b  The CPN model is layered, showing its general correspondence to the
       Open Systems Interconnection (OSI) model which is maintained by the
       International Organization for Standardization (ISO), Reference
       [15]. The CPN model, in addition to clearly indicating the nature
       and number of services provided by the CPN, also allows the systems
       implementers to better understand the complexities involved in
       providing the services.

2.3.c  Since the whole CPN is conceptually composed of two achitecturally
       symmetric halves, the services associated with the model may be
       made simpler to understand by concentrating on only one of the
       halves, as shown in Figure 2-3. It should be noted that in a
       physical implementation the two halves are not necessarily
       identical owing to operational factors which are discussed in more
       detail in Reference [8]; however, in this conceptual discussion the
       differences are put aside.

2.3.d  Eight separate services are provided within a CPN. Two of these
       services ("Internet" and "Path") operate in an asynchronous mode
       across the entire CPN. The remaining six services ("Encapsulation",
       "Multiplexing", "Bitstream", "Virtual Channel Access", "Insert",
       and "Virtual Channel Data Unit") are provided in either an
       asynchronous or isochronous mode by the Space Link Subnetwork.

2.3.1  CCSDS PRINCIPAL NETWORK END-TO-END DATA TRANSFER SERVICES

2.3.1.a   Two services, the Internet service and the Path service, operate
          end-to-end across a CPN. Project-defined "application services"
          may exist above these services to provide higher layer functions
          such as data-base access and file transfer, but CCSDS does not
          define their characteristics. For instance, while a Project-
          defined "stack" (OSI Layers 4-7) of protocols may exist above the
          CCSDS Internet service to support application services, these
          protocols are not specified by CCSDS: the shaded areas in Figure
          2-2 and 2-3 specifically indicate the services which ARE NOT
          discussed within this Recommendation.

2.3.1.b   Since both the Internet and Path services rely on underlying
          subnetworks which may not preserve sequence, end-to-end data
          transfer using these services is defined to be non-sequence
          preserving; the SLS, however, does preserve sequence.

2.3.1.1    INTERNET SERVICE

2.3.1.1.a   The Internet service routes variable-length network service
            data units end-to-end across the CPN, from a sending Network
            layer SAP to a receiving Network layer SAP. Each network
            service data unit contains a delimited string of octets
            representing higher-layer user data. The transfer is
            asynchronous, non-sequence preserving, and with lifetime
            control.

2.3.1.1.b   This service is expected to be used primarily for
            intermittently transferring, at relatively low data rates, low
            to moderate volumes of structured, delimited data from a
            single source end point to a single destination end point.
            Such uses may require access to upper-layer ISO protocol
            services, or may require communication through space links
            with applications that are accessible through ISO ground
            networks. This service could be used to support, for example,
            realtime interactive command and control operations, file
            transfer, and interactive operations such as electronic mail
            and remote terminal access.


                                  [IMAGE]


                                  [IMAGE]



2.3.1.1.c  The CCSDS Internet service conforms with the ISO 8473
           Connectionless Network Protocol Specification, Reference [16].
           To provide flexibility, the ISO 8473 packet features full
           addressing of the source and destination network SAPs, and the
           possibility of partial or full source routing, at the expense
           of a larger and more complex communications header than is
           provided within the Path service.

2.3.1.2    PATH SERVICE

2.3.1.2.a  The Path service transfers variable-length application-layer
           service data units end-to-end across the CPN, from an
           application-accessible source SAP to one or more application-
           accessible destination SAPs. Each service data unit contains a
           delimited string of octets of user application data. The Path
           service is asynchronous and non-sequence preserving.

2.3.1.2.b  The Path service is expected to be used primarily for
           transferring, at moderate to very-high data rates, large
           volumes of structured, delimited data units between fairly
           static source and destination associations. It is the service
           most likely to be used, for example, for the transfer of
           measurement data (i.e., telemetry) from payload instruments.

2.3.1.2.c  The transfer is designed to use a lean and efficient protocol,
           by exploiting the fact that in many space mission operations
           the association between the source and destination of user
           messages is known a priori. These pre-established associations,
           known as CCSDS "Logical Data Paths" (LDPs), are configured by
           management. Instead of providing full endpoint addressing, the
           protocol data unit of the Path service contains a "Path
           Identifier" which identifies the LDP.

2.3.1.2.d  The protocol data unit of the Path service is the Version-1
           CCSDS Packet.  The Path service offers two service options:

2.3.1.2.e  a "Packet" service transfers CCSDS Packets, preformatted by the
           user, intact across the CPN;

2.3.1.2.f  an "Octet String" service transfers delimited strings of user
           octets across the CPN, by building them into Version-1 CCSDS
           Packets on the user's behalf.

2.3.1.2.g  The Path service does not have an underlying segmentation
           function and does not include a protocol mechanism for end-to-
           end flow control.

2.3.2     SPACE LINK SUBNETWORK DATA TRANSFER SERVICES

2.3.2.a   The SLS, which forms the core of the CCSDS Principal Network,
          supports the bidirectional transmission of Path and Internet
          service data units through the space/ground and space/space
          channels that interconnect the distributed elements of the CCSDS
          Advanced Orbiting Systems. It also provides SLS data-transfer
          services which do not extend further through the CPN. Within the
          SLS, CCSDS defines the full protocol suite required to achieve
          cross support.

2.3.2.b   A key feature of the CCSDS protocol provided for the SLS is the
          concept of "Virtual Channels". The Virtual Channel facility
          allows one physical space channel to be shared among multiple
          higher-layer traffic streams, each of which may have different
          service requirements. A single physical space channel may
          therefore be divided into several separate logical data channels,
          each known as a "Virtual Channel" (VC). Each VC is individually
          identified and supports a single "Grade of Service".

2.3.2.c   To facilitate simple, reliable, and robust synchronization
          procedures, fixed-length protocol data units are used to transmit
          data through the weak-signal, noisy space channels: their length
          is established for a particular link during a particular mission
          phase by management, and they are delimited by placing
          Synchronization Markers between their boundaries. These protocol
          data units are each associated with one particular Virtual
          Channel, and are known as "Virtual Channel Data Units" or VCDUs.
          A service option internal to the VCDU can also produce a protocol
          data unit known as a "Coded Virtual Channel Data Unit", or CVCDU.
          Each VCDU and CVCDU contains a header and trailer which provide
          space link protocol control information, and a fixed-length data
          field within which higher-layer service data units are carried.

2.3.2.d   The SLS supports six different types of services: Encapsulation;
          Multiplexing; Bitstream; Virtual Channel Access; Virtual Channel
          Data Unit; and Insert.

2.3.2.1    ENCAPSULATION SERVICE

2.3.2.1.a  The Encapsulation service provides a facility whereby variable-
           length, octet-aligned service data units that are not formatted
           as CCSDS Packets may be transferred across the SLS. The
           transfer is asynchronous and sequence preserving.

2.3.2.1.b  The service is accomplished by locally encapsulating the
           "foreign" data structure within a CCSDS controlled data
           structure that is part of the suite of cross supported
           protocols defined for the SLS. The Encapsulation service is
           provided using the Version-1 CCSDS Packet as its protocol data
           unit.

2.3.2.2    MULTIPLEXING SERVICE

2.3.2.2.a  The Multiplexing service provides a facility whereby variable-
           length, delimited, octet-aligned service data units, which
           conform to the Version-1 CCSDS Packet format, may be
           multiplexed together for transfer across the SLS on the same
           Virtual Channel. The transfer is asynchronous and sequence
           preserving.

2.3.2.2.b  The Multiplexing service concatenates different CCSDS Packets
           together and formats them into blocks which are sized to
           exactly load the fixed-length data field of one Virtual Channel
           Data Unit. The Multiplexing service is provided using the
           Version-1 CCSDS Packet as its service data unit. The
           Multiplexing service can therefore accept both Encapsulation
           service and Path service data units, and concatenate them
           within one Virtual Channel.

2.3.2.3    BITSTREAM SERVICE

2.3.2.3.a  The Bitstream service provides a facility whereby serial
           strings of bits, whose internal structure and boundaries are
           unknown to the CPN, may be transferred across the SLS. The
           transfer is sequence preserving and may be either
           "asynchronous" or "isochronous". Isochronous transfer from
           service interface to service interface is provided with a
           specified maximum delay and a specified maximum jitter at the
           service interface. High-rate video data (Reference [7]) may use
           the isochronous Bitstream service.

2.3.2.3.b  The Bitstream service breaks the stream of bits from each SLS
           user into blocks which are sized to exactly load the fixed-
           length data field of one dedicated Virtual Channel Data Unit.
           Fill data may be transparently added and removed as necessary
           to match the bitstream to the fixed-length data field.
           Bitstreams from different SLS users may not be multiplexed
           together within one Virtual Channel by the Bitstream service.

2.3.2.4    VIRTUAL CHANNEL ACCESS SERVICE

2.3.2.4.a  The Virtual Channel Access service provides a facility whereby
           a Project organization may transfer private service data units
           (which are sized to exactly load the fixed-length data field of
           one dedicated Virtual Channel Data Unit and whose internal
           structure is unknown to the CPN) across the SLS. The transfer
           can be either asynchronous or isochronous, and is sequence
           preserving.

2.3.2.5    VIRTUAL CHANNEL DATA UNIT SERVICE

2.3.2.5.a  The Virtual Channel Data Unit service provides a facility
           whereby a fixed-length, octet-aligned VCDU or CVCDU, created by
           an independent SLS entity, may be transferred across the SLS.
           The transfer is sequence preserving and is performed either
           asynchronously or isochronously and in accordance with a
           prespecified priority.

2.3.2.5.b  Internal to the SLS, the Virtual Channel Data Unit service
           transfers the independently created VCDUs/CVCDUs through the
           space channel, together with VCDUs/CVCDUs created by the SLS
           itself. This service is made available to trusted users who are
           certified during the design process to ensure that the
           independently created protocol data units do not violate the
           operational integrity of the SLS. Necessarily, the independent
           VCDUs/CVCDUs must have the same length as those generated by
           the SLS.

2.3.2.6    INSERT SERVICE

2.3.2.6.a  The Insert service provides a facility whereby private, octet-
           aligned service data units may be transferred isochronously
           across the SLS in a mode which efficiently utilizes the space
           channel transmission resources at relatively low data rates
           (Reference [8]). When activated, the Insert service is
           implemented by establishing an "Insert Zone" in every Virtual
           Channel Data Unit that is transmitted on a particular Physical
           Channel, and by placing the Insert service data units into this
           Zone. The Insert Zone shares the fixed-length data field of the
           VCDUs and/or CVCDUs with other types of service.

2.3.2.6.b  As noted in Reference [8], when the aggregate transmitted data
           rate across the Physical Channel is less than 10Mb/s, the
           Insert Zone should be used for isochronous data transfer;
           however, at rates greater than 10Mb/s the isochronous data
           should be transmitted using the Bitstream service on a
           dedicated Virtual Channel. To avoid operational complexity,
           CCSDS recommends that the Insert service should not exist
           simultaneously with the Virtual Channel Data Unit service on
           one Physical Channel.

2.3.2.6.c  The Insert service is sequence preserving and is provided with
           a specified maximum delay and a specified maximum jitter at the
           service interface. Typical isochronous applications using the
           Insert service include moderate-rate processes such as audio
           (Reference [7]) and teleoperations control, operating in low-
           bandwidth environments where the overall transmitted data rate
           on the Physical Channel is constrained. The size of the Insert
           Zone and the sample rate of the Insert service data units must
           be carefully tuned in concert with the available data
           transmission resources. Note that it is unlikely that the
           aggregate Insert service data rate will exactly match the
           generated data rate of the user source; provision must
           therefore be made to compensate for any difference by the
           Insert service user.

2.3.2.6.d  When the Insert service is used, the Insert Zone must be
           present in all Virtual Channels that share the same Physical
           Channel, and its length is established by management.

2.3.3   SLS GRADES OF SERVICE

2.3.3.a   Three "Grades of Service" are offered within the Space Link
          Subnet.  A Project organization must implement at least one of
          these Grades of Service in order to be compatible with this
          Recommendation.

2.3.3.b   Grade-1 service: SLS service data units are delivered through the
          SLS complete, with their sequence preserved, and with a very high
          probability of containing no errors induced by the SLS.

2.3.3.c   Grade-2 service: SLS service data units are delivered through the
          SLS possibly incomplete, but with their sequence preserved and
          with a very high probability of containing no errors induced by
          the SLS.

2.3.3.d   Grade-3 service: SLS service data units are delivered through the
          SLS possibly incomplete and with a moderate probability that they
          contain errors induced by the SLS, but with their sequence
          preserved.

2.3.3.e   It should be noted that:

2.3.3.f   not all Grades of Service are offered for each SLS service;

2.3.3.g   the Grades of Service are only offered during periods when
          space/ground or space/space data channels are scheduled and
          available. Higher-layer CPN processes are required to
          reconstitute and deliver service data units which are buffered
          during periodic space channel outages;

2.3.3.h   the Grades of Service are ONLY defined by CCSDS across the Space
          Link Subnet;  it is necessarily a Project responsibility to
          extend them into end-to-end Grades of Service, if desired;

2.3.3.i   the Grades of Service are not explicitly signalled by protocol,
          but are set up by management;

2.3.3.j   service data units which contain detected SLS-induced errors are
          not required to be delivered in CCSDS cross support
          configurations.


2.4  ARCHITECTURE OF THE SPACE LINK SUBNET

2.4.a  The purpose of this section is to present a top level overview of
       the key functions and data structures which support the operation
       and services of the SLS. All of the operations which are described
       must be understood to be independent of the direction of data flow
       through the SLS. The controlling specification for the SLS service
       and protocol is contained in Section 5 of this Recommendation.

2.4.1   FUNCTIONS PERFORMED BY THE SLS

2.4.1.a   Figure 2-4 shows all possible data flows through the SLS: data
          flow from top to bottom of the figure on the sending side, and
          from bottom to top on the receiving side. The physical space
          medium (a space/ground or space/space data-transmission path)
          interconnects the sending and receiving sides of the SLS. The
          figure identifies the data-handling and formatting functions that
          are involved.  These functions are discussed in the following
          paragraphs.

2.4.1.1    PHYSICAL CHANNEL FUNCTION

2.4.1.1.a  The Physical Channel function creates one dedicated space data
           transmission path. A continuous stream of data bits is accepted
           at the sending side, modulated, serially transmitted through
           the physical space medium, demodulated, bit synchronized, and
           delivered through the receiving interface. The CCSDS
           Recommendation for the Physical Channel function is contained
           in Reference [14] and is not specified herein. While direct
           access to the Physical Channel is permissible, definition of
           such a service is not within the scope of this Recommendation.

2.4.1.2    VIRTUAL CHANNEL FUNCTION

2.4.1.2.a  At the sending side, the Virtual Channel function accepts
           service data units from higher-layer functions, builds them
           into the space link protocol data units (VCDUs or CVCDUs) that
           are required to identify and operate the Virtual Channels,
           applies the error control required by different Grades of
           Service, commutates the VCDUs/CVCDUs into an appropriate
           sequence, and submits them as a serial stream to the Physical
           Channel function for transmission through one Physical Channel.
           At the receiving side the serial stream is synchronized to find
           the boundaries between VCDUs/CVCDUs, which are then passed
           through error control procedures and decommutated. The higher-
           layer service data units are then extracted and passed back
           through the receiving service interface.

2.4.1.2.b  During transmission through the Physical Channel, each VCDU or
           CVCDU is carried synchronously within one "Channel Access Data
           Unit" (CADU). The CADUs provide fixed-length "channel access
           slots" which occur at precise time intervals that are
           synchronized with the transmitted bit rate, and whose
           boundaries are delimited using "Synchronization Markers". The
           commutated sequence of VCDUs/CVCDUs is transmitted so that all
           of the synchronous channel access slots are occupied. In
           situations where no valid higher-layer data are ready for
           release, a VCDU/CVCDU containing "Fill" data is commutated into
           the transmitted sequence. The continuous and contiguous stream
           of CADUs, known as a "Physical Channel Access Protocol Data
           Unit", is transferred through the Physical Channel.



                                  [IMAGE]

                 Figure 2-4:  Space Link Subnet Data Flow

2.4.1.2.c  Service data units associated with the Encapsulation,
           Multiplexing, Bitstream or Virtual Channel Access services are
           placed into a "Data Unit Zone" within the data field of the
           VCDU or CVCDU. At low transmitted data rates, the Insert Zone
           facility may be activated to allow isochronous data samples
           associated with the Insert service to share the VCDU/CVCDU data
           field with the other types of service data units.

2.4.1.2.d  The Grades of Service are supported as follows:

2.4.1.2.e  Grade-3 service is provided by constructing VCDUs for direct
           transmission through the underlying dedicated Physical Channel;

2.4.1.2.f  Grade-2 service is provided by adding an error-correcting code
           to the constructed VCDUs to form CVCDUs. The recommended code
           appends a block of error-correcting Reed-Solomon check symbols
           to the VCDU in order to provide virtually "error-free"
           transmission;

2.4.1.2.g  Grade-1 service is provided within CVCDUs on certain Virtual
           Channels by a "Space Link ARQ" function that supports the
           transfer of asynchronous Multiplexing, Bitstream or Virtual
           Channel Access service data units through the space link using
           a retransmission control ("ARQ") procedure to protect against
           momentary channel outages. The function is implemented by a
           "Space Link ARQ Procedure" (SLAP). Grade-1 service is defined
           only for full-duplex operation, i.e., two dedicated Virtual
           Channels, one in each direction, must be paired by management
           for Grade-1 service to be provided.

2.4.1.2.h  (Note: some Projects may be constrained to operate only with a
           unidirectional retransmission procedure; i.e., full-duplex
           operation may not be possible. Such Projects have the option of
           implementing a hybrid configuration with a Conventional CCSDS
           "Command Operation Procedure" providing retransmission control
           for the uplink, as described in References [4], [5] and [6].
           While technically supported, hybrid configurations are the
           subject of detailed Project implementations; such
           configurations are discussed in Reference [8].)

2.4.1.2.i  If Grades-1/2 operate in conjunction with Grade-3 on the same
           Physical Channel, the stream of protocol data units observed at
           the receiving side of the Physical Channel may therefore
           contain VCDUs and CVCDUs which are serially interleaved in a
           nondeterministic order.

2.4.1.2.j  The demultiplexing and delivery of VCDUs and CVCDUs is achieved
           by using a Spacecraft Identifier concatenated with a Virtual
           Channel Identifier, both of which are contained in the VCDU
           header. Error-control mechanisms are provided to protect these
           key header routing fields.

2.4.1.2.k  Independently created VCDUs/CVCDUs associated with the Virtual
           Channel Data Unit service flow through the Virtual Channel
           function, potentially interfacing only with the error-control
           mechanisms.

2.4.1.3    ASYNCHRONOUS DATA TRANSFER

2.4.1.3.a  The normal "asynchronous" mode of SLS data transfer associated
           with the Multiplexing, Encapsulation, Bitstream or Virtual
           Channel Access service is for incoming service data units to
           asynchronously fill up the Data Unit Zone of the VCDU or CVCDU
           before being released for transmission. The incoming service
           data units must be preformatted into fixed-length blocks in
           order to be placed within the Data Unit Zone.

2.4.1.4.   ISOCHRONOUS DATA TRANSFER

2.4.1.4.a  Some types of "isochronous" service data units require transfer
           through the SLS in a manner which preserves timing
           relationships that are important to users. This is achieved by
           defining a fixed time delay with specified jitter between
           transmissions.

2.4.1.4.b  High-rate isochronous data streams (e.g., video data) may be
           blocked using Bitstream procedures and an entire Virtual
           Channel may be dedicated for their isochronous transmission.

2.4.1.4.c  For low- or medium-rate user applications such as audio or
           teleoperations control data, situations may arise where the
           maximum transmitted data rate of the CADUs is constrained by
           channel bandwidth considerations. In this case, since the
           combination of maximum allowable time delay and CADU length
           lead to an inefficient utilization of the space channel if
           dedicated Virtual Channels are used, it may be necessary to
           share the VC with other data. The Insert Zone facility is
           provided within the VCDU/CVCDU data structures to carry the
           isochronous data samples;  it is present in every transmitted
           CADU and hence provides a fixed, synchronous time slot for the
           isochronous data.

2.4.1.5    MULTIPLEXING FUNCTION

2.4.1.5.a  To efficiently utilize the space channel, variable-length
           service data units must be packed together so that they fully
           occupy the fixed-length Data Unit Zone of the CVCDU. This is
           accomplished by a multiplexing, delimiting and blocking
           function. The Version-1 CCSDS Packet provides the only cross
           supported data structure that is recognized for use within this
           function.

2.4.1.5.b  Individual CCSDS Packets from multiple sources are concatenated
           together into a contiguous string of Packets, which is then
           broken into blocks whose length is arranged such that they may
           be loaded exactly into the fixed-length CVCDU Data Unit Zone.
           Several individual "Packet Channels" may thus concurrently
           share one VC using the Multiplexing functions. Each Packet
           Channel is locally identified using the "Application Process
           ID" (APID) field contained in the CCSDS Packet header.

2.4.1.5.c  The demultiplexing and delivery of CCSDS Packets on individual
           Packet Channels is achieved by examining the APID and "Packet
           Length" fields in the Packet header: since these fields are not
           protected against errors, the demultiplexing and delivery
           functions can only be reliably accomplished if the headers are
           known to be correct. Consequently, cross support can only be
           provided if the multiplexed data are placed within Reed-Solomon-
           protected CVCDUs.

2.4.1.5.d  In the event that a CVCDU has to be released before its Data
           Unit Zone is full, an "idle" CCSDS Packet, containing Fill
           data, is inserted.

2.4.1.6    BITSTREAM FUNCTION

2.4.1.6.a  The Bitstream function breaks each incoming stream of bits into
           blocks whose lengths are arranged so that they may be exactly
           loaded into the fixed-length Data Unit Zone of a VCDU on a
           dedicated VC. Reassembly of the contiguous stream of bits at
           the receiving service interface is performed. If fill data are
           inserted during the transfer, they are removed prior to
           delivery. The Bitstream data may be transferred either
           asynchronously or isochronously.

2.4.1.7    ENCAPSULATION FUNCTION

2.4.1.7.a  Since the asynchronous Multiplexing function only recognizes
           the Version-1 CCSDS Packet data structure, an Encapsulation
           function is provided which wraps "other" delimited data units
           into Version-1 CCSDS Packets.

2.4.1.7.b  The CCSDS Path service, by virtue of its use of Version-1 CCSDS
           Packets as its protocol data unit, is directly compatible with
           the Multiplexing function and therefore bypasses the
           Encapsulation function. However, the CCSDS Internet service
           uses the ISO 8473 packet format, and from an evolutionary
           viewpoint it is desirable to provide the flexibility to handle
           other delimited, octet-aligned data units should the future
           need arise to support different network layer services across
           the CPN. The Encapsulation function provides this flexibility.

2.4.1.7.c  The Encapsulation function takes any delimited service data
           unit which is presented to the SLS at a requesting service
           interface in non-CCSDS Packet format (e.g., the 8473 Internet
           packet) and encapsulates it within a special CCSDS "carrier"
           Packet during its transfer through the SLS. The carrier Packet
           may then be multiplexed onto an appropriate Packet Channel
           within one VC, along with Packet Channels containing other
           carrier Packets or Path service data units. At the receiving
           service interface of the SLS, the carrier Packet is stripped
           and the original delimited service data unit is reconstituted
           to continue its passage through the CPN.


2.5  ARCHITECTURE OF THE CCSDS PATH SERVICE

2.5.a  The CCSDS Path service, using the Version-1 CCSDS Packet, provides
       an optimized connectionless data transfer service between a single
       source user Application and one or more destination Applications.
       Since the Version-1 CCSDS Packet is a user data structure which is
       also standardized across CCSDS "Conventional" missions, the CCSDS
       "Advanced Orbiting Systems" Path service presents a compatible user
       interface across the entire spectrum of space applications.

2.5.b  This section contains a descriptive overview and definition of the
       Path service;  the full service and protocol specification is
       contained in Section 3. Reference [8] contains a more general
       discussion of Path service characteristics.

2.5.c  The architecture of the CCSDS Path service is illustrated in Figure
       2-5. The Path layer provides an enhanced performance service which
       exposes a Path SAP to the user Application at its upper side, and
       interfaces directly to the underlying local subnetwork on its lower
       side, thus bypassing all intermediate layers of protocol.

2.5.d  Although the service may operate in either direction through the
       CPN, one major requirement for the Path service is the need to
       transfer high rates and volumes of telemetry data from space to
       ground. The Path service architecture is shown to be symmetrical in
       Figures 2-2, 2-3, and 2-5;  however, at the ground end of a
       telemetry data transfer system, additional higher-layer processes
       may be provided to remove transmission artifacts induced by the SLS
       (such as filling data gaps when Path data are retrieved from
       onboard storage), and also to buffer the Path data for delivery on
       a user-convenient timescale.  These services are discussed in
       Reference [8].

                                  [IMAGE]

               Figure 2-5:  CCSDS Path Service Architecture


2.5.1     LOGICAL DATA PATHS

2.5.1.a   The Path service relies on the use of a managed association
          between two or more application end-points, i.e., a Logical Data
          Path (LDP). The LDP association is preconfigured by CPN
          management for subsequent use by the Path service. Each Logical
          Data Path is referenced by a "Path ID".

2.5.1.b   As the CCSDS Packets traverse the local subnetworks of the CPN,
          they are carried and routed by subnet-specific mechanisms (e.g.,
          local area networks). At relay points between different
          subnetwork routing mechanisms, the CCSDS Packet header itself may
          be used in a routing and relay role, in which case the LDP
          interpretation and mapping to the next subnetwork address is
          performed using tables that are configured through prior
          interaction between the relay points and management: in this case
          the "Application Process Identifier" (APID) field in the Version-
          1 CCSDS Packet header is used to provide the reference to the
          Path ID.


2.5.2     PATH ID MANAGEMENT

2.5.2.a   Reflecting the need to use a lean and compact protocol to achieve
          fast and efficient space communications, the APID field in the
          Version-1 CCSDS Packet is limited in length to eleven bits, thus
          giving the possibility to reference 2048 different LDPs. For
          complex international constellations of space vehicles, APIDs
          must be shared between space Agencies. To facilitate cross
          support, it is therefore necessary to identify a strategy for
          APID assignment which, while enabling the sharing of APIDs,
          avoids any APID ambiguity.

2.5.2.b   Within the onboard systems of a CPN, it is the responsibility of
          individual Projects to define a local assignment strategy for the
          available APIDs. Within the ground systems of a CPN (which must
          support Path service associated with multiple spacecraft) it is
          necessary to globally identify each LDP.  This may be
          accomplished by concatenating the APID in the CCSDS Packet with
          an "APID Qualifier" that is associated with the Packet throughout
          its ground transfer to and from user applications. A "Spacecraft
          Identifier" (SCID) may be used within the ground systems to
          provide this APID Qualifier.  The SCID is carried as an 8-bit
          field within the header of the space link protocol data unit,
          i.e., the VCDU/CVCDU. Each of the 256 SCIDs associated with the
          VCDU Version Number "01" may potentially provide an individual
          naming domain for 2048 APIDs.

2.5.2.c   The APID Qualifier may also be required in some space-to-space
          applications of the Path service.

2.5.3     PATH SERVICE INFORMATION FLOW

2.5.3.a   The flow of information from the user application to the local
          subnetwork interface, for a typical Path service transmission, is
          as follows:

2.5.3.b   the Path layer receives either a delimited string of user octets,
          together with the parameters necessary for the construction of
          the Path protocol data unit (CCSDS Packet), or  a complete user-
          formatted CCSDS Packet;

2.5.3.c   the Path layer either constructs a CCSDS Packet or validates a
          user-formatted Packet;

2.5.3.d   the Path layer cooperates with locally supplied communication
          mechanisms to deliver the CCSDS Packet to its intended
          destination.


2.6  ARCHITECTURE OF THE CCSDS INTERNET SERVICE

2.6.a  The CCSDS Internet service supports interactive operations (of the
       type represented by activities such as file transfer, electronic
       mail, and remote terminal access) between end systems located on
       the Onboard and Ground Networks of the CPN. The Internet service is
       associated with the Network layer of the ISO Reference Model of
       Open Systems Interconnection, Reference [15], and operates in
       connectionless mode.

2.6.b  This section contains a descriptive overview and definition of the
       Internet service;  the full service and protocol specification is
       contained in Section 4, which references the appropriate ISO
       documentation. Reference [8] contains a more general discussion of
       Internet service characteristics.

2.6.c  The CPN comprises a series of interconnected, dissimilar
       subnetworks through which data are conveyed. Each subnetwork may
       have different ways of addressing the destination, different
       protocol data unit sizes, different time delays and bandwidths, and
       different status and monitoring capabilities. The CCSDS Internet
       service resolves these subnetwork differences by providing global
       inline protocol mechanisms, which are contained in the Internet
       protocol data unit and mapped down to the subnet layer as the
       Internet data unit is transported through the CPN.

2.6.d  Since standard techniques already exist to solve problems of global
       internetworking, CCSDS has adopted existing international standards
       for both the Internet service definition and the protocol
       specification, i.e., the ISO connectionless mode network service
       (ISO 8348/AD1) and the associated protocol (ISO 8473) as defined in
       References [16] through [19] .

2.6.e  The ISO 8473 Internet protocol data unit carries along in its
       packet header full endpoint addresses, security, priority, quality
       of service, and routing capabilities which minimize (but do not
       eliminate) network management responsibility. This generality comes
       at the expense of a large communications header.

2.6.f  The Internet service differs from the Path service in several
       respects:

2.6.g   the number and location of the application endpoints may change
        relatively rapidly;

2.6.h   the data rates and volumes associated with this type of traffic
        are relatively low, and the duty cycle of individual users is more
        intermittent, so that the communications efficiency and throughput
        penalties of comprehensive inline protocol are not so important;

2.6.i   the service may support a suite of higher-layer OSI-compatible
        services, for those users who need them;

2.6.j   the service provides a richer Internet addressing capability which
        conforms to ISO international address partitioning standards, with
        a proportionally longer and more complex header to carry the
        address;

2.6.k   the service provides for a set of additional options, such as
        segmenting and route reporting, which may be needed by specific
        Projects.


2.7  MANAGEMENT OF THE CCSDS PRINCIPAL NETWORK

2.7.a  Many of the CPN protocols defined in this Recommendation have been
       designed to enable fast processing and to conserve bandwidth during
       space data transfer; therefore, some parameters associated with
       their operation are handled by management rather than by inline
       protocol. Management of the CPN consists of the set of functions
       and services which are provided to supervise, schedule and control
       the CPN resources.  To perform their coordinating functions,
       management systems exchange information using signalling
       mechanisms.

2.7.b  Insofar as these management functions are not associated with cross
       support, their implementation is a local matter which is not
       embraced by this CCSDS Recommendation.  The management and
       signalling aspects of cross support configurations are the subject
       of separate CCSDS Recommendations; the CCSDS Secretariat should be
       consulted for information relative to their status.


3  PATH SERVICE AND PROTOCOL SPECIFICATION

3.1  INTRODUCTION

3.1.a  The CCSDS Path service provides efficient, high throughput,
       unidirectional data transfer between a single source User
       Application and one or more destination User Applications. The
       organization of the Path service is reviewed in Figure 3-1.



                                  [IMAGE]


                  Figure 3-1:  Path Service Architecture


3.1.b  A CCSDS "Path Entity" provides Path service to a User Application.
       The Path layer protocol transfers variable-length CCSDS Path
       Service Data Units (CP_SDUs) from end to end across the CPN, from a
       source Path Entity to one or more destination Path Entities. The
       Path layer interfaces with management services that configure and
       control the Path service, and draws upon local subnetwork services
       for the transfer of the CCSDS Path Protocol Data Units (CP_PDUs).
       The CP_PDU is the Version-1 CCSDS Packet.

3.1.c  The route through the subnets of the CPN, known as a Logical Data
       Path (LDP), is established by Path layer management and is constant
       for the lifetime of the association between User Applications. The
       LDP is identified by a Path ID. At any point in the LDP, the CP_PDU
       may be routed from subnetwork to subnetwork by examining its Path
       ID. Alternatively, at any point in the LDP, routing may be
       accomplished between cooperating subnetworks by use of an agreed
       mapping between subnetwork addresses. (Note, however, that at the
       exiting gateway of the Space Link Subnet the Path ID must be
       employed for routing, since there is no alternative mechanism
       available in the SLS protocol stack.)

3.1.d  The Path service is provided in two ways:

3.1.e     a "Packet service" option transfers "Packet Service Data Units"
          (P_SDUs), which are preformatted by the user as Version-1 CCSDS
          Packets, intact across the CPN. Thus the user-formatted P_SDU is
          used as the CP_PDU, and can be transferred without further
          formatting by the Path procedures; or

3.1.f     an "Octet String service" option transfers "Octet Service Data
          Units" (O_SDUs), which consist of delimited strings of user
          octets, across the CPN by formatting them into CP_PDUs. This
          service may reduce the complexity of data transfer for the users,
          since the CCSDS Packets are created by the service.

3.1.g  Note that the O_SDU and the P_SDU are both instances of CCSDS Path
       Service Data Units (CP_SDUs).

3.1.h  Each LDP terminating in a source end system of the CPN has an
       associated type of service, either Packet or Octet String. The
       service type need not be preserved from end to end of the LDP;
       i.e., asymmetric services may be provided.  For instance, an
       invocation of the Octet String service at the source end system may
       (at the user's request) result in an instance of the Packet service
       at the destination end system(s). Once selected, the type of
       service (symmetric or asymmetric) provided at the ends of an LDP
       shall be fixed for its lifetime.

3.1.i  The Path service does not provide inline protocol mechanisms for
       flow control or segmentation.

3.1.j  The end-to-end Quality of Service provided to Path service users
       will vary according to the individual qualities of service provided
       by the various subnetworks along the Logical Data Path.  The Path
       service does not provide any mechanisms for guaranteeing a
       particular quality of service; it is the responsibility of
       implementing organizations to ensure that the end-to-end
       performance of a particular instance of the Path service meets the
       requirements of its users.


3.1.1     ORGANIZATION OF THE PATH LAYER

3.1.1.a   The composition and service interfaces of the Path layer are
          shown in Figure 3-2.



                                  [IMAGE]


                   Figure 3-2:  Path Layer Organization


3.1.1.b   The parameters passed to the Octet String service by the Path
          service user (along with information supplied by Path layer
          management) are used by the "Packet Construction Procedures" to
          build the Primary Header of the CP_PDU (the CCSDS Packet).

3.1.1.c   A Version-1 CCSDS Packet passed to the Packet service by the Path
          service user is used as the CP_PDU, so it is unchanged by the
          Path procedures.


3.1.2     PATH LAYER ADDRESSING

3.1.2.a   The Path service relies on the use of a preconfigured route (the
          Logical Data Path) between a single source User Application and
          one or more destination User Applications. The LDPs are
          configured by Path layer management for subsequent use by the
          Path service. Every LDP is uniquely identified by a Path ID.

3.1.2.b   Each LDP consists of the source end system, the destination end
          system(s), and the intermediate subnetworks on the LDP. An LDP
          need not include intermediate subnetworks if the source and
          destination end systems are on the same subnetwork.

3.1.2.c   "Packet Transfer Procedures", used to forward the CP_PDU through
          the CPN, are performed by Path Entities located in either a
          source end system or an intermediate system.

3.1.2.d   Figure 3-3 shows an example of a single LDP crossing an
          intermediate subnetwork to a single destination User Application.


                                  [IMAGE]

                Figure 3-3: Example of a Logical Data Path


3.1.2.e   Note that multi-addressing may be performed at any of the
          intermediate system Path Entities or at the source end system
          Path Entity. Multi-addressing may be performed from a single
          source end system Path Entity to multiple destination end system
          Path Entities on the same subnetwork, or on several subnetworks.
          A "multidrop" architecture is permitted where the CP_SDU is
          delivered to a user in a data system and the CP_PDU is also
          forwarded to other data systems.

3.1.2.f   In simple mission configurations, the Path ID of the LDP may be
          fully represented by the "Application Process ID" (APID)
          contained in the header of the Version-1 CCSDS Packet;  up to
          2048 different APIDs may be supported.

3.1.2.g   Since complex Path service cross support configurations may exist
          and LDPs must be uniquely identified, an extension of the Path
          addressing mechanism (known as an APID Qualifier) may be required
          within some of the subnetworks traversed by the LDP. If needed,
          the APID Qualifier is locally associated with the APID in the
          CCSDS Packet but is not explicitly represented in the CP_PDU. In
          such configurations, the Path ID is represented by the APID plus
          the APID Qualifier.

3.1.2.h   The APID Qualifier uniquely identifies a naming domain which
          "owns" an APID address space, and hence the 2048 Path IDs. The
          naming domain may be one spacecraft or, if a complex orbiting
          constellation of spacecraft elements exists, each of the
          individual elements may be its own naming domain. In this
          Recommendation it is assumed that (at least as far as the flight
          systems are concerned) all of the available APIDs are locally
          assigned by a Project organization across the communicating set
          of spacecraft elements which are under the control of that
          Project.

3.1.2.i   However, within the ground system (which may have to concurrently
          support multiple spacecraft) the APID Qualifier may be needed to
          maintain global uniqueness of Path IDs. The 8-bit Spacecraft
          Identifier (SCID), contained within the headers of VCDU/CVCDUs
          and concatenated with the Version Number "01", provides the APID
          Qualifier within the SLS. The SCID may therefore be used at the
          ground gateways with the SLS to map into appropriate ground
          network addressing mechanisms, so that partitioning of APIDs from
          different naming domains is preserved. Within the ground networks
          local subnetwork addressing information (i.e., "SN_SAPs") may be
          used to represent the APID Qualifier.

3.1.2.j   Note that some complex orbiting spacecraft may have multiple
          SCIDs assigned to them while implementing a common onboard APID
          address space.  In this case all of the SCIDs are treated as a
          unified APID naming domain as far as the APID Qualifier is
          concerned.

3.1.2.k   If a constellation of cooperating but separate spacecraft (each
          implementing its own internal APID naming domain without sharing
          APID address space across the orbiting systems) transmit their
          data through a common Physical Channel, then each of the SCIDs
          provides a separate APID Qualifier.

3.1.2.l   The convention for the APID naming domains is as follows:

3.1.2.m     for space-to-ground communication the naming domain is the
            source naming domain (the spacecraft or spacecraft element);

3.1.2.n     for ground-to-space communication the naming domain is the
            destination naming domain (the spacecraft or spacecraft
            element);

3.1.2.o     for space-to-space communication the naming domain is the
            source naming domain (the source spacecraft or spacecraft
            element). In this case, the destination spacecraft may need to
            use the APID Qualifier in a manner similar to the ground
            system.


3.1.3     SUBNETWORK SERVICES ASSUMED BY THE PATH LAYER

3.1.3.a   It is intended that the Path layer be capable of operating over
          connectionless-mode services derived from a wide variety of real
          subnetworks and data links. Therefore, in order to simplify the
          specifications of the protocol, its operation is defined with
          respect to an abstract "underlying service" rather than any
          particular real subnetwork (SN) service. This underlying service
          consists of a single "SN_UNITDATA" primitive which conveys the
          source and destination subnetwork point of attachment addresses
          and a minimum number of octets of user data.

3.1.3.b   The service primitives required are:

          SN_UNITDATA.request      (SN_SDU,
                                     Source Address,
                                     Destination Address)

          SN_UNITDATA.indication   (SN_SDU,
                                     Source Address,
                                     Destination Address)

3.1.3.c   Real subnetworks and data links may not conform to the
          SN_UNITDATA service interface defined in 3.1.3.b.   Use of the
          Path service over such a subnetwork or data link requires that a
          convergence function be performed between the SN_UNITDATA
          primitives specified for the Path protocol and the service
          primitives specified for that subnetwork or data link.


3.1.4     SERVICES ASSUMED FROM THE LOCAL ENVIRONMENT

3.1.4.a   The services assumed by the Path layer from the local environment
          are unspecified.


3.2  SERVICE INTERFACE SPECIFICATION

3.2.a  All of the service interface specifications in this Recommendation
       generally follow conventions used by ISO. Accordingly, the
       specifications are given in the form of primitives, which present
       an abstract model of the logical exchange of information between
       the Path layer and the user of the Path service. The primitives are
       specified to be independent of any particular implementation
       approach.

3.2.1     OVERVIEW OF INTERACTIONS

3.2.1.1   PACKET SERVICE

3.2.1.1.a   The service primitives associated with the Packet service are:

            PACKET.request
            PACKET.indication

3.2.1.1.b   The PACKET.request primitive is passed to the CCSDS Path layer
            to request that a P_SDU be sent.

3.2.1.1.c   The PACKET.indication primitive is passed from the CCSDS Path
            layer to indicate the arrival of a P_SDU.

3.2.1.2     OCTET STRING SERVICE

3.2.1.2.a   The service primitives associated with the Octet String
            service are:

            OCTET_STRING.request
            OCTET_STRING.indication

3.2.1.2.b   The OCTET_STRING.request primitive is passed to the CCSDS Path
            layer to request that an O_SDU be sent.

3.2.1.2.c   The OCTET_STRING.indication primitive is passed from the CCSDS
            Path layer to indicate the arrival of an O_SDU.

3.2.2       SERVICE PRIMITIVE PARAMETERS

3.2.2.a     The parameters for the Path service primitives are:

3.2.2.b O_SDU       The Octet Service Data Unit. The O_SDU is a delimited,
                    octet-oriented data unit whose content and format are
                    unknown to the Path layer. The maximum length of the
                    O_SDU is defined by individual Project organizations,
                    taking into account the maximum SDU size in all subnets
                    traversed by the LDP.

3.2.2.c APID        The APID is a mandatory parameter and is used in
                    conjunction with the APID qualifier (if present) to
                    uniquely identify the Logical Data Path to be used in
                    conjunction with the PACKET.request and
                    PACKET.indication primitives.

3.2.2.d P_SDU       The Packet Service Data Unit. The P_SDU is a Version-1
                    CCSDS Packet that has been created by the service user.
                    The maximum length of the P_SDU is defined by
                    individual Project organizations, taking into account
                    the maximum SDU size in all subnets traversed by the
                    LDP.

3.2.2.e APID        The APID Qualifier is an optional parameter which is
        Qualifier   associated with  the APID in the CCSDS Packet in order
                    to maintain global uniqueness  of APIDs. In this
                    Recommendation, it is assumed that the APID  Qualifier
                    is only used within the ground network, and that the
                    Spacecraft ID (SCID), concatenated with the Version
                    Number "01", may be used to provide this parameter.

3.2.2.f Secondary   The Secondary Header is a feature of the CCSDS Packet
        Header      which allows  additional types of information that may
        Indicator   be useful to the User  Application (e.g., a time code)
                    to be included. The CP_PDU Primary  Header contains a
                    "Secondary Header Flag" which indicates the  presence
                    or absence of a Secondary Header. Within the Packet
                    service,  a user of the service in a source end system
                    may signal the presence or  absence of a Secondary
                    Header by passing the Secondary Header  Indicator
                    parameter in the form of the Secondary Header Flag.
                    Within  the Octet String service, the Secondary Header
                    Indicator parameter  signals the presence of a
                    Secondary Header at the start of the O_SDU.

3.2.2.g Path ID     The Path ID, which uniquely identifies the LDP,
                    consists of the APID plus the optional APID Qualifier.

3.2.2.h Data        The Data Loss Indicator is used to alert the user of
                    the
        Loss        Octet String service in a destination end system that
        Indicator   one or more O_SDUs have been lost during transmission,
                    as evidenced by a discontinuity in the  CP_PDU Sequence
                    Count. This is an optional parameter, the  presence or
                    absence of which is implementation-specific.  If Data
                    Loss Indicators are to be generated by a particular
                    implementation  then they must be declared at design
                    time and be used consistently by  all parties involved
                    in the implementation.

3.2.3     DETAILED PATH SERVICE SPECIFICATION

3.2.3.a   This section describes in detail the primitives and parameters
          associated with the identified services. Note that the
          parameters, which specify the information to be made available to
          the receiving entity, are specified in an abstract sense: a
          specific implementation is not constrained in the method of
          making this information available.

3.2.3.1   PACKET.request

3.2.3.1.a   Function

            This primitive is the service request primitive for the Packet
            service.

3.2.3.1.b   Semantics

            The primitive shall provide parameters as follows:

            PACKET.request           (P_SDU,
                                       APID,
                                       APID Qualifier [optional])

3.2.3.1.c   When Generated

            This primitive is passed from the User Application to the
            CCSDS Path layer to attempt to send the P_SDU.

3.2.3.1.d   Effect on Receipt

            Receipt of this primitive causes the CCSDS Path layer to
            attempt to send the P_SDU.

3.2.3.2     PACKET.indication

3.2.3.2.a   Function

            This primitive is the service indication
            primitive for the Packet service.

3.2.3.2.b   Semantics

            The primitive shall provide parameters as
            follows:

            PACKET.indication     (P_SDU,
                                   APID,
                                   APID Qualifier [optional] )

3.2.3.2.c   When Generated

            This primitive is passed from the CCSDS Path
            layer to the User Application to indicate the arrival of a
            P_SDU from the remote entity.

3.2.3.2.d   Effect on Receipt

            The effect on receipt of this primitive by
            the User Application is unspecified.

3.2.3.3     OCTET_STRING.request

3.2.3.3.a   Function

            This primitive is the service request
            primitive for the Octet String service.

3.2.3.3.b   Semantics

            The primitive shall provide parameters as
            follows:

            OCTET_STRING.request  (O_SDU,
                                   Path ID,
                                   Secondary Header Indicator)

3.2.3.3.c   When Generated

            This primitive is passed from the User
            Application to the CCSDS Path layer to attempt to send the
            O_SDU.

3.2.3.3.d   Effect on Receipt

            Receipt of this primitive causes the CCSDS
            Path layer to attempt to send the O_SDU.

3.2.3.4     OCTET_STRING.indication

3.2.3.4.a   Function

            This primitive is the service indication
            primitive for the Octet String service.

3.2.3.4.b   Semantics

            The primitive shall provide parameters as
            follows:

            OCTET_STRING.indication    (O_SDU,
                                        Path ID,
                                        Secondary Header Indicator,
                                        Data Loss Indicator [opt.])

3.2.3.4.c   When Generated

            This primitive is passed from the CCSDS Path
            layer to the User Application to indicate the arrival of an
            O_SDU from the remote entity.

3.2.3.4.d   Effect on Receipt

            The effect of receipt of this primitive by
            the User Application is unspecified.


3.3  PATH PROTOCOL SPECIFICATION

3.3.a  The Path protocol procedures are composed of Packet Construction
       Procedures and Packet Transfer Procedures. The Packet Construction
       Procedures are associated only with the Octet String service and
       are active only in the end systems of an LDP. The Packet Transfer
       procedures are associated with both the Octet String service and
       the Packet service, and are active in both the end systems and the
       intermediate systems of an LDP.

3.3.1     PACKET CONSTRUCTION PROCEDURES

3.3.1.a   The Packet Construction Procedures of the Octet String service
          consist of two functions: a "CCSDS Packet Assembly function" and
          a "CCSDS Packet Extraction function".

3.3.1.1     CCSDS PACKET ASSEMBLY FUNCTION

3.3.1.1.a   The Packet Assembly function accepts the octet string SDU and
            the Path ID and builds the CP_PDU (i.e., a CCSDS Packet). The
            Packet APID is derived from the Path ID. The Secondary Header
            Indicator parameter is generated by the source end user to
            indicate the presence or absence of a Secondary Header data
            structure at the start of the O_SDU.  The Packet Assembly
            function translates the parameter by setting the "Secondary
            Header Flag" in the CP_PDU to a corresponding value. A
            sequence counter is maintained, and is used to generate a
            "Packet Sequence Count" field in the CP_PDU.

3.3.1.2     CCSDS PACKET EXTRACTION FUNCTION

3.3.1.2.a   The Packet Extraction function exists only in the destination
            end system. This function strips the protocol control
            information from the CP_PDU and delivers the O_SDU to the Path
            service user. The CP_SAP is identified by the Path ID.

3.3.1.2.b   The Secondary Header Indicator parameter is generated by the
            Packet Extraction function to indicate the presence of a
            Secondary Header data structure at the start of the O_SDU.

3.3.1.2.c   The Packet Extraction function will check the continuity of
            the Packet Sequence Count to determine if one or more CP_PDUs
            have been lost during transmission, and will generate the
            optional Data Loss Indicator parameter accordingly.

3.3.2     PACKET TRANSFER PROCEDURES

3.3.2.a   The Packet Transfer Procedures consist of a "Transfer function"
          and a "Path Recovery function".

3.3.2.1     TRANSFER FUNCTION

3.3.2.1.a   The Transfer function of the Path layer is active in the
            source end system of an LDP and in any intermediate system
            Path Entities which route CP_PDUs based on examination of
            their Path ID. The Transfer function uses the Path ID to
            identify the next Path Entity in the LDP. The Transfer
            function may submit the CP_PDU to a number of SN_SAPs
            (subnetwork addresses) which are not necessarily on the same
            subnetwork;  i.e., it may perform a multicast function and
            thus provide a broadcast service.

3.3.2.1.b   The Transfer function may be replaced in some intermediate
            systems by local agreements which relate SN_SAPs in one
            subnetwork to SN_SAPs in another subnetwork.

3.3.2.2     PATH RECOVERY FUNCTION

3.3.2.2.a   The Path Recovery function is active in the destination end
            systems of an LDP. If the optional APID Qualifier is used
            within a destination end system, the APID Qualifier is
            represented by the SN_SAP address and the Path Recovery
            function may recover the APID Qualifier on the basis of that
            address and derive the Path ID. If the APID Qualifier is not
            used within the destination end system, the Path ID is derived
            directly from the APID of the CP_PDU. In the case of the
            Packet service, the CP_PDU is delivered intact to the user
            identified by the Path ID. CP_PDUs of LDPs terminating in the
            Octet String service are delivered to the CCSDS Packet
            Extraction function of the Packet Construction Procedures.

3.3.3     STRUCTURE AND ENCODING OF THE CCSDS PATH PROTOCOL DATA UNIT

3.3.3.a   The CCSDS Path Protocol Data Unit is the Version-1 CCSDS Packet.
          The structure of the CP_PDU is shown in Figure 3-4.

                                  [IMAGE]

               Figure 3-4:  CP_PDU (CCSDS Packet) Structure

3.3.3.b     The utilization of the fields within the CP_PDU is as follows:

3.3.3.1     VERSION (Bits 0 through 2)

3.3.3.1.a   The three Version bits shall be set to "000", signifying the
            Version-1 CCSDS Packet.

3.3.3.2     TYPE (Bit 3)

3.3.3.2.a   The Type bit is not used within CCSDS Advanced Orbiting
            Systems. It may be set to either value "0" or "1".

3.3.3.3     SECONDARY HEADER FLAG (Bit 4)

3.3.3.3.a   The Secondary Header flag indicates if a Secondary Header is
            present in the CP_PDU. If a Secondary Header is not present,
            the flag shall be set to value "0". If a Secondary Header is
            present, the flag shall be set to value "1".

3.3.3.4     APPLICATION PROCESS IDENTIFIER (Bits 5 through 15)

3.3.3.4.a   The APID (possibly in conjunction with the optional external
            APID Qualifier) provides the naming mechanism for the LDP,
            i.e., the Path ID. The name of the LDP defines the source, the
            destination, and the route taken between them.

3.3.3.4.b   Up to 2048 APIDs may be expressed by this 11-bit field.
            However, not all APIDs are available for LDP naming. A list of
            APIDs reserved for special purposes is contained in Table 5-4,
            from which it will be seen that only 2032 APIDs are available
            for LDP naming.

3.3.3.5     SEQUENCE FLAGS (Bits 16,17)

3.3.3.5.a   These flags may be set by the user of the Packet service to
            indicate that the User Data contained within the P_SDU is a
            segment of a larger set of application data;  the flags are
            not part of the Path protocol. The encoding of the Sequence
            Flags for the Packet service is as follows:

            00   =    P_SDU contains a continuation segment of User Data.
            01   =    P_SDU contains the first segment of User Data.
            10   =    P_SDU contains the last segment of User Data.
            11   =    P_SDU contains unsegmented User Data.

3.3.3.5.b   Note that if the Octet String service is invoked at any point
            within the LDP the flags must be set to the "11"
            configuration, since segmentation is not allowed within the
            Path service.

3.3.3.6     PACKET SEQUENCE COUNT (Bits 18 through 31)

3.3.3.6.a   The 14-bit Packet Sequence Count field shall contain a
            straight sequential count (modulo 16384) which numbers each
            CP_PDU generated on a particular LDP.

3.3.3.7     PACKET LENGTH (Bits 32 through 47)

3.3.3.7.a   The 16-bit Packet Length field contains a sequential binary
            count "C" which expresses the length (in octets) of the
            remainder of the CP_PDU that follows this field. The value of
            "C" is the number of remaining octets minus one.

3.3.3.8     SECONDARY HEADER

3.3.3.8.a   The contents of the Secondary Header are specified by the
            source end user. A definition of how the Secondary Header may
            be used to support timetagging of the CCSDS Packet is
            presented in Annex A.  In any instance, the length of the
            Secondary Header must be an integral number of octets.

3.3.3.9     USER DATA

3.3.3.9.a   This is the User Data field of the CP_PDU; it must be an
            integral number of octets in length.


3.4  MANAGEMENT OF THE PATH SERVICE

3.4.a  Some of the parameters associated with the CCSDS Path service are
       configured using management techniques. Management, through the use
       of signalling mechanisms, conveys the required configuration
       information to the applicable Path layer entities.

3.4.b  The following Path service configuration parameters are handled by
       management; these parameters are abstract and are independent of
       any particular management system implementation.

3.4.1     SERVICE OPTION

3.4.1.a   Management configures the source and destination end systems of
          an LDP to support either Octet String or Packet service. The
          service on a particular LDP may be asymmetric; e.g., the source
          may support Octet String service and the destination may be
          configured to deliver unsegmented Packet service.

3.4.2     LDP ROUTING LIST

3.4.2.a   Management establishes the route to be taken by each LDP and
          identifies the subnetworks which are components of the route. For
          each subnetwork, management supplies the following configuration
          information:

3.4.2.b   the SAP through which the LDP enters the subnetwork;  and

3.4.2.c   the SAP(s) through which the LDP exits the subnetwork;  and

3.4.2.d   the (optional) APID Qualifier to be used to maintain uniqueness
          of the LDP within that subnetwork.



4    CCSDS INTERNET SERVICE AND PROTOCOL SPECIFICATION


4.a  This Section specifies the services and protocol associated with the
     CCSDS Internet service.


4.1  INTERNET SERVICE DEFINITION

4.1.a  The CCSDS Internet service shall conform to ISO 8348/AD1,
       "Information Processing Systems--Data Communications--Network
       Service Definition--Addendum-1: Connectionless Mode Transmission"
       (Reference [18]).


4.2  INTERNET PROTOCOL SPECIFICATION

4.2.a  The protocol selected to provide the Internet service shall conform
       to ISO 8473, "Information Processing Systems--Data Communications--
       Protocol for Providing the Connectionless-Mode Network Service"
       (Reference [16]).


4.3  INTERNET PROTOCOL CONFORMANCE STATEMENT

4.3.a  The ISO 8473 protocol specification identifies three protocol
       options:

4.3.b     the Full Protocol Set;

4.3.c     the Non-Segmenting Subset;

4.3.d     the Inactive Subset.

4.3.e  In order to provide maximum flexibility in cross support and
       interworking situations, the Full Protocol Set has been selected by
       CCSDS.

4.3.f  ISO 8473 also specifies mandatory and optional protocol functions.
       Except for error reporting, all mandatory options specified for the
       Full Protocol Set shall be provided. This does not preclude the
       provision of other, optional protocol functions, for Project-unique
       reasons;  however, the availability of optional protocol functions
       cannot be guaranteed for cross support.

4.3.g  Since the Internet service may be required to operate through
       unidirectional data links, mandatory error reporting may not be
       possible.




5  SPACE LINK SUBNETWORK SERVICE AND PROTOCOL SPECIFICATION

5.1  INTRODUCTION

5.1.a   This section of the CCSDS Recommendation for Advanced Orbiting
        Systems defines the services and procedures for communicating
        between two spacecraft, or between a spacecraft and its associated
        ground system, within the Space Link Subnet (SLS). The
        relationship of the protocol specified in this section to the
        overall CCSDS Principal Network layering is described in Section
        2.

5.1.b   Figure 5-1 illustrates the relationship of SLS layers to the Data
        Link and Physical layers of the reference model of Open Systems
        Interconnection, Reference [15]. The "Space Link" (SL) layer is
        organized into two sublayers: a "Virtual Channel Link Control"
        (VCLC) sublayer and a "Virtual Channel Access" (VCA) sublayer.
        These reside upon a "Physical Channel Layer" that accesses the
        physical medium for space/space or space/ground communication.


                                  [IMAGE]

             Figure 5-1:  Space Link Sublayering Relationships


5.1.c   Within the SL layer, multiplexing provides multi-user access to
        the SLS; users of the SLS are defined as the entities which access
        the subnetwork at SL Service Access Points (SL_SAPs). The SL layer
        provides two levels of multiplexing: the VCA sublayer provides
        "Virtual Channels" (VCs), which allow several users to use the
        same Physical Channel concurrently; and the VCLC sublayer provides
        further multiplexing for packetized data by allowing separate
        communications between users (referred to as "Packet Channels") to
        be multiplexed onto the same VC.

5.1.d.  Figure 5-2 illustrates the architecture and services of the Space
        Link Subnetwork.


                                  [IMAGE]

                Figure 5-2:  Space Link Subnet Architecture


5.1.e   The VCLC and VCA sublayers are defined in terms of:

5.1.f      the services that each sublayer provides to its users; and

5.1.g      the underlying services each requires from its lower layer or
           sublayer; and

5.1.h      the internal protocol procedures of each sublayer; and

5.1.i      the formats of the protocol data units associated with each;
           and

5.1.j      the management interface each has with its sublayer management
           entity.

5.1.k   The service specification for the VCLC/VCA interface occurs in the
        service specification of both sublayers: in the VCLC sublayer
        specification, the service required by the VCLC sublayer is
        described; in the VCA sublayer specification, the service provided
        by the VCA sublayer is described.

5.1.l   The service specification for the interface between the VCA
        sublayer and the Physical Channel layer defines the services
        required from the Physical Channel layer.  These services are
        defined to be independent of the nature of the transmission
        medium.

5.1.m   The service specifications for the management interfaces define
        the services between each sublayer and its sublayer management
        entity.

5.1.n   All of the service specifications are given in the form of
        primitives, which present an abstract model of the logical
        exchange of data structures and control information between the SL
        sublayers and the user of the sublayer services. The primitives
        are specified to be independent of specific implementation
        approaches.

5.1.o   The VCLC and VCA peer-to-peer protocol specifications define the
        procedures for the transfer of information between peer VCLC and
        VCA sublayer entities. They are independent of the type of space
        channel transmission medium used, and relate to each VCLC or VCA
        entity separately and independently from any other VCLC or VCA
        entity that might exist at the same time.

5.1.1     VIRTUAL CHANNEL LINK CONTROL SUBLAYER SERVICES

5.1.1.a Virtual Channel Link Control sublayer services provide for the
        transfer of "VCLC Service Data Units" (VCLC_SDUs) across a VC
        within "VCLC Protocol Data Units" (VCLC_PDUs). The VCLC_SDU may be
        either variable-length, delimited and octet-aligned "packetized"
        data, or "Bitstream" Data.

5.1.1.b Variable-length delimited SDUs which are to be carried in the same
        VC are multiplexed together in the VCLC_PDU. Delimited SDUs
        associated with different SLS users are carried in different
        "Packet Channels"; in this way several SLS users may have access
        to the same VC. The multiplexing mechanism is the Version-1 CCSDS
        Packet, and the Packet Channels are identified by the Application
        Process Identifier (APID) in the CCSDS Packet header.

5.1.1.c Variable-length delimited SDUs which conform to the Version-1
        CCSDS Packet format may be transferred through the Space Link
        Subnet via a "Multiplexing service". Alternatively, variable-
        length delimited SDUs which are not in CCSDS Packet format may be
        prepared for multiplexing and transfer via an "Encapsulation
        service".

5.1.1.d Bitstream Data are placed into VCLC_PDUs dedicated to individual
        users. The service is provided by a "Bitstream service".

5.1.1.e Table 5-1 shows the combination of VCLC services which are
        permitted (denoted by an "X") to be concurrently used within a VC.


         Table 5-1:  Allowed Concurrent VCLC Service Combinations

                                  [IMAGE]


5.1.2     VIRTUAL CHANNEL ACCESS SUBLAYER SERVICES

5.1.2.a The Virtual Channel Access sublayer provides a VCA service for the
        transfer of "VCA Service Data Units" (VCA_SDUs) across the
        physical space channel within "Virtual Channel Protocol Data
        Units" (VC_PDUs). To facilitate synchronization procedures when
        transmitting the VC_PDUs through weak-signal, noisy space
        channels, the VC_PDUs (and therefore the VCA_SDUs) are of fixed
        length on any particular Physical Channel: their length is set by
        management.

5.1.2.b VC_PDUs are implemented using a CCSDS data structure known as a
        "Virtual Channel Data Unit" (VCDU). Within the VCA sublayer, a
        VCDU may be error protected by transforming it into a CCSDS data
        structure known as a "Coded Virtual Channel Data Unit" (CVCDU).
        The CVCDU is identical to the VCDU except that internally its data
        field is shortened and a block of error-correcting Reed-Solomon
        check symbols is included. The VCDUs and CVCDUs that are
        transmitted on a particular Physical Channel are all of the same
        length.

5.1.2.c Internal to a VC_PDU, two other VCA sublayer error protection
        options are provided in addition to the Reed-Solomon encoding.
        First, a few critical routing fields of the VCDU header may be
        protected by adding an optional "VCDU Header Error Control" field.
        Second, the entire VCDU may be appended with an optional "VCDU
        Error Control" field which uses a cyclic redundancy code to
        provide a capability to detect errors occurring anywhere within
        the VC_PDU.

5.1.2.d Each VC_PDU (i.e., each VCDU or CVCDU) carries precisely one
        VCA_SDU and is uniquely identified by means of a "VCDU-ID" field
        which consists of a "Spacecraft Identifier" concatenated with a
        "Virtual Channel Identifier".

5.1.2.e The VCA sublayer provides a "Virtual Channel Access" service
        whereby an SLS user may implement a private VCLC sublayer protocol
        and submit fixed-length private VCA_SDUs directly to the VCA
        sublayer for transfer through the SLS using one or more dedicated
        Virtual Channels. Since both the format and content of the private
        VCA_SDUs are unknown to the SLS, cross support is confined to
        their delivery using VC_PDU routing mechanisms. (Note: Project
        organizations that use the Virtual Channel Access service and wish
        to receive cross support of a private VCLC sublayer protocol may
        make proposals to CCSDS for its registration as a standard, in
        which case this Recommendation would be extended if the proposal
        is accepted.)

5.1.2.f The VCA sublayer provides an "Insert" service to support the
        isochronous transfer of samples of octet-aligned data (e.g., audio
        or teleoperations control information). This service is usually
        only invoked to support the isochronous transfer when the total
        transmitted data rate across the physical space channel is low
        (typically less than 10 Mb/s). An Insert Service Data Unit
        (IN_SDU) is placed into a special "Insert Zone" that exists in
        every transmitted VC_PDU on a particular Physical Channel, thus
        offering a fixed, synchronous time slot to the user. The presence
        or absence of the Insert Zone is established by management for
        each individual Physical Channel.

5.1.2.g The VCA sublayer provides a "Virtual Channel Data Unit" service
        whereby the service data units are themselves fully formed VC_PDUs
        (created by an independent VCA sublayer entity) that may be
        directly interleaved into the stream of VC_PDUs which are
        transmitted on a particular Physical Channel. The independently
        created VC_PDUs internally support SLS services provided by a
        separate VCA sublayer entity.

5.1.2.h Each fixed-length VC_PDU is prefixed and delimited by a
        Synchronization Marker for transfer across the Physical Channel.
        The resulting data unit is known as a "Channel Access Data Unit"
        (CADU). A serial stream of bits, representing a continuous and
        contiguous string of CADUs, forms the "Physical Channel Access
        Protocol Data Unit" (PCA_PDU) which is used by the VCA sublayer to
        access the Physical Channel layer. Each CADU therefore provides a
        fixed data transmission time slot within the synchronously
        transmitted PCA_PDU.

5.1.2.i A PCA_PDU transmitted through a Physical Channel is identified
        within the VCA sublayer by a Link Identifier or "LinkID".

5.1.2.j The LinkID is the naming mechanism for those VCA sublayer services
        (e.g., Insert) which are bound to every VC_PDU that is present in
        a particular PCA_PDU.  It is also the mechanism for identifying
        the managed attributes of a particular PCA_PDU, including:  the
        data transmission rate; the VCDU-IDs which may appear in a
        particular PCA_PDU, their Version Numbers and if applicable their
        multiplexing sequence; the length of the CADUs in that PCA_PDU;
        the presence and length of any Inserts; and the presence or
        absence of any techniques which provide adequate bit transitions
        in the PCA_PDU.

5.1.2.k The LinkID in any particular implementation is conveyed in an "out-
        of-band" fashion by local management associations, not by "in-
        band" protocol.  It is therefore a logical mechanism for ascribing
        physical attributes to a PCA_PDU, rather than an element of
        essential inline protocol addressing information.


5.1.3     PHYSICAL CHANNEL SERVICE

5.1.3.a The Physical Channel layer, which provides a "Physical Channel
        Service" to the VCA sublayer, activates the physical space medium
        for transmission of the PCA_PDU between two spacecraft, or between
        a spacecraft and its supporting ground system. The CCSDS
        Recommendation for "Radio Frequency and Modulation", Reference
        [14], contains specifications for space/ground and ground/space
        physical channels. The applicability of this Recommendation to
        general space/space communications has not been determined.


5.1.4     SLS GRADES OF SERVICE

5.1.4.a User data which are carried within VCDUs receive "Grade-3"
        service; i.e., their transmission is dependent upon the
        performance of the Physical Channel and may not be error
        controlled.

5.1.4.b User data which are carried within CVCDUs receive "Grade-2"
        service; i.e., their transmission is error controlled using the
        Reed-Solomon coding.

5.1.4.c Link retransmission ("ARQ") procedures are provided within the
        Virtual Channel Access sublayer for some user data which require
        "Grade-1" service. These data are carried within CVCDUs which
        provide Reed-Solomon error control, augmented by the ARQ protocol
        to ensure their completeness. The ARQ procedures are described in
        Section 6.

5.1.4.d Table 5-2 shows the SLS Grades of Service as a function of the
        error-protection mechanisms available within the VCA sublayer.
        Those mechanisms listed as "M" are mandatory for that Grade of
        Service.  Those mechanisms listed as "O" are optional for that
        Grade of Service.  Those mechanisms listed as "O/M" are normally
        optional for that Grade of Service, but may be mandatory in
        certain situations (see paragraphs 5.4.9.1.2.3 and 5.4.9.1.2.10).
        Those mechanisms listed as "n/a" are not applicable to that Grade
        of Service, insofar as their presence would automatically change
        the Grade of Service to a higher grade.

    Table 5-2:  Error Protection Requirements of SLS Grades of Service

                                  [IMAGE]


5.1.4.e Not all combinations of SLS services and Grades of Service are
        permitted. Table 5-3 summarizes the service options which are
        allowed (denoted by "X") within the SLS, in combination with the
        SLS Grades of Service and the Isochronous ("I") or Asynchronous
        ("A") data transfer.

             Table 5-3:  Allowable Types and Grades of Service

                                  [IMAGE]


5.1.4.f Caution should be exercised when using Grade-3 service, since the
        service does not provide the low error rate required for reliable
        extraction of the type of asynchronous packetized data associated
        with the Multiplexing, Encapsulation, and (possibly) Virtual
        Channel Access services.

5.1.4.g Insert SDUs must be contained in every VC_PDU (VCDU and/or CVCDU)
        transmitted in a PCA_PDU which is authorized by management to
        support Insert service (see 5.1.2h-k), and their length must be
        constant so that the data-carrying space available for other types
        of SDUs is known. Although an Insert SDU may be carried in a
        VC_PDU for which Grade-1 service is provided, Grade-1 service
        (i.e., ARQ) will not be provided for the Insert SDU.

5.1.4.h Within the VCDU service, cross support of a particular Grade of
        Service is necessarily the subject of local agreements.


5.1.5     SPACE LINK ADDRESSING

5.1.5.a The Virtual Channel Access and Virtual Channel Link Control
        sublayers of the Space Link layer each have their own addressing
        mechanisms.

5.1.5.b The VCA sublayer uses the VCDU-ID to identify the VCA-SAPs for the
        Virtual Channel Data Unit service and the VCA service.  The VCDU-
        ID also identifies the user of the Virtual Channel Data Unit
        service or VCA service and hence identifies the relationship
        between the VCA_SAPs and the users of these services.  The
        VCA_SAPs are bound by management at the transmitting end of a data
        link to one or more PCA_PDUs.  Although multicasting of a virtual
        channel through multiple PCA_PDUs is permitted if the VCDU size is
        the same for all of the relevant PCA_PDUs and Insert service is
        not present in any of those PCA_PDUs, multiplexing of a virtual
        channel across multiple PCA_PDUs is forbidden.

5.1.5.c The VCA sublayer uses the LinkID to identify the VCA_SAPs for the
        Insert service.

5.1.5.d The users of the VCLC services are identified by the VCLC_SAPs.
        The VCLC_SAP address, which is unique across all VCLC services, is
        composed of a number of parts which vary for each service:

5.1.5.e    the VCLC_SAPs for the Bitstream service are identified by the
           VCDU-ID; and

5.1.5.f    the VCLC_SAPs for the Multiplexing and Encapsulation services
           are identified by the VCDU-ID plus the Packet Channel
           Identifier (PCID). The PCID is represented by the 11-bit
           Application Process ID (APID) in the Version-1 CCSDS Packet.

5.1.5.g The PCIDs associated with the Multiplexing service do not overlap
        with those associated with the Encapsulation service. Certain PCID
        values are reserved by CCSDS for special uses such as for the
        encapsulation of the ISO 8473 Internet protocol data units (using
        the Encapsulation service) during their transfer through the SLS.
        There are 2048 possible PCIDs, some of which are reserved by CCSDS
        for special uses. Table 5-4 specifies how the PCIDs are allocated.

5.1.5.h The nonreserved PCID values (0-2031) are administered as "user
        domains" by Project organizations and are allocated to
        Multiplexing service users in conjunction with the CPN Path
        service. Each user domain is named by the Spacecraft ID component
        of the VCDU-ID concatenated with the Version Number "01".

5.1.5.i The VCLC_SAP addressing for the Encapsulation service (E-service),
        Multiplexing service (M-service) and Bitstream service (B-service)
        is summarized in Table 5-5.


   Table 5-4:  Packet Channel/Application Process Identifier Allocations

                                  [IMAGE]



                  Table 5-5:  VCLC_SAP Address Parameters

                                  [IMAGE]


5.1.6     ISOCHRONOUS SERVICE

5.1.6.a The VCA sublayer provides isochronous data transfer across the
        SLS, with a jitter dependent on that of the CADUs. The CADUs each
        occupy a fixed time slot within the PCA_PDU which is transmitted
        serially on the Physical Channel. Therefore, for example, if the
        CADU-to-CADU "time slot jitter" is 1-nanosecond, then this same
        jitter will apply to the isochronous data.

5.1.6.b The isochronous data transfer can be achieved either:

        (1)   by using a dedicated Virtual Channel which is timed to occur
               at a fixed interval (i.e., every nth CADU), thus providing a
               fixed time slot; or

        (2)   by using the Insert service, which provides a fixed-length,
               time division multiplexed, synchronous data sample in every
               transmitted CADU via an "Insert Zone" in the VC_PDU.

5.1.6.c In both cases, the controlling clock is that of the SLS.
        Disregarding the SLS propagation delay, if the frequency of
        occurrence of CADUs on the physical channel is "F" then the SLS
        access delay for method (1) is therefore n/(F) and the SLS access
        delay for method (2) is 1/(F).


5.2  SPACE LINK SUBNETWORK PERFORMANCE REQUIREMENTS

5.2.a   This section contains an overview of the performance required
        within the SLS. Some of the implications of these performance
        requirements are discussed more fully in Reference [8].


5.2.1     PHYSICAL CHANNEL OPERATING POINTS

5.2.1.a In order to conserve bandwidth, the Space Link Subnet assumes that
        the stream of CADUs is modulated directly onto the space channel.
        However, in the event that an uncoded channel cannot provide the
        required performance, the stream of CADUs may as a Project option
        be coded before modulation. The design parameters for the standard
        CCSDS convolutional inner code are specified in Reference [3].


5.2.2     PROBABILITY OF VCDU MISIDENTIFICATION

5.2.2.a The stream of CADUs delivered at the receiving end of the Space
        Channel layer may contain VCDUs and/or CVCDUs, inserted in a
        nondeterministic order, each labelled by the VCDU Identifier (VCDU-
        ID) field consisting of a Spacecraft ID concatenated with a
        Virtual Channel ID. Multiple Spacecraft ID and Virtual Channel ID
        fields, qualified by their Version Numbers, must potentially be
        examined in order to deliver the data units to the proper data
        handling process within the VCA sublayer.  An error occurring in
        these fields will therefore cause misidentification of the data
        unit and consequent disruption in service.

5.2.2.b The baseline performance requirement for the VCA sublayer is that
        the probability of misidentifying a VCDU or CVCDU, owing to a
        channel-induced error occurring in the VCDU-ID field, shall be
        less than 1x10E-07.

5.2.2.c Recognizing that VCDUs (Grade-3) and CVCDUs (Grade-2) may be mixed
        on a Physical Channel, and that for some applications it may be
        desired to deliver data prior to the Reed-Solomon decoding
        process, a mechanism must therefore be provided to protect the
        VCDU-ID field against channel-induced error so that the minimum
        misidentification probability is guaranteed. A "VCDU Header Error
        Control" field is therefore provided as an option in the VCDU
        header to provide this protection. The probability of
        misidentifying a VCDU or CVCDU due to an error induced by the
        space channel may thus be governed by the performance of the VCDU
        Header Error Control mechanism.


5.2.3     PERFORMANCE OF THE GRADES OF SERVICE

5.2.3.a The performance of each of the various Grades of Service offered
        within the Space Link Subnet is governed by:

5.2.3.b    the probability that a particular VCDU/CVCDU is missing in the
           sequence observed at the receiving end of the Physical Channel,
           as a result of rejection due to an uncorrectable channel-
           induced error;  and

5.2.3.c    the probability that an undetected channel-induced error exists
           somewhere within a particular accepted VCDU/CVCDU at the
           receiving end of the Physical Channel.

5.2.3.d The performance of each of the Grades of Service is a function of
        the particular physical space medium being used. In Reference [8],
        assuming the conditions of an additive white Gaussian noise
        channel, the performance of each of the Grades of Service is
        addressed parametrically.

5.2.3.e When operating a Virtual Channel in Grade-3 service the
        performance is established by the characteristics of the Physical
        Channel and the performance of the VCDU Header Error Control
        mechanism. Within Grade-2 service, the performance probabilities
        are improved by the error-correcting capabilities of the Reed-
        Solomon code. Within Grade-1 service, the probabilities are
        further improved by the provision of the link retransmission
        protocol.

5.2.3.f Under the Physical Channel operating conditions necessary to
        achieve the required 1x10E-07 probability of VCDU
        misidentification, the minimum required service provided by the
        Space Link Subnet within the three Grades of Service is as shown
        in Table 5-6. Reference [8] presents examples of achieved
        performance on a particular Physical Channel.


                Table 5-6:  Minimum Required Performance of
                            SLS Grades of Service

                                  [IMAGE]


5.3  VIRTUAL CHANNEL LINK CONTROL SUBLAYER

5.3.a   This section contains the service and protocol specifications for
        the Virtual Channel Link Control sublayer. The VCLC sublayer
        provides services to transfer either delimited "packetized" or
        undelimited "Bitstream" service data units within user specified
        VCs.


5.3.1     VCLC FUNCTIONAL OVERVIEW

5.3.1.a Delimited service data units (i.e., packetized data) are
        transferred using fixed-length "Multiplexing Protocol Data Units"
        (M_PDUs). The M_PDUs are constructed by multiplexing together
        Version-1 CCSDS Packets that are to be delivered over the same VC,
        and breaking the resulting stream of Packets into fixed-length
        blocks which exactly fit the data space of the VC_PDU in the layer
        below. Non-CCSDS Packet delimited service data units are first
        encapsulated within a unique Version-1 CCSDS Packet prior to
        multiplexing.

5.3.1.b Bitstream Data are transferred using fixed-length "Bitstream
        Protocol Data Units" (B_PDUs) which are dedicated to a single
        user.

5.3.1.c The VCLC sublayer uses the VCA service of the VCA sublayer to
        transfer its PDUs (i.e., M_PDUs and B_PDUs). The VCDU-ID parameter
        is used by the VCLC sublayer to identify the VC for the transfer.
        It is passed with the M_PDU and the B_PDU to the VCA sublayer,
        which builds the VC_PDU.


5.3.2     INTERNAL ORGANIZATION OF THE VCLC SUBLAYER

5.3.2.a The VCLC sublayer provides three types of services and contains
        three procedures. The services, procedures, and their mandatory
        interface parameters are illustrated in Figure 5-3.

                                  [IMAGE]

          Figure 5-3:  Internal Organization of the VCLC Sublayer


5.3.3     VCLC SERVICES PROVIDED

5.3.3.a The VCLC sublayer provides three services to its users:
        Encapsulation, Multiplexing, and Bitstream.

5.3.3.1 ENCAPSULATION SERVICE

5.3.3.1.a The Encapsulation service provides transfer of non-CCSDS
          structured delimited, octet-aligned data units across the Space
          Link Subnet. These data units are encapsulated within CCSDS
          Packets for multiplexing within a VC.

5.3.3.2 MULTIPLEXING SERVICE

5.3.3.2.a The Multiplexing service provides transfer of CCSDS Packets
          across the Space Link Subnet. CCSDS Packets (and other non-CCSDS
          delimited data units, encapsulated within CCSDS Packets) are
          multiplexed together for transfer within a VC.


5.3.3.3 BITSTREAM SERVICE

5.3.3.3.a The Bitstream service provides transfer of undelimited Bitstream
          Data across the Space Link Subnet.


5.3.4  SERVICES ASSUMED FROM THE VIRTUAL CHANNEL ACCESS SUBLAYER

5.3.4.a The service required by the VCLC sublayer to exchange VCLC_PDUs is
        the VCA service provided by the VCA sublayer. The service
        parameters, as used by the VCLC sublayer, are:

5.3.4.b VCA_SDU     The VCA_SDU is the VCLC_PDU;

5.3.4.c VCDU-ID     The VCDU-ID is the same as the VCDU-ID parameter used
                    in the VCLC service primitives;

5.3.4.d VCDU        The VCDU Loss Flag is used to notify the user at the
        Loss        destination end of a VCA service that a sequence
        Flag        discontinuity has been detected and that one or more
                    VC_PDUs has been lost.  The VCDU Loss Flag is
                    mandatory (in contrast to similar flags provided by the
                    Encapsulation and Bitstream services) in recognition of
                    its  importance in the Multiplexing and Bitstream
                    procedures of the  VCLC sublayer.


5.3.5     SERVICES ASSUMED FROM THE LOCAL ENVIRONMENT

5.3.5.a The services assumed from the local environment are unspecified.

5.3.6     VCLC SUBLAYER SERVICE INTERFACE SPECIFICATION

5.3.6.1 OVERVIEW OF INTERACTIONS

5.3.6.1.1 ENCAPSULATION SERVICE

5.3.6.1.1.a The Encapsulation service is used to transfer non-CCSDS
            structured delimited, octet-aligned Encapsulation SDUs (E_SDUs)
            by encapsulating them within Encapsulation Protocol Data Units
            (E_PDUs). The E_PDUs use the Version-1 CCSDS Packet structure.
            They are transferred according to the Grade of Service
            specified by management for the requested VC. The service
            permits E_SDUs to have any format and to be of any length which
            is an integral number of octets, up to 65,536 octets maximum;
            however, individual Project organizations shall establish the
            maximum and minimum sizes for the E_SDU, providing that the
            65,536-octets maximum length is not exceeded.

5.3.6.1.1.b The service primitives associated with this service are:

                E_UNITDATA.request
                E_UNITDATA.indication

5.3.6.1.1.c    The E_UNITDATA.request primitive is passed to the VCLC
               sublayer to request that an E_SDU be encapsulated and
               multiplexed into the specified Virtual Channel and sent.

5.3.6.1.1.d    The E_UNITDATA.indication is passed from the VCLC sublayer
               to indicate the arrival of an E_SDU.

5.3.6.1.1.e    When the Encapsulation service is used as the underlying
               subnetwork service for the CCSDS Internet service (see
               section 4), a convergence function must be performed to map
               between the SN_UNITDATA primitives specified for the ISO
               8473 protocol and the E_UNITDATA primitives specified for
               the Encapsulation service.  The mechanics of the convergence
               function depend on the implementation of the systems
               involved.  They are therefore necessarily the subject of
               local cross support negotiations.

5.3.6.1.2 MULTIPLEXING SERVICE

5.3.6.1.2.a    The Multiplexing service is used to transfer Multiplexing
               SDUs (M_SDUs) which are preformatted as Version-1 CCSDS
               Packets. They are transferred according to the Grade of
               Service specified by management for the requested VC. The
               CCSDS Packet structure allows the M_SDUs to be multiplexed
               along with other M_SDUs and E_PDUs using the specified VC.
               The service permits the M_SDU to be of any length which is
               an integral number of octets, up to 65,542 octets maximum;
               however, individual Project organizations shall establish
               the maximum and minimum sizes for the M_SDU, providing that
               the 65,542-octets maximum length is not exceeded.

5.3.6.1.2.b    The service primitives associated with this service are:

                   M_UNITDATA.request
                   M_UNITDATA.indication

5.3.6.1.2.c   The M_UNITDATA.request primitive is passed to the VCLC
              sublayer to request that an M_SDU structured as a Version-1
              CCSDS Packet be multiplexed into the specified Virtual
              Channel, and sent.

5.3.6.1.2.d   The M_UNITDATA.indication is passed from the VCLC sublayer
              to indicate the arrival of an M_SDU.

5.3.6.1.2.e   When the Multiplexing service is used as the underlying
              subnetwork service for the CCSDS Path service (see section
              3), a convergence function must be performed to map between
              the SN_UNITDATA primitives specified for the Path protocol
              and the M_UNITDATA primitives specified for the Multiplexing
              service.  The mechanics of the convergence function depend
              on the implementation of the systems involved:  they are
              therefore necessarily the subject of local cross support
              negotiations.

5.3.6.1.3     BITSTREAM SERVICE

5.3.6.1.3.a   The Bitstream service is used to transfer Bitstream Data.
              Different Bitstreams are not multiplexed within a Virtual
              Channel; i.e., each VC is dedicated to one source of
              Bitstream Data. The service allows Bitstreams to be of any
              length. However, the length of data that implementations may
              support at the service interface may vary for any one use of
              the Bitstream service primitives. That is, the length of
              data accepted for transfer at the source in one Bitstream
              service request may not be equal in length to the data
              delivered at the destination in one Bitstream service
              indication, e.g., since "fill" may be inserted and its
              location indicated.

5.3.6.1.3.b   There are two service primitives associated with this
              service:

                BITSTREAM.request
                BITSTREAM.indication

5.3.6.1.3.c   The BITSTREAM.request primitive is passed to the VCLC
              sublayer to request that Bitstream Data be sent.

5.3.6.1.3.d   The BITSTREAM.indication primitive is passed from the VCLC
              sublayer to indicate the arrival of Bitstream Data.

5.3.6.2    VCLC SERVICE PRIMITIVE PARAMETERS

5.3.6.2.a  The parameters for the VCLC primitives are described below.
           Unique uses of these parameters by any primitive are described
           in the "Additional Comments" section in the detailed
           description of that primitive.

5.3.6.2.b  E_SDU      The Encapsulation Service Data Unit. An E_SDU is a
                      delimited, octet-aligned data unit which, since it
                      is not formatted as a Version-1 CCSDS Packet, has a
                      format and content that are both unknown to the VCLC
                      sublayer.

5.3.6.2.c  M_SDU      The Multiplexing Service Data Unit. An M_SDU is a
                      delimited, octet-aligned data unit which is
                      necessarily formatted as a Version-1 CCSDS Packet.
                      The content and format of an M_SDU header is both
                      known to and used by the VCLC sublayer.

5.3.6.2.d  Bitstream  Bitstream Data are undelimited strings of bits
           Data       whose content and format are unknown to the VCLC
                      sublayer.

5.3.6.2.e  PCID       The Packet Channel Identifier. The PCID identifies
                      the VCLC_SAPs for M_SDUs and E_SDUs within a
                      specific VC. The PCID is locally expressed by the
                      Application Process ID field in the Version-1 CCSDS
                      Packet header. A subset of the PCID (i.e., APID)
                      values are reserved for assignment and
                      administration by CCSDS, as specified in Table 5-4;
                      the remaining values are available for
                      administration by users. Reserved values are
                      globally unique, while user values are unique only
                      within their own administrative domain (which is
                      named by the Spacecraft ID within the VCDU-ID).
                      Within the ground network, user PCIDs may need to be
                      qualified to achieve a unique VCLC_SAP address; the
                      parameter which qualifies them is the Spacecraft ID,
                      concatenated with the Version Number "01".

5.3.6.2.f  VCDU-ID    The Virtual Channel Data Unit Identifier, which
                      consists of the Spacecraft Identifier (SCID)
                      concatenated with the Virtual Channel Identifier
                      (VCID).

5.3.6.2.g  Bitstream  The Bitstream Data Loss Flag is an optional
           Data Loss  parameter which may be used to notify the user at
           Flag       the destination end of the VCLC Bitstream service
                      that a sequence discontinuity has been detected  and
                      that Bitstream data may have been lost. If
                      implemented, the  flag shall be derived from the
                      VCDU Loss Flag received from the  VCA sublayer.  If
                      this flag is generated by a particular
                      implementation then it must be declared at design
                      time and be  used consistently by all parties
                      involved in the implementation.

5.3.6.2.h  E_SDU      The E_SDU Loss Flag is an optional parameter which may
           Loss Flag  be used to notify the user at the destination end of
                      the VCLC Encapsulation  service that a sequence
                      discontinuity has been detected and that  one or
                      more E_SDUs have been lost. If implemented, the flag
                      shall  be derived by examining the Packet Sequence
                      Count in the  E_PDU.  If this flag is generated by a
                      particular  implementation then it must be declared
                      at design time and be  used consistently by all
                      parties involved in the implementation.


5.3.7     DETAILED VCLC SERVICE SPECIFICATION

5.3.7.a This section describes in detail the primitives and parameters
        associated with each VCLC service. The parameters are specified in
        an abstract sense and specify the information to be made available
        to the user of the primitive. A specific implementation is not
        constrained in the method of making this information available.

5.3.7.1 E_UNITDATA.request

5.3.7.1.a  Function

           This primitive is the service request
           primitive for the Encapsulation service.

5.3.7.1.b  Semantics

           The primitive shall provide parameters as
           follows:

           E_UNITDATA.request   (E_SDU,
                                 VCDU-ID,
                                 PCID)

5.3.7.1.c  When Generated

           This primitive is passed to the VCLC sublayer
           to request it to send the E_SDU.

5.3.7.1.d  Effect on Receipt

           Receipt of this primitive causes the VCLC
           sublayer to attempt to send the E_SDU.

5.3.7.1.e  Additional Comments

           None.

5.3.7.2    E_UNITDATA.indication

5.3.7.2.a  Function

           This primitive is the service indication
           primitive for the Encapsulation service.

5.3.7.2.b  Semantics

           The primitive shall provide parameters as
           follows:

           E_UNITDATA.indication(E_SDU,
                                 VCDU-ID,
                                 PCID,
                                 E_SDU Loss Flag [opt.])

5.3.7.2.c  When Generated

           This primitive is passed from the VCLC
           sublayer to the Encapsulation service user to indicate the
           arrival of an E_SDU.

5.3.7.2.d  Effect on Receipt

           The effect of receipt of this primitive by
           the Encapsulation service user is unspecified.

5.3.7.2.e  Additional Comments

           The optional E_SDU Loss Flag may be passed to
           the user of the Encapsulation service to signal a sequence
           discontinuity.

5.3.7.3    M_UNITDATA.request

5.3.7.3.a  Function

           This primitive is the service request
           primitive for the Multiplexing service.

5.3.7.3.b  Semantics

           The primitive shall provide parameters as
           follows:

           M_UNITDATA.request   (M_SDU,
                                 PCID,
                                 VCDU-ID)

5.3.7.3.c  When Generated

           This primitive is passed to the VCLC sublayer
           to request it to send the M_SDU.

5.3.7.3.d  Effect on Receipt

           Receipt of this primitive causes the VCLC
           sublayer to attempt to send the M_SDU.

5.3.7.3.e  Additional Comments

           This primitive is used to attempt to send
           CCSDS Packets across the SLS.

5.3.7.4    M_UNITDATA.indication

5.3.7.4.a  Function

           This primitive is the service indication
           primitive for the Multiplexing service.

5.3.7.4.b  Semantics

           The primitive shall provide parameters as
           follows:

           M_UNITDATA.indication (M_SDU,
                                  PCID,
                                  VCDU-ID)

5.3.7.4.c  When Generated

           This primitive is passed from the VCLC
           sublayer to the Multiplexing service user to indicate the
           arrival of an M_SDU.

5.3.7.4.d  Effect on Receipt

           The effect of receipt of this primitive by
           the Multiplexing service user is specified in the Path service
           specification, Section 3.

5.3.7.4.e  Additional Comments

           This primitive is used to deliver CCSDS
           Packets to the user identified by the PCID (i.e., the
           Application Process ID field in the Version-1 CCSDS Packet
           header, as qualified by the VCDU-ID). The CCSDS Packet header
           is not stripped prior to delivery. The Multiplexing service
           does not provide a "data loss" parameter to its users; any
           discontinuities associated with the Multiplexing service that
           are detected by the VCA sublayer are handled by management.

5.3.7.5    BITSTREAM.request

5.3.7.5.a  Function

           This primitive is the service request
           primitive for the Bitstream service.

5.3.7.5.b  Semantics

           The primitive shall provide parameters as
           follows:

           BITSTREAM.request    (Bitstream Data,
                                 VCDU-ID)

5.3.7.5.c  When Generated

           This primitive is passed to the VCLC sublayer
           to request it to send the Bitstream Data.

5.3.7.5.d  Effect on Receipt

           Receipt of this primitive causes the VCLC
           sublayer to attempt to send the Bitstream Data.

5.3.7.5.e  Additional Comments

           Since the service interface specification is
           an abstract specification, the implementation of the Bitstream
           Data parameter is not constrained; i.e., it may be continuous
           Bitstream, delimited Bitstream, or individual bits.

5.3.7.6    BITSTREAM.indication

5.3.7.6.a  Function

           This primitive is the service indication
           primitive for the Bitstream service.

5.3.7.6.b  Semantics

           The primitive shall provide parameters as
           follows:

           BITSTREAM.indication (Bitstream Data,
                                 VCDU-ID,
                                 Bitstream Data
                                 Loss Flag [opt.])

5.3.7.6.c  When Generated

           This primitive is passed from the VCLC
           sublayer to the Bitstream service user to indicate the arrival
           of Bitstream Data.

5.3.7.6.d  Effect on Receipt

           The effect of receipt of this primitive by
           the Bitstream service user is not specified.

5.3.7.6.e  Additional Comments

           The quantity of user data delivered by an
           implementation of this service primitive is not defined.
           Therefore, it is not necessarily related to the quantity of
           data submitted to the Bitstream service by the sender using the
           BITSTREAM.request primitive. The optional Bitstream Data Loss
           Flag is derived from the VCDU Loss Flag parameter received from
           the VCA sublayer.


5.3.8      VCLC PROTOCOL SPECIFICATION

5.3.8.1    VCLC PROTOCOL PROCEDURES

5.3.8.1.a  The VCLC Protocol Procedures are composed of
           Encapsulation Procedures, Multiplexing Procedures, and
           Bitstream Procedures.

5.3.8.1.1    ENCAPSULATION PROCEDURES

5.3.8.1.1.a    The Encapsulation Procedures provide an "Encapsulation
               Function" for the E_UNITDATA.request service primitive, and
               a "De-Encapsulation Function" for the E_UNITDATA.indication
               service primitive.

5.3.8.1.1.1    ENCAPSULATION FUNCTION

5.3.8.1.1.1.a  The Encapsulation Function is used to encapsulate delimited,
               octet-aligned E_SDUs, which are passed to the VCLC sublayer
               with the E_UNITDATA.request. Any E_SDUs which exceed 65,536
               octets in length (or Project-specified maximum and minimum
               lengths that are less than 65,536 octets) are rejected by
               the Encapsulation Function. Each valid E_SDU is encapsulated
               in an E_PDU. The E_SDU is placed unchanged into the User
               Data field of the E_PDU (i.e., the CCSDS Packet).

5.3.8.1.1.1.b  The Multiplexing Procedures transfer the E_PDU from the
               Encapsulation Function to the De-Encapsulation Function at
               the destination VCLC sublayer entity. The E_PDU and its VCDU-
               ID are submitted to the Multiplexing Procedures via an
               internal VCLC interface. E_PDU header fields in the CCSDS
               Packet, which are set by the Encapsulation Function, are the
               PCID (i.e., the APID), the Sequence Count, and the Packet
               Length.

5.3.8.1.1.2    DE-ENCAPSULATION FUNCTION

5.3.8.1.1.2.a  The De-Encapsulation Function is used to deliver E_SDUs to
               the destination Encapsulation service user. The De-
               Encapsulation Function removes E_SDUs, unchanged, from
               E_PDUs received from the Multiplexing Procedures. The E_PDU
               PCID field is used, in conjunction with the VCDU-ID, to
               identify the destination VCLC_SAP. The De-Encapsulation
               Function utilizes the E_UNITDATA.indication primitive to
               deliver the E_SDUs to the Encapsulation service user located
               at the VCLC_SAP. As an option, the De-Encapsulation Function
               may check the Packet Sequence Count in the E_PDU and notify
               the user of missing data via the E_SDU Data Loss parameter.

5.3.8.1.2      MULTIPLEXING PROCEDURES

5.3.8.1.2.a    The Multiplexing Procedures are composed of a "Multiplexing
               Function" and a "Demultiplexing Function". The Multiplexing
               Function provides an internal VCLC interface to the
               Encapsulation Function and an M_UNITDATA.request service
               primitive interface to the VCLC user. The Demultiplexing
               Function provides an internal VCLC interface to the De-
               Encapsulation Function and an M_UNITDATA.indication service
               primitive interface to the VCLC user.

5.3.8.1.2.1    MULTIPLEXING FUNCTION

5.3.8.1.2.1.a  The Multiplexing Function is used to multiplex E_PDUs and
               M_SDUs together into an M_PDU for transfer. The E_PDUs are
               received from the Encapsulation Procedures. The M_SDUs are
               received in M_UNITDATA.request primitives.

5.3.8.1.2.1.b  The Multiplexing Function constructs separate M_PDUs for
               each VC as identified by the VCDU-ID parameter. The M_PDU is
               fixed length for any VC.  Its length is specified by
               management to match the data-carrying space of the VC_PDU.

5.3.8.1.2.1.c  M_PDUs are constructed by concatenating E_PDUs and M_SDUs
               together until the maximum M_PDU length is exceeded. Any
               E_PDU or M_SDU which exceeds the maximum M_PDU length is
               split, filling the M_PDU completely, and starting a new
               M_PDU with the remainder. Construction of the next M_PDU
               continues with the concatenation of E_PDUs and M_SDUs until
               it overflows.

5.3.8.1.2.1.d  An M_PDU "First Header Pointer" field is set by the
               Multiplexing Function to indicate the location of the first
               octet of the first E_PDU or M_SDU header occurring within
               the data field of the M_PDU.

5.3.8.1.2.1.e  The Multiplexing Function may generate "fill" data in the
               absence of sufficient SDUs being supplied from the users
               above. The mechanism for generating fill is to create a
               Version-1 CCSDS Packet of appropriate length for insertion
               into the M_PDU which contains a PCID (i.e., APID) set to the
               reserved "Fill Packet" value of "all ones". The shortest
               Fill Packet is 7-octets long (i.e., a 6-octet header plus 1
               octet of fill data). If the area to be filled in an M_PDU is
               less than 7-octets, then the Fill Packet will spill over
               into the beginning of the next M_PDU.

5.3.8.1.2.1.f  The Multiplexing Function uses the VCA service of the VCA
               sublayer. The Grade of Service is defined by management for
               the VC being used.

5.3.8.1.2.2    DEMULTIPLEXING FUNCTION

5.3.8.1.2.2.a  The Demultiplexing Function is used to extract E_PDUs and
               M_SDUs from M_PDUs, and to deliver them to either the De-
               Encapsulation Function or to the Multiplexing service users.

5.3.8.1.2.2.b  The M_PDU First Header Pointer field is used in conjunction
               with the Length field of each data unit (i.e., CCSDS Packet)
               contained within the M_PDU to provide the delimiting
               information needed to extract the data unit. If the last
               data unit removed from the M_PDU is incomplete, the
               Demultiplexing Function retrieves its remainder from the
               beginning of the next M_PDU received on the same VC. The
               M_PDU First Header Pointer in the next M_PDU is used to
               determine the length of the remainder, and hence the
               beginning of the next data unit to be extracted.

5.3.8.1.2.2.c  If the calculated location of the beginning of the first
               M_SDU or E_PDU is not consistent with the location indicated
               by the M_PDU First Header Pointer, the Demultiplexing
               Function shall assume that the First Header Pointer is
               correct, and shall continue the demultiplexing based on that
               assumption.

5.3.8.1.2.2.d  Incomplete M_SDUs or E_PDUs are not required to be delivered
               in cross support situations.

5.3.8.1.2.2.e  Extracted data units are delivered to the De-Encapsulation
               Procedures or to the Multiplexing service users on the basis
               of the PCID field in their header.

5.3.8.1.2.2.f  Data units with PCIDs reserved for Encapsulation service
               users are delivered to the De-Encapsulation Procedures
               across a local VCLC interface. The Demultiplexing Function
               does not check the sequence of the E_PDUs prior to delivery.

5.3.8.1.2.2.g  Data units which have user PCIDs are delivered, with a
               M_UNITDATA.indication, to the Multiplexing service user
               identified by the combination of the PCID and the VCDU-ID.
               The Demultiplexing Function does not check the sequence of
               the M_SDUs prior to delivery.

5.3.8.1.2.2.h  Data units with the reserved PCIDs indicating a Fill Packet
               are discarded.

5.3.8.1.3      BITSTREAM PROCEDURES

5.3.8.1.3.a    The Bitstream Procedures provide a "B_PDU Construction
               Function" for the Bitstream service request primitive, and a
               "Bitstream Extraction Function" for the Bitstream service
               indication primitive.

5.3.8.1.3.1    B_PDU CONSTRUCTION FUNCTION

5.3.8.1.3.1.a  The B_PDU Construction Function is used to fill the data
               field of the B_PDU with the Bitstream Data supplied in
               BITSTREAM.request primitives. Each B_PDU contains data for
               only one VC, identified by the VCDU-ID parameter. Each bit
               is placed sequentially, and unchanged, into the B_PDU data
               field.

5.3.8.1.3.1.b  The B_PDU is fixed length for any VC; its length is
               specified by management to match the data-carrying space of
               the VC_PDU. When the Bitstream Data have filled one
               particular B_PDU, the continuation of the Bitstream Data is
               placed in the next B_PDU on the same VC.

5.3.8.1.3.1.c  If, due to the constraints of the PDU release algorithm, a
               B_PDU is not completely filled by Bitstream Data at release
               time, the B_PDU Construction Function will fill the
               remainder of the B_PDU with a locally specified fill
               pattern. The boundary between the end of the valid user data
               and the beginning of the fill data is indicated by setting a
               "Bitstream Data Pointer" in the B_PDU header.

5.3.8.1.3.1.d  The B_PDU Construction Function uses the VCA service of the
               VCA sublayer for data transfer. The choice of the Grade of
               Service is defined by management for the VC being used.

5.3.8.1.3.2    BITSTREAM EXTRACTION FUNCTION

5.3.8.1.3.2.a  The Bitstream Extraction Function is used to extract
               Bitstream Data from B_PDUs. The B_PDU is the SDU parameter
               received from the VCA sublayer. The extracted Bitstream Data
               are delivered to the Bitstream service user identified by
               the VCDU-ID parameter. Any fill data inserted by the B_PDU
               Construction Function are removed and discarded prior to
               delivery, using the Bitstream Data Pointer information.

5.3.8.1.3.2.b  The Bitstream Extraction Function may optionally pass a
               Bitstream Data Loss Flag to the user of the Bitstream
               service as a parameter; the flag is derived from the VCDU
               Loss Flag received from the VCA sublayer.

5.3.8.1.3.2.c  If used, the Bitstream Data Loss Flag indicates to the user
               that an indeterminate amount of data may have been lost
               between the instance of the BITSTREAM.indication primitive
               with which the Flag is associated and the previous instance
               of the BITSTREAM.indication primitive.  Note that if the
               Bitstream Data Loss Flag is set, and (one or more)
               subsequent B_PDUs are discarded because they contain only
               fill data, then the Flag must remain set until the next
               valid B_SDU is delivered to the user.  As the contents
               (valid or fill data) of lost B_PDUs cannot be established,
               the user should be aware that the Bitstream Data Loss Flag
               signals a disruption in the Bitstream Protocol Data Units,
               and not necessarily a disruption of the Bitstream itself.

5.3.8.2        STRUCTURE AND ENCODING OF VCLC_PDUs

5.3.8.2.a      The VCLC_PDU may be either a Multiplexing PDU (M_PDU) or a
               Bitstream PDU (B_PDU).  The M_PDU may contain Encapsulation
               PDUs (E_PDUs).

5.3.8.2.1      FORMAT OF THE ENCAPSULATION PROTOCOL DATA UNIT

5.3.8.2.1.a    The Encapsulation Procedures accept variable-length,
               delimited, octet-aligned E_SDUs from the Encapsulation
               service interface and encapsulate each of them within a
               variable-length Encapsulation Protocol Data Unit (E_PDU).
               The E_PDU uses the format of the Version-1 CCSDS Packet. Its
               structure is shown in Figure 5-4.


                                  [IMAGE]

               Figure 5-4:  Encapsulation Protocol Data Unit


5.3.8.2.1.b    The utilization of the fields within the E_PDU is as
               follows.

5.3.8.2.1.1    VERSION (Bits 0 through 2)

5.3.8.2.1.1.a  The three Version bits shall be set to value "000",
               indicating a Version-1 CCSDS Packet.

5.3.8.2.1.2    TYPE (Bit 3)

5.3.8.2.1.2.a  The Type bit is not used. It may be set to value "0" or "1"
               at the discretion of the Project organization.

5.3.8.2.1.3    SECONDARY HEADER FLAG (Bit 4)

5.3.8.2.1.3.a  No requirements have been identified for a Secondary Header
               in the E_PDU. The Secondary Header Flag bit shall be set to
               value "0".

5.3.8.2.1.4    APPLICATION PROCESS ID/PACKET CHANNEL ID (Bits 5
               through 15)

5.3.8.2.1.4.a  The 11-bit Application Process ID/Packet Channel ID field
               identifies the Packet Channel that is being used for the
               flow of encapsulated data.

5.3.8.2.1.4.b  When the E_SDU contained in the User Data field of the
               Packet is an ISO 8473 Internet packet, this field shall be
               set to the reserved Packet Channel value of "all ones minus
               one".

5.3.8.2.1.4.c  The assignment of other reserved values of this field (see
               Table 5-4) for use by the Encapsulation service is an item
               for potential future extension of this document.

5.3.8.2.1.5    SEQUENCE FLAGS (Bits 16,17)

5.3.8.2.1.5.a  No requirements for segmentation of E_SDUs by the E_PDU have
               been identified. The two Sequence Flag bits shall therefore
               be set to value "11".

5.3.8.2.1.6    PACKET SEQUENCE COUNT (Bits 18 through 31)

5.3.8.2.1.6.a  The 14-bit Packet Sequence Count field shall contain a
               straight sequential count (modulo 16384) which numbers each
               E_PDU generated on each reserved Packet Channel. The count
               shall be incremented independently for each Packet Channel.

5.3.8.2.1.7    PACKET LENGTH (Bits 32 through 47)

5.3.8.2.1.7.a  The Packet Length field contains a sequential 16-bit binary
               count "C" of the length (in octets) of the E_PDU excluding
               the Primary Header. The field is a count of the total number
               of octets which occur in the E_PDU after the last bit of the
               Primary Header, expressed as follows:

                      C = { (number of octets) - 1 }

5.3.8.2.1.8    E_PDU DATA FIELD

5.3.8.2.1.8.a  The E_PDU Data field contains one E_SDU, whose length must
               be an integer number of octets up to a maximum of 65,536.

5.3.8.2.2      FORMAT OF THE MULTIPLEXING PROTOCOL DATA UNIT

5.3.8.2.2.a    The Multiplexing Procedures accept CCSDS Packets (E_PDUs or
               M_SDUs) respectively from the Encapsulation Procedures and
               the Multiplexing service interface, and multiplexes them
               into the Multiplexing Protocol Data Unit (M_PDU).

5.3.8.2.2.b    The length of the M_PDU is fixed by management for any
               particular Virtual Channel, since it is required to fit
               exactly within the fixed-length data space of the VC_PDU.
               Necessarily, the length of M_PDUs carried by a Virtual
               Channel which supports the Insert or SLAP procedures must
               take into account the fixed length of the optional Insert,
               and/or the optional SLAP, protocol control information. Once
               the various length parameters have been set by management,
               they are static.

5.3.8.2.2.c    The format of the M_PDU, which consists of an M_PDU Header
               followed by an M_PDU Packet Zone, is shown in Figure 5-5.

5.3.8.2.2.d    The utilization of the fields within the M_PDU is as
               follows:


                                  [IMAGE]

            Figure 5-5:  Multiplexing Protocol Data Unit, M_PDU

5.3.8.2.2.1    SPARE (Bits 0-4)

5.3.8.2.2.1.a  The five-bit Spare field is currently undefined by CCSDS; by
               convention, it shall therefore be set to the reserved value
               of "00000".

5.3.8.2.2.2    FIRST HEADER POINTER (Bits 5-15)

5.3.8.2.2.2.a  The purpose of the First Header Pointer field is to
               facilitate delimiting of variable-length SDUs contained
               within the M_PDU Packet Zone, by pointing directly to a
               known reference location within the first SDU from which its
               length may be determined. The SDUs within the M_PDU may be
               either E_PDUs or M_SDUs, both of which are formatted as
               Version-1 CCSDS Packets.

5.3.8.2.2.2.b  Length delimiting is used to determine where the boundaries
               of the CCSDS Packets occur within the M_PDU Packet Zone.
               Packets may "spill over" into the Packet Zone of the next
               consecutive M_PDU on a particular Virtual Channel.

5.3.8.2.2.2.c  This 11-bit field contains a binary count "P" (modulo 2048)
               which, when incremented by "1", points directly to the
               number of the octet within the M_PDU Packet Zone (starting
               at octet number one, which begins at the first bit of the
               Packet Zone) that contains the first octet of the first
               CCSDS Packet header. The count "P" is expressed as:

                     P = { (Number of the octet) - 1 }

5.3.8.2.2.2.d  If the M_PDU Packet Zone contains CCSDS Packet data but no
               Packet header exists within the Zone, the First Header
               Pointer shall be set to value "all ones". This situation may
               occur if a long Packet spills over across more than one
               M_PDU.

5.3.8.2.2.2.e  If the M_PDU Packet Zone does not contain any valid user
               data (i.e., it contains a fill pattern) the First Header
               Pointer shall be set to value "all ones minus one".

5.3.8.2.2.2.f  Since CCSDS Packets may start at any octet boundary within
               the M_PDU Packet Zone, it is possible that a Packet header
               may be split between successive M_PDUs on one Virtual
               Channel. The rules for handling this situation are as
               follows:

5.3.8.2.2.2.g  if the first CCSDS Packet header starts at the end of the
               Packet Zone within M_PDU (x) and spills over into M_PDU
               (x+1) on that Virtual Channel, the First Header Pointer in
               M_PDU (x) shall be set to indicate the start of this Packet
               header;

5.3.8.2.2.2.h  if any CCSDS Packet header is split between M_PDUs (x) and
               (x+1) on that Virtual Channel, the First Header Pointer in
               M_PDU (x+1) ignores the residue of the split Packet Header,
               and shall only be set to indicate the start of any
               subsequent new CCSDS Packet header within M_PDU (x+1).

5.3.8.2.2.3    M_PDU PACKET ZONE (integral number of octets)

5.3.8.2.2.3.a  The M_PDU Packet Zone is a fixed number of octets in length
               and contains the variable-length E_PDUs or M_SDUs, formatted
               as Version-1 CCSDS Packets. The first and last Packets of
               the M_PDU are not necessarily complete, since the first
               CCSDS Packet may be a continuation of a Packet begun in the
               previous M_PDU and the last CCSDS Packet may continue in the
               subsequent M_PDU.

5.3.8.2.2.3.b  In the event that it is necessary to insert a "fill" Packet,
               a Version-1 CCSDS Packet of appropriate length shall be
               generated which has the following characteristics:

          Version:            "000"
          Type:               Not used; set to either "0" or "1".
          Sec. Header Flag:   "0"
          APID:               "All ones"
          Sequence Flags:     "11" (unsegmented)
          Sequence Count:     "All zeros"
          Packet Length:      The value of this field is a binary count of
                              the exact number of octets in the User Data
                              field of the Fill Packet, minus one.
          User Data Field:    A Project-specified fill pattern, which must
                              be an integral number of octets, shall be
                              inserted.


5.3.8.2.3      FORMAT OF THE BITSTREAM PROTOCOL DATA UNIT

5.3.8.2.3.a    The Bitstream Procedures accept Bitstream Data from the
               Bitstream service interface and generate the Bitstream
               Protocol Data Unit (B_PDU).

5.3.8.2.3.b    The length of the B_PDU is fixed by management for any
               particular Virtual Channel, since it is required to fit
               exactly within the fixed-length data space of the VC_PDU.
               Necessarily, the length of B_PDUs carried by a Virtual
               Channel which supports the Insert or SLAP procedures must
               take into account the fixed length of the Insert, SLAP
               protocol control information, and Reed-Solomon Check Symbols
               field if the associated options are selected. Once the
               various length parameters have been set by management, they
               are static.

5.3.8.2.3.c    The format of the B_PDU, which consists of a B_PDU Header
               followed by a B_PDU Bitstream Data Zone, is shown in Figure
               5-6.

                                  [IMAGE]

             Figure 5-6:  Bitstream Protocol Data Unit, B_PDU


5.3.8.2.3.d    The utilization of the fields within the B_PDU is as
               follows:

5.3.8.2.3.1    SPARE (Bits 0,1)

5.3.8.2.3.1.a  The Spare field is currently undefined by CCSDS: by
               convention, it shall therefore be set to the reserved value
               of "00".

5.3.8.2.3.2    BITSTREAM DATA POINTER (Bits 2-15)

5.3.8.2.3.2.a  Because it may be necessary to insert fill data if an
               insufficient number of Bitstream Data bits have been
               received before a B_PDU is released for transmission, the
               Bitstream Data Pointer indicates the location of the last
               valid user data bit within B_PDU Bitstream Data Zone (i.e.,
               the boundary between user data and any inserted fill).

5.3.8.2.3.2.b  This 14-bit field contains a binary count "B" (modulo 16384)
               which, when incremented by "1", points directly to the
               number of the last valid user data bit within the B_PDU
               Bitstream Data Zone (starting at bit number one, which is
               the first bit within the Bitstream Data Zone). The count "B"
               is expressed as:

                      B = { (Number of the bit) - 1 }

5.3.8.2.3.2.c  If there are no fill data in the Bitstream Data Zone (i.e.,
               the B_PDU contains only valid user data), the Bitstream Data
               Pointer shall be set to the value "all ones".

5.3.8.2.3.2.d  If there are no valid user data in the Bitstream Data Zone
               (i.e., the B_PDU contains only fill), the Bitstream Data
               Pointer shall be set to the value "all ones minus one".

5.3.8.2.3.3    B_PDU BITSTREAM DATA ZONE

5.3.8.2.3.3.a  The Bitstream Data Zone contains either a fixed-length block
               of the user Bitstream Data (possibly terminated with fill
               data at a location delimited by the Bitstream Data Pointer),
               or a fixed-length Project-specified fill pattern.


5.4  VIRTUAL CHANNEL ACCESS SUBLAYER

5.4.1   OVERVIEW

5.4.1.a This section contains the service and protocol specifications for
        the Virtual Channel Access sublayer. The VCA sublayer performs
        time division multiplexing between the asynchronous VCLC sublayer
        and the synchronous Physical Channel layer.


5.4.2   INTERNAL ORGANIZATION OF THE VCA SUBLAYER

5.4.2.a The addressing mechanism at the Virtual Channel Data Unit and VCA
        service interfaces to the VCA sublayer is the CCSDS Virtual
        Channel identified by the VCDU-ID, which is a concatenation of
        Spacecraft ID and Virtual Channel ID.  The VCDU-IDs are bound by
        management at the transmitting end of a data link to one or more
        PCA_PDUs.  Although multicasting of a virtual channel through
        multiple PCA_PDUs is permitted if the VCDU size is the same for
        all of the relevant PCA_PDUs and Insert service is not present in
        any of those PCA_PDUs, multiplexing of a virtual channel across
        multiple PCA_PDUs is forbidden.

5.4.2.b The addressing mechanism at the Insert service interface to the
        VCA sublayer is the LinkID.

5.4.2.c The internal organization of the VCA sublayer is shown in Figure 5-
        7.

5.4.3   SERVICES PROVIDED BY THE VCA SUBLAYER

5.4.3.a The VCA sublayer provides three services:

5.4.3.b    a "VCA service" provides transfer of VCA_SDUs across the
           Physical Channel. The VCA service is used by the VCLC sublayer
           and is exposed as an SLS service.  Internal to the VCA
           sublayer, an option exists to transfer VCA_SDUs across the
           Physical Channel using a retransmission control procedure known
           as a "Space Link ARQ Procedure" (SLAP);

5.4.3.c    an "Insert service" may be used at low transmitted data rates
           (see Reference [8]) to provide isochronous transfer of fixed-
           length IN_SDUs across the Physical Channel. The Insert service
           concurrently uses the same VCs as the other services;

                                  [IMAGE]

          Figure 5-7:  Internal Organization of the VCA Sublayer


5.4.3.d    a "Virtual Channel Data Unit service" provides transfer of user-
           generated validated VC_PDUs (VCDUs or CVCDUs) across the
           Physical Channel.

5.4.3.e In view of complex interactions with internal VCA error control,
        the Virtual Channel Data Unit service and Insert service shall not
        be simultaneously active on a particular Physical Channel.

5.4.3.f The types of data transfer services that are supported are as
        follows:

5.4.3.g    a VCA_SDU and/or an IN_SDU may be transferred using a VC_PDU
           which does not incorporate Reed-Solomon coding (i.e., a VCDU),
           thus providing SLS "Grade-3" service. The VCA_SDU may not be an
           M_PDU if Grade-3 service is used;

5.4.3.h    a VCA_SDU and/or an IN_SDU may be transferred using a VC_PDU
           which incorporates Reed-Solomon coding (i.e., a CVCDU), thus
           providing SLS "Grade-2" service;

5.4.3.i    a VCA_SDU may be transferred using a VC_PDU which incorporates
           Reed-Solomon coding plus the SLAP retransmission protocol, thus
           providing SLS "Grade-1" service;

5.4.3.j    a user-generated VC_PDU may be transferred which itself
           internally supports either Grade-1, Grade-2 or Grade-3 service
           across the SLS.


5.4.4          VCA SERVICES ASSUMED FROM THE PHYSICAL CHANNEL LAYER

5.4.4.a        The "Physical Channel Service" required from the Physical
               Channel layer is the capability to transfer channel bits
               from point to point or point to multipoint across the Space
               Link Subnet. Multiplexing of a VCA, VCDU, or Insert service
               across multiple Physical Channels is not permitted, though
               this does not preclude the multicasting of a Virtual Channel
               over multiple Physical Channels.

5.4.4.b        The service primitives are:

                              PC_UNITDATA.request (channel bit)
                              PC_UNITDATA.indication   (channel bit)


5.4.5          VCA SERVICES ASSUMED FROM THE LOCAL ENVIRONMENT

5.4.5.a        The services assumed from the local environment are
               unspecified.


5.4.6          VCA SERVICE INTERFACE SPECIFICATION

5.4.6.a.       This section specifies the services provided by the CCSDS
               Virtual Channel Access sublayer. The services described do
               not imply any particular implementation.

5.4.6.1        OVERVIEW OF INTERACTIONS

5.4.6.1.1      VCA SERVICE

5.4.6.1.1.a    The VCA service is used to transfer VCA_SDUs across the
               Space Link Subnet. The VCA service user accesses the
               sublayer at the VCA_SAP identified by the VCDU-ID. The VCA
               sublayer entity constructs VC_PDUs (VCDUs or CVCDUs) from
               VCA_SDUs, optionally (if Grade-1 service is requested)
               invoking the internal SLAP procedures to add the SLAP
               protocol. It serializes the VC_PDUs, delimits them using
               Synchronization Markers, and transmits them using the
               services of the Physical Channel layer.

5.4.6.1.1.b    The service primitives associated with this service are:

               VCA_UNITDATA.request
               VCA_UNITDATA.indication

5.4.6.1.1.c    The VCA_UNITDATA.request primitive is passed to the Virtual
               Channel Access sublayer to request that a VCA_SDU be sent.

5.4.6.1.1.d    The VCA_UNITDATA.indication primitive is passed from the
               Virtual Channel Access sublayer to indicate the arrival of a
               VCA_SDU.

5.4.6.1.2      INSERT SERVICE

5.4.6.1.2.a    The Insert service is used to transfer isochronous Insert
               SDUs (IN_SDUs) by carrying them within an Insert field that
               is placed into every transmitted VC_PDU. The
               presence/absence and length of the Insert field is set by
               management. The service requires isochronous IN_SDUs to be
               of fixed length on all Virtual Channels; their length may be
               of any constant value which is an integral number of octets,
               between 1 octet and the maximum length of the data-carrying
               space of the VC_PDU.

5.4.6.1.2.b    There are two service primitives associated with this
               service:

               INSERT.request
               INSERT.indication

5.4.6.1.2.c    The INSERT.request primitive is passed to the VCA sublayer
               to request that an IN_SDU be sent.

5.4.6.1.2.d    The INSERT.indication is used by the VCA sublayer to
               indicate the arrival of an IN_SDU.

5.4.6.1.3      VIRTUAL CHANNEL DATA UNIT SERVICE

5.4.6.1.3.a    The Virtual Channel Data Unit service is used by a trusted
               VCA sublayer user (i.e., an independent VCA sublayer entity
               which has been certified during the design process to meet
               Project-specified reliability and safety criteria) to
               transfer preformatted VCDUs or CVCDUs across the Space Link
               Subnet. The trusted VCA sublayer user accesses the VCA
               sublayer at the VCA_SAP identified by the VCDU-ID; this SAP
               is bound by management to use the same Physical Channel
               service as the VCA sublayer. The VCA sublayer multiplexes
               the user-generated VC_PDUs (VCDUs/CVCDUs) with the
               VCDUs/CVCDUs generated by itself, delimits them using
               Synchronization Markers, and transmits them using the
               services of the Physical Channel layer.

5.4.6.1.3.b    The service primitives associated with this service are:

               VCA_VCDU.request
               VCA_VCDU.indication

5.4.6.1.3.c    The VCA_VCDU.request primitive is passed to the Virtual
               Channel Access sublayer by the trusted sublayer user to
               request that a VCDU or CVCDU be sent.

5.4.6.1.3.d    The VCA_VCDU.indication primitive is passed from the Virtual
               Channel Access sublayer to the trusted sublayer user to
               indicate the arrival of a VCDU or CVCDU.

5.4.6.2        VCA SERVICE PRIMITIVE PARAMETERS

5.4.6.2.a      The parameters for the VCA primitives are described below.
               Unique uses of these parameters by any primitive are
               described in the Additional Comments section in the detailed
               description of that primitive.

5.4.6.2.b  VCA_SDU       VCA Service Data Unit. A VCA_SDU is the service
                         data unit passed to and from users of the VCA
                         service on a particular VC.

5.4.6.2.c  IN_SDU        The Insert Service Data Unit.  An IN_SDU is the
                         service data unit passed to and from users of the
                         Insert service on all VCs. An IN_SDU is an
                         isochronous, octet-aligned data unit of fixed
                         length. Its length at the request (source)
                         interface is always equal to its length at the
                         indication (destination) interface.

5.4.6.2.d  SLAP_SDU      The SLAP Service Data Unit. A SLAP_SDU is a
                         special instance of a VCA_SDU, passed to and from
                         users of the VCA service on a VC which has been
                         assigned by management to support SLS Grade-1
                         service.

5.4.6.2.e  VCDU/         Virtual Channel Data Unit or Coded Virtual Channel
           CVCDU         Data Unit.  Within the Virtual Channel Data Unit
                         service, a VCDU/CVCDU  is the service data unit
                         which is passed between trusted peer VCA  sublayer
                         entities.

5.4.6.2.f  VCDU-ID       Virtual Channel Data Unit Identifier. The VCDU-ID
                         consists of a concatenation of the Spacecraft
                         Identifier (SCID) and the Virtual Channel
                         Identifier (VCID). It identifies the VCA_SAP and
                         therefore the SLS Grade of Service (Grade-1, Grade-
                         2, or Grade-3) associated with the transfer.

5.4.6.2.g  LinkID        The LinkID is used by the Insert service to
                         identify the PCA_PDU that contains the stream of
                         VC_PDUs which carry the IN_SDUs. Note that a
                         stream of VC_PDUs contained in a PCA_PDU may
                         include more than one SCID.

5.4.6.2.h  VCDU          The VCDU Loss Flag is used to notify the user at
                         the
           Loss          destination end of a VCA service that a sequence
                         discontinuity has been  Flag  detected and that
                         one or more VC_PDUs has been lost.  The  VCDU Loss
                         Flag is mandatory (in contrast to similar flags
                         provided by the Encapsulation and Bitstream
                         services) in  recognition of its importance in the
                         Multiplexing and Bitstream  procedures of the VCLC
                         layer.

5.4.6.2.i  Insert Data   The Insert Data Loss Flag is an optional parameter
           Loss Flag     which may be used to notify the user at the
                         destination end of the Insert service that one or
                         more CADUs has been lost

5.4.7       DETAILED VCA SERVICE SPECIFICATIONS

5.4.7.a     This section describes in detail the primitives and parameters
            associated with the VCA service, the Insert service, and the
            Virtual Channel Data Unit service.

5.4.7.b     The parameters, which are specified in an abstract sense,
            specify the information to be made available to the receiving
            entity. A specific implementation is not constrained in the
            method of making this information available.

5.4.7.1     VCA_UNITDATA.request

5.4.7.1.a   Function

            This primitive is the service request
            primitive for the VCA service.

5.4.7.1.b   Semantics

            The primitive shall provide parameters as
            follows:

            VCA_UNITDATA.request  (VCA_SDU,
                                   VCDU-ID)

5.4.7.1.c   When Generated

            This primitive is passed to the VCA sublayer
            to request it to send the VCA_SDU.

5.4.7.1.d   Effect on Receipt

            Receipt of this primitive causes the VCA
            sublayer to attempt to send the VCA_SDU.

5.4.7.1.e   Additional Comments

            None.


5.4.7.2     VCA_UNITDATA.indication

5.4.7.2.a   Function

            This primitive is the service indication
            primitive for the VCA service.

5.4.7.2.b   Semantics

            The primitive shall provide parameters as
            follows:

            VCA_UNITDATA.indication    (VCA_SDU,
                                        VCDU-ID,
                                        VCDU Loss Flag)

5.4.7.2.c   When Generated

            This primitive is passed from the VCA
            sublayer to the VCA sublayer user to indicate the arrival of a
            VCA_SDU.

5.4.7.2.d   Effect on Receipt

            The effect of receipt of this primitive by
            the VCLC layer is described in Section 5.3

5.4.7.2.e   Additional Comments

            The VCDU Loss Flag is used to signal a
            detected discontinuity in the sequence of VC_PDUs to the VCA
            service user.


5.4.7.3     INSERT.request

5.4.7.3.a   Function

            This primitive is the service request
            primitive for the Insert service.

5.4.7.3.b   Semantics

            The primitive shall provide parameters as
            follows:

            INSERT.request   (IN_SDU,
                              LinkID)

5.4.7.3.c   When Generated

            This primitive is passed to the VCA sublayer
            to request it to send the IN_SDU.

5.4.7.3.d   Effect on Receipt

            Receipt of this primitive causes the VCA
            sublayer to attempt to send the IN_SDU.

5.4.7.3.e   Additional Comments

            The LinkID indicates that the IN_SDU must be
            inserted into all VC_PDUs. The Insert service and the Virtual
            Channel Data Unit service are mutually exclusive on a
            particular Physical Channel.

5.4.7.4     INSERT.indication

5.4.7.4.a   Function

            This primitive is the service indication
            primitive for the Insert service.

5.4.7.4.b   Semantics

            The primitive shall provide parameters as
            follows:

            INSERT.indication(IN_SDU,
                              LinkID,
                              Insert Data Loss Flag [opt.])

5.4.7.4.c   When Generated

            This primitive is passed from the VCA
            sublayer to the Insert service user to indicate the arrival of
            an IN_SDU.

5.4.7.4.d   Effect on Receipt

            The effect of receipt of this primitive by
            the Insert service user is not specified.

5.4.7.4.e   Additional Comments

            The LinkID parameter indicates that the
            IN_SDU was transferred in "all" Virtual Channels. The optional
            Insert Data Loss Flag is used to signal a detected loss of one
            or more CADUs to the Insert service user.

5.4.7.5     VCA_VCDU.request

5.4.7.5.a   Function

            This primitive is the service request
            primitive for the Virtual Channel Data Unit service.

5.4.7.5.b   Semantics

            The primitive shall provide parameters as
            follows:

            VCA_VCDU.request (VCDU/CVCDU,
                              VCDU-ID)

5.4.7.5.c   When Generated

            This primitive is passed to the VCA sublayer
            to request it to send the VCDU or CVCDU.

5.4.7.5.d   Effect on Receipt

            Receipt of this primitive causes the VCA
            sublayer to attempt to send the VCDU or CVCDU.

5.4.7.5.e   Additional Comments

            The Virtual Channel Data Unit service and the
            Insert service are mutually exclusive on a particular Physical
            Channel.

5.4.7.6     VCA_VCDU.indication

5.4.7.6.a   Function

            This primitive is the service indication
            primitive for the Virtual Channel Data Unit service.

5.4.7.6.b   Semantics

            The primitive shall provide parameters as
            follows:

            VCA_VCDU.indication   (VCDU/CVCDU,
                                   VCDU-ID)

5.4.7.6.c   When Generated

            This primitive is passed from the VCA
            sublayer to the VCA sublayer user to indicate the arrival of a
            VCDU or CVCDU.

5.4.7.6.d   Effect on Receipt

            The effect of receipt of this primitive by
            the VCA sublayer user is not specified.

5.4.7.6.e   Additional Comments

            None.

5.4.8       INTERNAL VCA INTERFACE TO THE SLAP PROCEDURES

5.4.8.a     The SLAP procedures, although completely contained within the
            VCA sublayer, are sufficiently complex and detailed that they
            are described separately in Section 6 of this Recommendation.
            For this reason an unambiguous interface to the SLAP
            procedures is defined here.

5.4.8.b     The architecture of the SLAP interfaces is shown in Figure 5-
            8.


                                  [IMAGE]

            Figure 5-8:  Internal VCA Interfaces with the SLAP
5.4.8.c     The services assumed from the SLAP consist of the primitives:

            SLAP_DATA.request
            SLAP_DATA.indication

5.4.8.d     Services presented to the SLAP are those of the VCA sublayer,
            and at the VCA service interface consist of the primitives:

            VCA_UNITDATA.request
            VCA_UNITDATA.indication

5.4.8.1     SERVICES ASSUMED FROM THE SLAP PROCEDURES

5.4.8.1.1   SLAP_DATA.request

5.4.8.1.1.a Function

            This primitive is the service request primitive for the SLAP
            service.

5.4.8.1.1.b Semantics

            The primitive shall provide parameters as follows:

            SLAP_DATA.request(SLAP_SDU,
                              VCDU-ID)

5.4.8.1.1.c When Generated

            This primitive is passed to the SLAP procedures to send the
            SLAP_SDU.

5.4.8.1.1.d Effect on Receipt

            Receipt of this primitive causes the SLAP procedures to send
            the SLAP_SDU.

5.4.8.1.1.e Additional Comments

            The SLAP_SDU is the VCA_SDU on a VC assigned by management to
            support SLS Grade-1 service. The SLAP_SAP is defined by the
            VCDU-ID.

5.4.8.1.2   SLAP_DATA.indication

5.4.8.1.2.a Function

            This primitive is the service indication primitive for the
            SLAP service.

5.4.8.1.2.b Semantics

            The primitive shall provide parameters as follows:

            SLAP_DATA.indication  (SLAP_SDU,
                                   VCDU-ID)

5.4.8.1.2.c When Generated

            This primitive is passed from the SLAP to the VCA sublayer
            user on a particular Grade-1 VC to indicate the arrival of a
            SLAP_SDU.

5.4.8.1.2.d Effect on Receipt

            The effect of receipt of this primitive by the VCA sublayer
            user is unspecified.

5.4.8.1.2.e Additional Comments

            The SLAP_SDU is the VCA_SDU on a VC assigned by management to
            support SLS Grade-1 service. The SLAP_SAP is defined by the
            VCDU-ID.

5.4.8.2     SERVICES PRESENTED TO THE SLAP PROCEDURES

5.4.8.2.a   The services presented to the SLAP procedures are those at the
            VCA service interface. The SLAP has its own numbering
            mechanism and is therefore independent of the sequencing of
            VC_PDUs.


5.4.9       VIRTUAL CHANNEL ACCESS PROTOCOL SPECIFICATION

5.4.9.1     VCA PROTOCOL PROCEDURES

5.4.9.1.a   The VCA sublayer is composed of three sets of protocol
            procedures: "SLAP Procedures"; "Virtual Channel Procedures";
            and "Channel Access Procedures".

5.4.9.1.b   The internal functional organization of the SLAP Procedures is
            described in Section 6 of this Recommendation and is therefore
            not discussed here.

5.4.9.1.c   The Virtual Channel Procedures and Channel Access Procedures
            are internally organized to support the functions illustrated
            in Figure 5-9.


                                  [IMAGE]

             Figure 5-9:  VCA Internal Functional Organization


5.4.9.1.1      VIRTUAL CHANNEL PROCEDURES

5.4.9.1.1.a    The protocol data unit of the Virtual Channel Procedures is
               the VC_PDU, which is implemented using the CCSDS Virtual
               Channel Data Unit (VCDU) data structure. A VC_PDU is
               composed of a VCDU Primary Header, an optional VCDU Insert
               Zone, a VCDU Data Unit Zone, and an optional VCDU Trailer.

5.4.9.1.1.b    The Virtual Channel Procedures accept service data units and
               build them into VC_PDUs for transmission at the sending VCA
               sublayer entity, and extract and deliver the service data
               units at the receiving VCA sublayer entity. The procedures
               are composed of a "VCDU Assembly Function" and a "VCA_SDU
               Extraction Function".

5.4.9.1.1.1    VCDU ASSEMBLY FUNCTION

5.4.9.1.1.1.a  The VCDU Assembly Function is used to build the structure
               and Primary Header of the VCDUs for transmission on each
               Virtual Channel, using VCA_SDUs (or SLAP_PDUs if the VC
               supports Grade-1 service) which are each received in a
               VCA_UNITDATA.request primitive. There is one VCDU Assembly
               Function per Virtual Channel.

5.4.9.1.1.1.b  VCDUs are assembled by placing a single VCA_SDU or SLAP_PDU,
               unchanged, into the VCDU Data Unit Zone, and generating the
               VCDU Primary Header fields. The length of the VCA_SDU or
               SLAP_PDU must be equal to the length of the Data Unit Zone
               for the Virtual Channel identified by the VCDU-ID.

5.4.9.1.1.1.c  A VCDU-ID field is generated and placed into the Primary
               Header. A sequential count is generated independently for
               each VC and placed into the Primary Header.

5.4.9.1.1.2    VCA_SDU EXTRACTION FUNCTION

5.4.9.1.1.2.a  The VCA_SDU Extraction Function extracts VCA_SDUs from the
               VCDUs, and delivers them on individual Virtual Channels to
               users of the VCA service at VCA_SAPs defined by the VCDU-ID.
               An extracted VCA_SDU (which may, for Grade-1 service, be a
               SLAP_PDU) is delivered in a VCA_UNITDATA.indication
               primitive. There is one VCA_SDU Extraction Function per
               Virtual Channel.

5.4.9.1.2      CHANNEL ACCESS PROCEDURES

5.4.9.1.2.a    The Channel Access Procedures provide the multiplexing
               functions necessary to switch all of the individual Virtual
               Channels together for commutation into one PCA_PDU. They
               also provide the error-control functions in support of the
               different SLS Grades of Service, and the isochronous
               formatting functions in support of the Insert service. There
               is one Channel Access Procedural entity for each PCA_PDU.

5.4.9.1.2.b    In support of Grade-1/2 service, a VC_PDU may be error
               protected, using the Reed-Solomon encoding scheme, in which
               case it is transformed internally and becomes a CCSDS Coded
               Virtual Channel Data Unit (CVCDU) data structure.

5.4.9.1.2.c    The VC_PDUs are transmitted through the Physical Channel as
               a serial string of VCDUs and/or CVCDUs; the boundaries
               between them are delimited by attaching a Synchronization
               Marker to each VCDU/CVCDU. One individual VCDU/CVCDU,
               prefixed by its attached Synchronization Marker, is a CCSDS
               Channel Access Data Unit (CADU).

5.4.9.1.2.d    The protocol data unit of the Channel Access Procedures is
               the PCA_PDU, which is a serial stream of bits representing a
               continuous and contiguous stream of CADUs.  The PCA_PDU is
               named by the LinkID.

5.4.9.1.2.e    The Channel Access Procedures are composed of ten internal
               functions: a "VCDU Commutation Function"; a "Fill Generation
               Function"; an "Error Control Encoding Function"; an "Insert
               Injection Function"; a "Delimiting Function"; a
               "Synchronization Function"; an "Insert Extraction Function";
               an "Error Control Decoding Function"; a "VCDU Decommutation
               Function"; and a "Fill Removal Function".

5.4.9.1.2.1    VCDU COMMUTATION FUNCTION

5.4.9.1.2.1.a  There is one VCDU Commutation entity for each PCA_PDU. The
               VCDU Commutation entity generates a queue of VCDUs (received
               from either the Virtual Channel Procedures or from the
               Virtual Channel Data Unit service interface) for commutation
               into the PCA_PDU in an appropriate order that is set by
               management. If necessary to preserve the continuity of the
               transmitted stream, the VCDU Commutation Function requests
               "Fill" VCDUs from the Fill Generation Function.

5.4.9.1.2.1.b  The Virtual Channel Data Unit service interface supports
               externally generated VC_PDUs: these may be either VCDUs or
               CVCDUs, as specified by management. They are passed in a
               VCA_VCDU.request primitive.

5.4.9.1.2.1.c  The algorithm to be used to order the VC_PDUs is not
               specified by CCSDS, but is defined by Project organizations
               considering factors such as priority, release rate,
               isochronous timing requirements, etc.

5.4.9.1.2.2    FILL GENERATION FUNCTION

5.4.9.1.2.2.a  In the event that there are no valid VC_PDUs available for
               transmission at a release time that is established by the
               VCDU Commutation Function, the Fill Generation Function
               creates a Fill VCDU which has its VCID set to the reserved
               value of "all ones".  It is not required to maintain a
               sequential count for fill VCDUs.

5.4.9.1.2.3    ERROR CONTROL ENCODING FUNCTION

5.4.9.1.2.3.a  Under control of management, three optional error control
               fields may be generated by the Error Control Encoding
               Function and added to the VCDU, in support of different SLS
               Grades of Service:

5.4.9.1.2.3.b  A "VCDU Header Error Control" field may be added to the VCDU
               Primary Header to protect key header information.  This
               field is required in all VC_PDUs associated with Grade-3
               service, and in all VC_PDUs associated with Grade-1/2
               service where:  (1) the implementation of the receiving
               system is such that the Primary Header must be processed
               prior to Reed-Solomon decoding, and/or (2) the Insert Zone
               is present in a PCA_PDU which supports mixed Grade-3 and
               Grade-1/2 service.  (Note:  in case (1) the requirement for
               VCDU Header Error Control is implementation dependent and is
               therefore the subject of local cross support agreements; in
               case (2) the presence of the VCDU Header Error Control field
               is required in order to equalize the length of the Primary
               Headers, so that Insert data may be extracted by the
               receiver before any decoding is performed.)

5.4.9.1.2.3.c  A cyclic redundancy code (CRC) "VCDU Error Control" field
               (using a polynomial which covers the entire VCDU) may be
               inserted into the VCDU Trailer. This field is required in
               all VC_PDUs associated with Grade-3 service.

5.4.9.1.2.3.d  A block of "Reed-Solomon Check Symbols" may be appended to
               the end of the VCDU, thus forming a CVCDU. This field is
               required in all VC_PDUs associated with Grade-1/2 service.

5.4.9.1.2.3.e  Since VCDUs and CVCDUs are always of the same fixed length
               in a particular PCA_PDU, the Data Unit Zone of a CVCDU is
               shortened (relative to a VCDU) by an amount equal to the
               length of the Reed-Solomon check symbols.

5.4.9.1.2.3.f  Externally generated VC_PDUs associated with the Virtual
               Channel Data Unit service will always bypass the Error
               Control Encoding Functions specified in 5.4.9.1.2.3.b and
               5.4.9.1.2.3.c.  The Virtual Channel Data Unit service user
               must therefore ensure that the VC_PDUs contain an error
               encoding option which conforms with that implemented by the
               supporting SLS element(s).  However, it is permissible for
               Virtual Channel Data Unit service users to supply VCDUs to a
               supporting SLS element for conversion to CVCDUs, providing
               that the user shortens their length to accommodate the
               addition of the Reed-Solomon check symbols.

5.4.9.1.2.4    INSERT INJECTION FUNCTION

5.4.9.1.2.4.a  When the optional Insert service is activated, a fixed-
               length Insert Zone exists in every VC_PDU (VCDU/CVCDU) that
               is transmitted in a particular PCA_PDU (including Fill
               VC_PDUs). The Insert service and Virtual Channel Data Unit
               service may not be activated simultaneously.

5.4.9.1.2.4.b  The IN_SDUs are timed to arrive at a constant interval that
               corresponds to the release time of the VC_PDUs onto the
               Physical Channel. The Insert Injection function places the
               IN_SDU, received in an INSERT.request primitive, into the
               Insert Zone of the VC_PDU, preserving octet alignment.

5.4.9.1.2.4.c  The Insert Injection function shall be performed before the
               CRC and/or Reed-Solomon Error Control Encoding Functions.

5.4.9.1.2.5    BIT TRANSITION GENERATION FUNCTION (OPT.)

5.4.9.1.2.5.a  Adequate bit transition density must be ensured when the
               PCA_PDU is modulated directly onto the space channel. Some
               modulation schemes themselves provide the required
               transitions; however, if adequate bit transitions do not
               exist, a random sequence shall be exclusively ORed with each
               bit of the CADU, exclusive of the Synchronization Marker.
               Such a random sequence shall be generated using the
               following polynomial:

                      h(x) = x**8 + x**7 + x**5 + x**3 + 1

5.4.9.1.2.5.b  This sequence repeats after 255 bits and the sequence
               generator is re-initialized to an all-ones state during each
               Synchronization Marker period. The first 40 bits of the
               pseudonoise sequence are shown below; the left-most bit is
               the first bit of the sequence and is exclusively ORed with
               the first bit of the VCDU or CVCDU:

        1111  1111  0100  1000  0000  1110  1100  0000  1001  1010

5.4.9.1.2.5.c  If an inner convolutional coding scheme is implemented with
               alternate symbol inversion, there is no requirement to add
               the bit transition generator (but neither is it prohibited).
               Appropriate choice of a modulation technique could also
               obviate the need for a transition generator.  If the
               transition generator is implemented, then management
               provisions must necessarily be made to notify the receiving
               end of the link of its presence:  the LinkID provides this
               management association.

5.4.9.1.2.6    DELIMITING FUNCTION

5.4.9.1.2.6.a  VC_PDUs are submitted to the Delimiting Function at a data
               rate that is set by management; their transmitted sequence
               is determined by the VCDU Commutation Function.

5.4.9.1.2.6.b  The Delimiting Function creates the PCA_PDU, which is
               clocked out synchronously at the transmitted bit rate of the
               Physical Channel by prefixing a Synchronization Marker to
               each VC_PDU and thus forming a continuous and contiguous
               stream of CADUs. Each CADU occupies one synchronous time
               slot on the Physical Channel.

5.4.9.1.2.6.c  The PCA_PDU is submitted to the Physical Channel layer in
               the PC_UNITDATA.request primitive.

5.4.9.1.2.7    SYNCHRONIZATION FUNCTION

5.4.9.1.2.7.a  The PCA_PDU is received from the Physical Channel layer in a
               PC_UNITDATA.indication primitive. The Synchronization
               Function determines the boundaries of the fixed-length
               VC_PDU by recognition of the appended Synchronization Marker
               of the CADU. The Synchronization Marker is discarded once
               synchronization to the VC_PDU boundaries has been achieved.

5.4.9.1.2.8    BIT TRANSITION REMOVAL FUNCTION (IF NEEDED)

5.4.9.1.2.8.a  In the event that the optional Bit Transition Generation
               Function was performed by the transmitter, the Bit
               Transition Removal Function is activated at the receiving
               end (immediately after synchronization is achieved) to
               remove the randomization and restore the original data.

5.4.9.1.2.8.b  The Bit Transition Removal Function is activated as needed
               under control of management; i.e., the presence or absence
               of the randomizing sequence is one of the managed parameters
               which is ascribed by a particular LinkID.

5.4.9.1.2.9    INSERT EXTRACTION FUNCTION

5.4.9.1.2.9.a  When the optional Insert service is activated under control
               of management, the Insert Extraction Function extracts the
               IN_SDUs from the Insert Zones of the incoming stream of
               VC_PDUs, regardless of their VCDU-ID, and delivers each of
               them to the user of the Insert service in an
               INSERT.indication primitive. If error protection of the
               IN_SDUs is not required, this function may be performed
               prior to the Error Control Decoding Function.

5.4.9.1.2.10   ERROR CONTROL DECODING FUNCTION

5.4.9.1.2.10.a The operations performed by the Error Control Decoding
               Function vary according to the error coding techniques
               (i.e., VCDU Header Error Control, VCDU Error Control field,
               Reed-Solomon encoding) that are present in the received
               VC_PDUs.  The mechanism that the Error Control Decoding
               Function uses to determine which of the error coding
               techniques is present is dependent on the implementation of
               the receiving system.  There are a number of possible ways
               for a receiver to determine the error coding techniques that
               are in use in a particular PCA_PDU, using either management-
               supplied information, information deduced from the received
               VC_PDUs themselves, or a combination of both.  The rules for
               incorporating VCDU Error Control are discussed in Section
               5.4.9.1.2.3; note that the implementation of the receiving
               system may itself affect those rules.  The variety of
               options for processing PCA_PDUs with mixtures of error
               coding mechanisms is discussed further in Reference [8].

5.4.9.1.2.10.b If VCDU Header Error Control is present in the VC_PDU, the
               Error Control Decoding Function uses the content of the VCDU
               Header Error Control field to attempt to correct key
               elements of the VCDU Primary Header.  (Note that if Reed-
               Solomon error protection of the entire VC_PDU is also
               present, additional decoding of the VCDU Header Error
               Control is not required.)  A VC_PDU which contains detected
               and uncorrectable header errors is not required to be
               delivered in cross support situations.

5.4.9.1.2.10.c If the VCDU Error Control field is present in the VC_PDU,
               the Error Control Decoding Function recomputes the CRC value
               for the VCDU and compares it to the content of the VCDU
               Error Control field to determine if the VCDU contains a
               detected error.  (Note that if Reed-Solomon error protection
               of the entire VC_PDU is also present, additional decoding of
               the VCDU Error Control is not required.)  A VC_PDU which
               contains a detected error is not required to be delivered in
               cross support situations.

5.4.9.1.2.10.d If Reed-Solomon encoding is present in the VC_PDU (that is,
               the VC_PDU is a CVCDU), the Error Control Decoding Function
               uses the content of the Reed-Solomon Check Symbols field to
               attempt to correct the errors in the VC_PDU.  A VC_PDU which
               contains detected and uncorrectable errors is not required
               to be delivered in cross support situations.

5.4.9.1.2.10.e Externally generated VC_PDUs associated with the Virtual
               Channel Data Unit service use the Error Control Decoding
               Function only to the extent necessary to ensure the validity
               of their Primary Header routing information.  Such VC_PDUs
               containing detected and uncorrectable header errors are not
               required to be delivered in cross support situations.

5.4.9.1.2.11   VCDU DECOMMUTATION FUNCTION

5.4.9.1.2.11.a The VCDU Decommutation Function examines the VCDU-ID in the
               incoming stream of VC_PDUs and routes them to either the
               VCA_SDU Extraction Function, the Virtual Channel Data Unit
               service interface, or the Fill Removal Function. At the
               Virtual Channel Data Unit service interface, the VC_PDU is
               delivered in a VCA_VCDU.indication primitive.

5.4.9.1.2.12   FILL REMOVAL FUNCTION

5.4.9.1.2.12.a The Fill Removal Function recognizes "Fill" VCDUs by their
               unique VCID value of "all ones" and discards them.

5.4.9.2        STRUCTURE AND ENCODING OF VCA SUBLAYER PROTOCOL DATA UNITS

5.4.9.2.a      The protocol data units of the VCA sublayer are the Virtual
               Channel Protocol Data Unit (VC_PDU), the SLAP Protocol Data
               Unit (SLAP_PDU) and the Physical Channel Access Protocol
               Data Unit (PCA_PDU).

5.4.9.2.1      FORMAT OF THE VC_PDU

5.4.9.2.1.a    The VC_PDU is implemented using the CCSDS Virtual Channel
               Data Unit (VCDU). A VCDU is composed of a VCDU Primary
               Header, an optional VCDU Insert Zone, a VCDU Data Unit Zone,
               and an optional VCDU Trailer. In support of Grade-1/2
               service, a block of Reed-Solomon check symbols is internally
               appended to the VCDU to form a Coded Virtual Channel Data
               Unit (CVCDU). The structural relationships between the VCDU
               and CVCDU are shown in Figure 5-10.

                                  [IMAGE]

              Figure 5-10:  VCDU/CVCDU Structural Components


5.4.9.2.1.b    Since the VCDU and CVCDU have the same fixed length in a
               particular PCA_PDU, the Data Unit Zone of a CVCDU is
               shortened to accommodate the Reed-Solomon check symbols.

5.4.9.2.1.c    The detailed internal field allocation of the VCDU is shown
               in Figure 5-11.


5.4.9.2.1.1                                  VCDU PRIMARY HEADER

5.4.9.2.1.1.a    The VCDU Primary Header contains the following fields:

          Field:                              Length (bits):

          VERSION NUMBER                          2
          VCDU IDENTIFIER:                       14
          Spacecraft ID (8)
          Virtual Channel ID (6)
          VIRTUAL CHANNEL DATA UNIT COUNTER      24
          SIGNALLING FIELD                        8
          Replay Flag (1)
          Reserved Spares (7)
          VCDU HEADER ERROR CONTROL (optional): (16)

            The total length of the VCDU Primary Header is 48 or 64 bits,
            depending on whether the optional VCDU Header Error Control
            field is present.

                                  [IMAGE]

              Figure 5-11:  Virtual Channel Data Unit Format

5.4.9.2.1.1.1       VERSION NUMBER (Bits 0,1)

5.4.9.2.1.1.1.a     The two Version Number bits (which occupy the two most
                    significant bits of the VCDU Primary Header) are
                    reserved for identification of the VCDU structure. At
                    present two Versions are recognized:

5.4.9.2.1.1.1.b     Version-1 (Bits 0,1 = "00"): identifies the CCSDS
                    Telemetry Transfer Frame, specified in Reference [2];

5.4.9.2.1.1.1.c     Version-2 (Bits 0,1 = "01"): identifies the CCSDS
                    Virtual Channel Data Unit, specified herein.

5.4.9.2.1.1.1.d     The remainder of this document discusses only the
                    Version-2 structure. Note, however, that there is a
                    deliberate and close relationship between the Version-2
                    VCDU and the Version-1 Transfer Frame, which maximizes
                    the commonality between CCSDS Conventional Systems and
                    CCSDS Advanced Orbiting Systems.

5.4.9.2.1.1.2       VCDU IDENTIFIER (Bits 2 through 15)

5.4.9.2.1.1.2.a     The purpose of the VCDU Identifier (VCDU-ID) is to
                    identify the operational spacecraft with which the VCDU
                    is associated, and to identify the Virtual Channel in
                    use. The field contains two subfields:

5.4.9.2.1.1.2.1     Spacecraft Identifier (Bits 2 through 9)

5.4.9.2.1.1.2.1.a   The Spacecraft Identifier (SCID) identifies the various
                    logical entities that provide data to (or receive data
                    from) the VCA sublayer. It also provides the naming
                    domain for the Virtual Channels.

5.4.9.2.1.1.2.1.b   For complex international constellations of spacecraft,
                    several SCIDs may be present in the same PCA_PDU.  A
                    single spacecraft may be assigned more than one SCID.
                    Different SCIDs will be assigned for flight vehicles,
                    for development vehicles which are using ground
                    networks during prelaunch operations, and for simulated
                    streams. The Secretariat of the CCSDS assigns SCIDs,
                    using procedures defined in Reference [1].

5.4.9.2.1.1.2.1.c   The convention for the SCID naming domains is as
                    follows:

5.4.9.2.1.1.2.1.d   for space-to-ground communication the naming domain is
                    the source naming domain (i.e., the transmitting
                    spacecraft);

5.4.9.2.1.1.2.1.e   for ground-to-space communication the naming domain is
                    the destination naming domain (i.e., the receiving
                    spacecraft);

5.4.9.2.1.1.2.1.f   for space-to-space communication the naming domain is
                    the source naming domain (i.e., the transmitting
                    spacecraft).

5.4.9.2.1.1.2.2     Virtual Channel Identifier (Bits 10 through 15)

5.4.9.2.1.1.2.2.a   The six-bit Virtual Channel Identifier (VCID) field
                    enables up to 64 Virtual Channels (VCs) to be run
                    concurrently in association with each SCID that is
                    authorized in a particular PCA_PDU.

5.4.9.2.1.1.2.2.b   If only one VC is used, these bits are set permanently
                    to value "all zeros". A VC used for transmission of
                    "Fill" data is indicated by setting these bits to the
                    reserved value of "all ones": a Fill VC so identified
                    may not contain any valid user data within its Data
                    Unit Zone, but it must contain the Insert Zone if
                    Insert service is supported.

5.4.9.2.1.1.3       VIRTUAL CHANNEL DATA UNIT COUNTER (Bits 16 through 39)

5.4.9.2.1.1.3.a     The purpose of the VCDU Counter field is to provide
                    individual accountability for each of the sixty-four
                    Virtual Channels.

5.4.9.2.1.1.3.b     The 24-bit field represents a sequential count (modulo
                    16,777,216) of the total number of VCDUs which have
                    been transmitted on each of the VCs; it is used in
                    association with the VCID field to maintain a separate
                    counter for each VC.

5.4.9.2.1.1.4       SIGNALLING FIELD (Bits 40 through 47)

5.4.9.2.1.1.4.a     The Signalling field is used to alert the receiver of
                    the VCDU with respect to functions that: (a) may change
                    more rapidly than can be handled by management, or; (b)
                    provide a significant cross check against manual or
                    automated setups, for use in VCA sublayer fault
                    detection and isolation. The Signalling field contains
                    two subfields:

5.4.9.2.1.1.4.1     Replay Flag (Bit 40)

5.4.9.2.1.1.4.1.a   Recognizing the need to store VCDUs during periods when
                    the Physical Channel is unavailable, and to retrieve
                    them for subsequent replay when the channel is
                    restored, this flag alerts the receiver of the VCDU
                    with respect to its "realtime" or "replay" status. Its
                    main purpose is to discriminate between realtime and
                    replay VCDUs transmitted on a particular Physical
                    Channel when they both may use the same VCID.

5.4.9.2.1.1.4.1.b   The Replay Flag is interpreted as follows:

                    "0" = Realtime VCDU
                    "1" = Replay VCDU

5.4.9.2.1.1.4.1.c   Owing to the wide spectrum of onboard storage and
                    retrieval technology options, the exact interpretation
                    of this Flag is necessarily the subject of negotiation
                    between Projects and cross support organizations. For
                    instance, it may be interpreted to indicate that the
                    value of the VCDU Counter field on the replayed VC
                    decreases rather than increases, as a function of
                    reverse playback. Note that if a Reed-Solomon encoded
                    CVCDU is stored, it must be re-encoded if the status of
                    the Replay Flag is altered after retrieval.

5.4.9.2.1.1.4.2     Reserved Spares (Bits 41 through 47)

5.4.9.2.1.1.4.2.a   The seven-bit Reserved Spares field is reserved by
                    CCSDS for potential future signalling applications and
                    in the interim shall, by convention, be set to the
                    value "all zeros".

5.4.9.2.1.1.5       VCDU HEADER ERROR CONTROL (Bits 48 through 63,
                    optional)

5.4.9.2.1.1.5.a     The 2-bit Version Number field, the 14-bit VCDU
                    Identifier field, and the 8-bit Signalling field may
                    all be protected by an optional error detecting and
                    error correcting code, whose check symbols are
                    contained within this 16-bit field.

5.4.9.2.1.1.5.b     The VCDU Header Error Control field is either mandatory
                    or optional, depending on the Grade of Service, the
                    presence or absence of related VCDU fields, and local
                    implementation decisions.  (See Section 5.4.9.1.2.3,
                    Section 5.4.9.1.2.10 and Reference [8] for more
                    information on these dependencies.)

5.4.9.2.1.1.5.c     The mechanism for generating the VCDU Header Error
                    Control field shall be to use a shortened Reed-Solomon
                    (10,6) code. The parameters of the selected code are as
                    follows:

                    (1)   "J=4" bits per Reed-Solomon (R-S) symbol.

                    (2)   "E=2" symbol error correction capability within
                          a R-S code word.

                    (3)   The field generator polynomial shall be:

                                  [IMAGE]

                    (4)   The code generator polynomial shall be:

                                  [IMAGE]

                    (5)   Within an R-S symbol, the transmission shall
                          start from the bit on the left side;  e.g.,

                                  [IMAGE]

              shall be transmitted as a 1 followed by three 0s.

           (6)The bit to R-S symbol mapping shall be:

                   bits in the header  symbol

                     0,1,2,3              0
                     4,5,6,7              1
                     8,9,10,11            2
                     12,13,14,15          3
                     40,41,42,43          4
                     44,45,46,47          5
                     48,49,50,51          6
                     52,53,54,55          7
                     56,57,58,59          8
                     60,61,62,63          9

5.4.9.2.1.1.5.d     Note that the header error correction code can correct
                    up to and including two symbol errors.  This is
                    sufficient to meet the required performance of &lt;1x10E-
                    07 VCA_SDUs missing (specified in Table 5-6 for Grade-3
                    service) at a 1x10E-05 channel bit error rate, for
                    random bit errors.  In the case of convolutional coded
                    channels, in particular when the convolutional coding
                    is interleaved, the VCA_SDU loss rate will drop to
                    2x10E-05 at an operating point equivalent to a channel
                    bit error rate of 1x10E-05.  This is due to the burst
                    errors typical of the convolutional decoders.  The
                    minimum required performance may be achieved, for
                    example, by using Grade-2 services, by using additional
                    (transparent) interleaving, or by improving the link
                    margin.

5.4.9.2.1.2 VCDU INSERT ZONE

5.4.9.2.1.2.a  The presence or absence of the optional VCDU Insert Zone is
               established by management. If the VCDU/CVCDU supports the
               Insert service for transfer of isochronous data, the Insert
               Zone shall exist in every VCDU and/or CVCDU that is
               transmitted in a particular PCA_PDU, including Fill VCDUs.

5.4.9.2.1.2.b  The length of the Insert Zone shall be set by management to
               be equal to the constant length of the Insert Service Data
               Unit (IN_SDU) for that PCA_PDU.  The Insert Zone shall
               contain precisely one octet-aligned IN_SDU. There is no
               CCSDS protocol data unit associated with the Insert service
               within the VCA sublayer.

5.4.9.2.1.2.c  If the Insert Zone is present, management reduces the length
               of the VCDU Data Unit Zone that is available to VCA users by
               an amount equal to the constant length of the Insert Zone.
               Once set by management, the length and presence of the
               Insert Zone is static.

5.4.9.2.1.3    VCDU DATA UNIT ZONE

5.4.9.2.1.3.a  The VCDU Data Unit Zone, which must exist as an integer
               number of octets, has a length which varies and is equal to:

               (1)  the fixed VCDU or CVCDU length which has been selected
                    for use on a particular Physical Channel; minus

               (2)  the length of the VCDU Primary Header plus the length
                    of the VCDU Insert Zone and/or the VCDU Trailer and/or
                    the Reed-Solomon check symbols (if any of these are
                    present).

5.4.9.2.1.3.b  The VCDU Data Unit Zone contains higher-layer service data
               units associated with the SLS Encapsulation, Multiplexing,
               Bitstream, or Virtual Channel Access service interfaces. It
               may therefore contain one M_PDU, one B_PDU, one SLAP_PDU, or
               one private data unit of unknown internal format and
               structure.

5.4.9.2.1.3.c  When no valid higher-layer data are available for
               transmission at release time for a VCDU, the Virtual Channel
               ID shall be set to the value "all ones" and a Project-
               specified "fill" pattern shall be inserted into the VCDU
               Data Unit Zone.

5.4.9.2.1.4    VCDU TRAILER

5.4.9.2.1.4.a  The VCDU Trailer is an optional component of the VCDU. Its
               presence or absence and internal configuration are
               prespecified for a particular Virtual Channel by management.
               If present, it provides a mechanism for inserting an
               "Operational Control" field, and/or a "VCDU Error Control"
               field into the trailing octets of a particular VCDU.

5.4.9.2.1.4.1    Operational Control Field (32 bits) (optional)

5.4.9.2.1.4.1.a. The purpose of the Operational Control field is to allow
                 a Project organization to support a hybrid configuration
                 whereby a "Conventional" CCSDS system may be operated in
                 conjunction with an Advanced Orbiting System. If present,
                 this 32-bit field shall contain a "Command Link Control
                 Word", whose use and format are defined in the CCSDS
                 Recommendations for Packet Telemetry, Reference [2], and
                 Telecommand, Reference [5].  A discussion of hybrid
                 telecommand operations is continued in Reference [8].

5.4.9.2.1.4.1.b  If the VCDU Error Control field is not present in the
                 VCDU Trailer, this field occupies the four trailing
                 octets of the VCDU. If the VCDU Error Control field is
                 present, this field is displaced towards the beginning of
                 the VCDU by two octets.

5.4.9.2.1.4.2    VCDU Error Control Field (16 bits) (optional)

5.4.9.2.1.4.2.a  The VCDU Error Control field contains a 16-bit cyclic
                 redundancy code which provides a capability for detecting
                 errors that may have been introduced into VCDUs that have
                 been transmitted without the protection of Reed-Solomon
                 outer coding. Note that since the VCDU Header Error
                 Control field independently protects key elements of the
                 VCDU Primary Header, the main use of the VCDU Error
                 Control field is to detect errors occurring elsewhere in
                 the VCDU structure.

5.4.9.2.1.4.2.b  Use of the VCDU Error Control field is mandatory within
                 Virtual Channels that are not Reed-Solomon encoded; its
                 presence is not otherwise required. Presence or absence
                 of the field within a particular VCDU is prespecified by
                 management as a setup parameter for the receiving end of
                 each Virtual Channel; it may not be dynamically changed.
                 If present, the field occupies the two trailing octets of
                 the VCDU.

5.4.9.2.1.4.2.c  The cyclic redundancy code contained within this field
                 shall be characterized as follows:

                 (1)  The generator polynomial shall be:

                      g(x) = x**16 + x**12 + x**5 + 1

                 (2)  Both encoder and decoder shall be initialized to the
                      "all ones" state for each VCDU.

                 (3)  Parity "P" generation shall be performed over the
                      data space "D" as shown in Figure 5-12; i.e., "D"
                      covers the entire VCDU excluding the final 16-bit
                      VCDU Error Control field.

                 (4)  The generated parity symbols shall then be inserted
                      into the VCDU Error Control field which occupies the
                      final 16-bits of the VCDU.

5.4.9.2.1.4.2.d  The detailed procedure for generating the parity symbols
                 is identical to that used for the Version-1 CCSDS
                 Telemetry Transfer Frame and is thus specified in
                 Reference [2].


                                  [IMAGE]


         Figure 5-12:  VCDU Fields over Which Parity Is Generated

5.4.9.2.1.5    REED-SOLOMON CHECK SYMBOLS FIELD

5.4.9.2.1.5.a  The Reed-Solomon Check Symbols field contains the Reed-
               Solomon check symbols, which shall be generated according to
               the procedures specified in Reference [3]. The presence or
               absence of this field is an attribute of the Virtual Channel
               and is prespecified by management. A VCDU which has this
               field appended becomes known as a Coded Virtual Channel Data
               Unit (CVCDU). In order to meet the requirement that VCDUs
               and CVCDUs have the same (fixed) length on a particular
               Physical Channel, the Data Unit Zone of a CVCDU is shortened
               to accommodate the addition of the Reed-Solomon check
               symbols.

5.4.9.2.2      FORMAT OF THE SLAP_PDU

5.4.9.2.2.a    If a particular Virtual Channel is configured by management
               to support Grade-1 service, the SLAP Procedures accept fixed-
               length SLAP_SDUs (received in a SLAP_DATA.request primitive)
               and generate the SLAP Protocol Data Unit (SLAP_PDU).

5.4.9.2.2.b    The length of the SLAP_PDU is fixed by management for any
               particular Virtual Channel since it is inserted exactly into
               the fixed-length VCDU Data Unit Zone of a CVCDU.
               Necessarily, the management processes which fix the length
               of the SLAP_SDU carried within the SLAP_PDU must take into
               account the length of the SLAP_PDU protocol control
               information.

5.4.9.2.2.c    The format of the SLAP_PDU is shown in Figure 5-13.

5.4.9.2.2.d    The "Link ARQ Control Word", which supports the SLAP
               protocol, is discussed further in Section 6.


                                  [IMAGE]


                  Figure 5-13:   SLAP Protocol Data Unit


5.4.9.2.3      FORMAT OF THE PCA_PDU

5.4.9.2.3.a    The PCA_PDU consists of a continuous and contiguous
               succession of equal-length Channel Access Data Units
               (CADUs). The CADU consists of a VC_PDU (i.e., a VCDU or a
               CVCDU, possibly exclusively ORed with a bit transition
               generator) that is prefixed by a Synchronization Marker.
               Since the succession of CADUs occur at fixed time intervals
               that are synchronized with the transmitted channel bit rate,
               the CADUs provide "channel access slots" into which
               individual VC_PDUs are placed.

5.4.9.2.3.b    The format of the PCA_PDU is shown in Figure 5-14.


                                  [IMAGE]

         Figure 5-14:  Physical Channel Access Protocol Data Unit


5.4.9.2.3.c    The Synchronization Marker shall be the standard CCSDS
               Attached Synchronization Marker that is specified in
               Reference [3].  It is a fixed 32-bit pattern which may be
               represented in hexadecimal notation as:

                               1ACFFC1D

5.4.10         SUMMARY OF VCA DATA STRUCTURES

5.4.10.a       Figure 5-15 summarizes the overall relationship between the
               Reed-Solomon Codeblock, the CVCDU, the VCDU, the CADU and
               the PCA_PDU. Within the transmitted PCA_PDU, both VCDUs and
               CVCDUs may appear in any order. The information relative to
               whether a particular CADU contains a VCDU or a CVCDU is
               inferred from the relevant VCDU-ID.

                                  [IMAGE]

   Figure 5-15:  Relationship Between the VCDU, CVCDU, CADU and PCA_PDU

5.4.10.1       STANDARD CADU/VCDU/CVCDU LENGTHS

5.4.10.1.a     In order to facilitate robust, reliable synchronization
               processes within the Space Link Subnet, the CADU length is
               fixed at a constant value for one given Physical Channel.
               For very high-rate systems, use of the maximum standard
               length is recommended for reasons of speed and efficiency.
               However, for lower-rate systems, shorter standard lengths
               are available to decrease the potential delays experienced
               by "realtime" data and to improve synchronization
               performance.

5.4.10.1.b     Since one VCDU or CVCDU is embedded synchronously within
               each CADU, the standard CADU lengths map directly into
               standard VCDU/CVCDU lengths. This section defines the
               standard VCDU or CVCDU lengths.  Note that the standard CADU
               lengths are 32-bits longer, corresponding to the added
               length of the Synchronization Marker. The length of the
               VCDU/CVCDU is a managed parameter.

5.4.10.1.c     Two different types of space data links are considered.

5.4.10.1.1     LINKS SUPPORTING ONLY SLS GRADE-3 SERVICE

5.4.10.1.1.a   On these links, where only VCDUs are transmitted (no CVCDUs
               are present), all VCDUs shall have one size only, until
               changed by management. The length of the VCDU can be chosen
               to be any integer number of octets, as required by the using
               Project, within the following range:

                Minimum VCDU length: 124 octets   (992 bits)
                Maximum VCDU length:1275 octets   (10,200 bits)

5.4.10.1.1.b   Once selected, the VCDU length must be fixed for a mission
               phase on a particular Physical Channel.

5.4.10.1.2     LINKS SUPPORTING MIXED SLS GRADES OF SERVICE, OR GRADE-1/2
               ONLY

5.4.10.1.2.a   On mixed links, where at least one Virtual Channel is
               providing Grade-1 or Grade-2 service (i.e., VCDUs and CVCDUs
               may both be present), or on links supporting purely Grade-
               1/2 service, the recommended standard lengths (which must be
               integer numbers of octets) are derived by varying the
               Interleave Depth (I) of the Reed-Solomon encoding as
               specified in Reference [3]. For systems requiring only octet
               compatibility, Projects may select a value from the
               following five standard lengths:

               Interleave Depth:    VCDU/CVCDU Length:

               I = 1                255 octets(2040 bits)
               I = 2                510 octets(4080 bits)
               I = 3                765 octets(6120 bits)
               I = 4                1020 octets   (8160 bits)
               I = 5                1275 octets   (10200 bits)

5.4.10.1.2.b   For systems requiring 32-bit compatibility, the technique of
               "Virtual Fill", as specified in Reference [3], may be used
               in addition to varying the Reed-Solomon Interleave Depth.
               The Virtual Fill, which is not transmitted, is used to
               shorten each Reed-Solomon codeblock by "n" octets. (A Reed-
               Solomon codeblock consists of "I" codewords, each of length
               255 octets. For example, if I=2 then the codeblock length
               without the Virtual Fill is 510 octets.) If this technique
               is used, Projects may select a value from the following five
               standard lengths:

               Interleave  Standard VCDU/CVCDU      Virtual Fill
               Depth:      length:                  octets/codeblock:

               I = 1       252 octets(2016 bits)    n = 3
               I = 2       508 octets(4064 bits)    n = 2
               I = 3       756 octets(6048 bits)    n = 9
               I = 4       1020 octets              (8160 bits)  n = 0
               I = 5       1260 octets              (10080 bits) n = 15

5.4.10.1.2.c   Once selected, the VCDU and CVCDU lengths must be the same
               and must be fixed for a mission phase on a particular
               Physical Channel.

5.4.10.2       SUMMARY OF CADU INTERNAL FORMATS

5.4.10.2.a     The various internal structures of the CADUs associated with
               different Grades of Service within the Space Link Subnet are
               summarized in the following diagrams.

5.4.10.2.b     GRADE-1, WITHOUT INSERT, ALL SLS SERVICES


                                  [IMAGE]


5.4.10.2.c     GRADE-1, WITH INSERT, ALL SLS SERVICES


                                  [IMAGE]


5.4.10.2.d     GRADE-2, WITHOUT INSERT, SLS MULTIPLEXING OR
               BITSTREAM SERVICE


                                  [IMAGE]


5.4.10.2.e     GRADE-2, WITHOUT INSERT, SLS VIRTUAL CHANNEL
               ACCESS SERVICE


                                  [IMAGE]


5.4.10.2.f     GRADE-2, WITHOUT INSERT, "FILL" VC


                                  [IMAGE]



5.4.10.2.g     GRADE-2, WITH INSERT, SLS MULTIPLEXING OR
               BITSTREAM SERVICE


                                  [IMAGE]


5.4.10.2.h     GRADE-2, WITH INSERT, SLS VIRTUAL CHANNEL ACCESS SERVICE


                                  [IMAGE]


5.4.10.2.i     GRADE-2, WITH INSERT, "FILL" VC


                                  [IMAGE]


5.4.10.2.j     GRADE-3, WITHOUT INSERT, SLS BITSTREAM SERVICE


                                  [IMAGE]


5.4.10.2.k     GRADE-3, WITHOUT INSERT, SLS VIRTUAL CHANNEL
               ACCESS SERVICE


                                  [IMAGE]


5.4.10.2.l     GRADE-3, WITHOUT INSERT, "FILL" VC


                                  [IMAGE]


5.4.10.2.m     GRADE-3, WITH INSERT, SLS BITSTREAM SERVICE


                                  [IMAGE]

5.4.10.2.n     GRADE-3, WITH INSERT, SLS VIRTUAL CHANNEL ACCESS SERVICE


                                  [IMAGE]


5.4.10.2.o     GRADE-3, WITH INSERT, "FILL" VC


                                  [IMAGE]


5.5       MANAGEMENT OF THE SPACE LINK SUBNETWORK

5.5.a     In order to conserve bandwidth on the Physical Channel, some
          parameters associated with SLS services are handled by management
          rather than by inline communications protocol. The managed
          parameters are those which tend to be static for long periods of
          time, and whose change generally signifies a major
          reconfiguration of the data communications systems associated
          with a particular Advanced Orbiting System. Through the use of a
          signalling system, management conveys the required configuration
          information to the applicable protocol layers within the SLS.

5.5.b     The managed configuration parameters for the VCA and VCLC
          sublayers are listed below. These parameters are defined in an
          abstract sense and are not intended to imply any particular
          implementation of a management system.


5.5.1     VIRTUAL CHANNEL ACCESS CONFIGURATION PARAMETERS

5.5.1.1   VC_PDU SERVICE PARAMETERS

5.5.1.1.a   Each VCDU-ID has associated with it a list of indicators which
            define:

5.5.1.1.b      the length of the VC_PDU;

5.5.1.1.c      the upper-layer service interface (i.e., Multiplexing,
               Bitstream, Virtual Channel Access, or Virtual Channel Data
               Unit) with which the VC_PDU is associated;

5.5.1.1.d      the Grade of Service being supported, i.e., the presence or
               absence of the Reed-Solomon check symbols and the SLAP
               protocol;

5.5.1.1.e      the presence or absence of the VCDU Header Error Control
               field;

5.5.1.1.f      the presence or absence of the Insert Zone and (if present)
               its length;

5.5.1.1.g      the presence or absence of the VCDU Trailer, and its
               contents;

5.5.1.1.h      the PCA_PDU(s) in which this VCDU-ID is authorized for
               transmission.

5.5.1.1.i   Management, via the signalling system, sends this information
            to both the sending and receiving entities.


5.5.1.2     VC_PDU RELEASE PARAMETERS

5.5.1.2.a   Each VCDU-ID has associated with it Project-unique parameters
            which define the conditions under which the VC_PDU is to be
            released for transmission. Management, via the signalling
            system, sends this Project-unique information only to the
            sending entity.

5.5.1.3     VC_PDU PROCESSING PARAMETERS

5.5.1.3.a   Each VCDU-ID has associated with it processing parameters
            which define:

5.5.1.3.b      whether the contents of the VCDU Data Unit Zone are to be
               extracted and delivered to the SLAP procedures, to the VCLC
               sublayer (Multiplexing and Bitstream service), or to the
               Virtual Channel Access service interface;

5.5.1.3.c      whether the complete VC_PDU is to be delivered to the
               Virtual Channel Data Unit or to the Virtual Channel Access
               service interface;

5.5.1.3.d      whether or not the VC_PDU is to be discarded because it
               contains Fill data.

5.5.1.3.e   Management, via the signalling system, sends this information
            to only the receiving entity.


5.5.2       VIRTUAL CHANNEL LINK CONTROL CONFIGURATION PARAMETERS

5.5.2.1     LOWER LAYER SERVICE PARAMETERS

5.5.2.1.a   Each VCLC entity has associated with it a list of indicators
            which define the following service parameters provided by the
            VCA sublayer below in conjunction with a particular VC:

5.5.2.1.b      the Grade of Service provided;

5.5.2.1.c      the length to be used for the service data unit.

5.5.2.1.d   Management, via the signalling system, sends this information
            to both the sending and receiving entities.


5.5.2.2     VCLC PROCESSING PARAMETERS

5.5.2.2.a   Each VCLC entity has associated with it processing parameters
            which define:

5.5.2.2.b      the type of service data unit being delivered by the VCA
               sublayer (i.e., M_PDU or B_PDU);

5.5.2.2.c      to which service access points the user service data units
               are to be delivered.

5.5.2.2.d   Management, via the signalling system, sends this information
            to only the receiving entity.





6    SPACE LINK ARQ PROCEDURE: SERVICE DEFINITION

6.1  INTRODUCTION

6.1.a      This section of the Recommendation defines the Space Link ARQ
           Procedure (SLAP) which is used to provide "Grade-1" data
           delivery service across the Space Link Subnetwork. Grade-1
           service is characterized by the transfer of higher-layer user
           service data units (SLAP_SDUs) so that they are delivered
           through the SLS in sequence, without duplication, with a very
           high probability of being complete, and with a very high
           probability that they are error free.

6.1.b      The SLAP, as described here, operates only within the Space
           Link Subnetwork and can therefore be used in support of both
           Path and Internet service. Extension of Grade-1 service across
           the entire CPN (sometimes described as "end-to-end") would
           require Project organizations either to use additional link
           layer ARQ protocols in each of the onboard and ground
           subnetworks, or to augment the Internet service by implementing
           a Transport layer which supports retransmission control.
           Alternatively, a special Application layer ARQ protocol could
           be used. It should be noted that the SLAP has been designed to
           be conceptually independent of the layer in which it operates,
           and thus could potentially be extended in the future for use as
           an Application layer ARQ protocol across the CPN.  This usage
           is not, however, currently part of this Recommendation and is
           not discussed further herein.

6.1.c      This section describes the operational concept for the SLAP and
           specifies the SLAP service interface. The CCSDS Secretariat
           should be consulted for information relative to the status of
           the SLAP protocol specification.

6.2  OPERATIONAL CONCEPT AND ORGANIZATION OF THE SLAP

6.2.a.     As noted in Section 5, the SLAP resides within the Virtual
           Channel Access (VCA) sublayer of the Space Link Subnet. It is
           an element of VCA procedure which supports the VCLC procedures
           as well as the Virtual Channel Access service. It relies upon
           the VCA service interface to achieve data transfer through the
           Physical Channel, using individual Virtual Channels which are
           dedicated to Grade-1 service.

6.2.b      The SLAP is defined to be a bidirectional procedure: two
           dedicated Grade-1 Virtual Channels, one in each direction of
           SLS data flow (e.g., VC "x" forward and VC "y" return), are
           paired to interconnect two symmetric SLAP entities. At each end
           of the connection ("Point A" and "Point B"), the SLAP entity is
           composed of both a "Sending Function" and an "Acceptance
           Function", as illustrated in Figure 6-1. Note that, although
           shown in separate boxes in the figure, the Sending and
           Acceptance Functions at Point A (and likewise at Point B) are
           in fact both performed within a single protocol state machine.


                                  [IMAGE]


                   Figure 6-1:  Symmetric SLAP Operation


6.2.c      The SLAP_SDUs are received from the service interface with a
           layer above (i.e., either the VCLC sublayer, or the Virtual
           Channel Access service). The SLAP Sending Function adds a Link
           ARQ Control Word (LACW) to each SLAP_SDU to produce a SLAP_PDU,
           which is transferred on a prespecified dedicated Virtual
           Channel by placing it within a Coded Virtual Channel Data Unit
           (CVCDU) data structure. The LACW contains numbering information
           which identifies each SLAP_SDU flowing on VC "x", plus a report
           of the status of acceptance of SLAP_SDUs flowing on VC "y".

6.2.d      The CVCDUs are protected using Reed-Solomon encoding, which
           provides the required very-high probability that the Grade-1
           SLAP_SDUs are error free. In the event that the VCA sublayer is
           unable to correct a CVCDU, it will be discarded and a
           discontinuity will thus be introduced into the sequence of
           SLAP_PDUs. Discontinuities may also be introduced by momentary
           channel outages. The SLAP therefore provides the necessary
           retransmission protocol needed to ensure the completeness and
           sequencing of delivered Grade-1 SLAP_SDUs by supplying the
           required numbering, sending, reporting, and resending
           procedures. The result is a hybrid system employing both
           powerful forward error correction and ARQ-type retransmission
           control.

6.2.e      Each LACW within a SLAP_PDU contains a sequence number that is
           associated with the SLAP_SDU to which it is appended. These
           sequence numbers are generated by the SLAP Sending Function,
           and are valid only within the SLAP; they are independent of the
           numbering scheme used by either the Virtual Channel procedures
           (i.e., the VCDU Counter in the VCDU Primary Header), or by the
           layers above. It is these LACW sequence numbers that are used
           for SLAP_PDU acceptance checks and for retransmission control.
           The sequence numbers assigned to SLAP_PDUs traveling in one
           direction over the connections are independent of the sequence
           numbers of SLAP_PDUs traveling in the opposite direction.

6.2.f      Certain LACWs may also be formatted to produce "supervisory"
           SLAP_PDUs, which are used to pass protocol control data from
           the Sending Function to the Acceptance Function, or vice versa.
           Supervisory SLAP_PDUs are not assigned sequence numbers by the
           Sending Function and therefore are not checked for correct
           sequencing by the Acceptance Function.

6.2.g      For the SLAP to operate, it is necessary for the Acceptance
           Function to acknowledge receipt of SLAP_PDUs, and to report
           sequence errors when they occur. These reports are carried in
           the LACWs that accompany data flowing in the opposite
           direction, i.e., reports concerning receipt of SLAP_PDUs
           transmitted from A to B are carried in the LACWs that are
           attached to SLAP_PDUs flowing from B to A.

6.2.h      If the LACW report received at Point A acknowledges that all
           SLAP_PDUs were received by the Acceptance Function at Point B,
           normal operation occurs. However, if the LACW report indicates
           that a sequence error has occurred, a retransmission strategy
           is invoked within the Sending Function at Point A to resend the
           missing SLAP_PDU(s). If an unrecoverable error condition is
           encountered, a service interruption is reported to management
           and the Sending Function at Point A then reinitializes itself
           and transmits a supervisory protocol control command to the
           Acceptance Function at Point B, which causes reinitialization
           there and enables service to be resumed.

6.2.i      In a symmetric manner, reports on data transmitted from the
           Sending Function at Point B to the Acceptance Function at Point
           A are carried in LACWs that accompany data flowing from A to B,
           and are acted upon by the Sending Function at Point B.

6.2.j      The general organization of the SLAP Sending and Acceptance
           Functions is shown in Figure 6-2. For simplicity, only half of
           the pair of procedures at each end of the connection is shown.


6.3  SLAP SERVICE INTERFACE SPECIFICATION

6.3.a      This section defines the services provided by the SLAP to the
           sublayer above (the VCLC sublayer, or the Virtual Channel
           Access service interface) and the services required by the SLAP
           from the Virtual Channel procedures in the sublayer below
           (referred to here as the "lower layer"). The service
           specifications in this section are not intended to imply any
           particular implementation.

6.3.b      The SLAP service is connection oriented; it is bidirectional
           and persists over time. Connection establishment, reset, and
           termination are controlled by management.    The service
           interfaces specified herein are only those that are used for
           data transfer once a connection has been established.

6.3.c      In the service interfaces described below, the general
           parameters "SN_SOURCE.address" and "SN_DESTINATION.address" are
           used to represent the identification of the subnetwork source
           and destination addresses for the data flowing over the SLAP
           connection. Within the SLS, the specific address parameters are
           provided by the VCDU-ID; however, the more general parameter
           terminology is used to facilitate potential future application
           of the SLAP within other layers of the CPN architecture.


                                  [IMAGE]

    Figure 6-2:  Organization of the SLAP Sending/Acceptance Functions


6.3.1      SLAP/UPPER LAYER SERVICE INTERFACE SPECIFICATION

6.3.1.a    This section specifies the services required of the SLAP by the
           upper layer, as described from the viewpoint of the upper
           layer. These services allow a local upper-layer entity to
           exchange data units with remote peer upper-layer entities. The
           upper layer accesses the SLAP via a "SLAP_SAP", which is
           associated with a particular Virtual Channel by management.

6.3.1.b    The only service provided at this interface is data transfer.
           The service primitives associated with data transfer are:

           SLAP_DATA.request
           SLAP_DATA.indication

6.3.1.1    SLAP_DATA.request

6.3.1.1.a   Function

            This primitive is the service request primitive for the SLAP
            service.

6.3.1.1.b   Semantics

            The primitive shall provide parameters as follows:

                              SLAP_DATA.request          (SLAP_SDU,
                                      SN_SOURCE.address)

6.3.1.1.c   When Generated

            This primitive is passed to the SLAP to request that a
            SLAP_SDU be sent to the other end of the connection.

6.3.1.1.d   Effect on Receipt

            Receipt of this primitive causes the SLAP to send the
            SLAP_SDU, using the Virtual Channel identified by the
            SN_SOURCE.address.

6.3.1.1.e   Additional Comments

            The SN_SOURCE.address parameter is specified by the VCDU-ID.
            The length of the SLAP_SDU on a given VC is equal to the
            length of the CVCDU Data Unit Zone minus the length of the
            LACW, and must remain fixed for the duration of the
            connection.

6.3.1.2     SLAP_DATA.indication

6.3.1.2.a   Function

            This primitive is the service indication primitive for the
            SLAP service.

6.3.1.2.b   Semantics

            The primitive shall provide parameters as follows:

            SLAP_DATA.indication       (SLAP_SDU,
                                        SN_DESTINATION.address)

6.3.1.2.c   When Generated

            This primitive is passed from the SLAP to the layer above to
            indicate the arrival of a SLAP_SDU on the Virtual Channel
            indicated by the SN_DESTINATION.address.

6.3.1.2.d   Effect on Receipt

            The effect of receipt of this primitive by the layer above is
            specified in Section 5.

6.3.1.2.e   Additional Comments

            The SN_DESTINATION.address parameter is specified by the VCDU-
            ID. The SLAP_SDU is guaranteed to be delivered in the same
            sequence in which it was submitted to the SLAP, with a
            specified high probability of being without omission or
            duplication, and with a specified high probability of not
            containing an error induced by the SLS.


6.3.2      SLAP/LOWER LAYER SERVICE INTERFACE SPECIFICATION

6.3.2.a    This section specifies the services required of the lower layer
           by the SLAP. These services allow the local SLAP entity to
           exchange SLAP_PDUs with a peer SLAP entity at the other end of
           a connection.

6.3.2.b    The service primitives at the lower layer interface are:

           VCA_UNITDATA.request
           VCA_UNITDATA.indication

6.3.2.1     VCA_UNITDATA.request

6.3.2.1.a   Function

            This primitive is the service request primitive for the VCA
            service.

6.3.2.1.b   Semantics

            The primitive shall provide parameters as follows:

            VCA_UNITDATA.request       (SLAP_PDU,
                                        SN_SOURCE.address)

6.3.2.1.c   When Generated

            This primitive is passed from the SLAP Procedures to the
            Virtual Channel  procedures to request them to send the
            SLAP_PDU, using the Virtual Channel identified by the
            SN_SOURCE.address parameter.

6.3.2.1.d   Effect on Receipt

            Receipt of this primitive causes the Virtual Channel
            procedures to encapsulate the SLAP_PDU within a CVCDU and to
            attempt to send it.

6.3.2.1.e   Additional Comments

            The SN_SOURCE.address parameter is specified by the VCDU-ID. A
            dedicated Virtual Channel must be used to transmit the
            SLAP_PDU. The length of the SLAP_PDU on a given dedicated
            Grade-1 VC is equal to the length of the CVCDU Data Unit Zone,
            and must remain fixed for the duration of the connection.

6.3.2.2     VCA_UNITDATA.indication

6.3.2.2.a   Function

            This primitive is the service indication primitive for the VCA
            service.

6.3.2.2.b   Semantics

            The primitive shall provide parameters as follows:

            VCA_UNITDATA.indication         (SLAP_PDU,
                                             SN_DESTINATION.address,
                                             VCDU Data Loss Flag)

6.3.2.2.c   When Generated

            This primitive is passed from the Virtual Channel procedures
            to the SLAP to indicate the arrival of a SLAP_PDU on the
            Virtual Channel indicated by the SN_DESTINATION.address.

6.3.2.2.d   Effect on Receipt

            The effect of receipt of this primitive by the SLAP is
            currently unspecified.

6.3.2.2.e   Additional Comments

            The SN_DESTINATION.address parameter is specified by the VCDU-
            ID. The Virtual Channel procedures must provide a fixed-length
            CVCDU Data Unit Zone for the duration of the SLAP connection.


6.4  REQUIREMENTS FOR THE SLAP PROTOCOL

6.4.a      This section presents an overview of the functional
           requirements which must be satisfied by the SLAP.


6.4.1      REQUIREMENTS FOR THE SLAP SENDING FUNCTION

6.4.1.a    The SLAP Sending Function shall receive SLAP_SDUs and
           corresponding address information from the layer above the
           SLAP.

6.4.1.b    The SLAP Sending Function shall guarantee that the SLAP_SDUs
           are delivered complete, in sequence, and without duplication to
           the remote SLAP entity at the other end of the connection.

6.4.1.c    The SLAP Sending Function shall utilize the underlying services
           of the sublayer below for transfer of SLAP_PDUs to the remote
           peer SLAP entity.

6.4.1.d    The SLAP Sending Function shall deliver the SLAP_PDUs to the
           sublayer below in a controlled flow so as to avoid an overflow
           of the remote peer SLAP entity's capacity to receive.

6.4.1.e    The SLAP Sending Function shall, when requested by the remote
           peer SLAP entity, retransmit all SLAP_PDUs that have been
           transmitted since the last acknowledged SLAP_PDU.

6.4.1.f    In the event that acknowledgements are not received within a
           specified period of time, the SLAP Sending Function shall
           retransmit all SLAP_PDUs that have been transmitted since the
           last acknowledged PDU.


6.4.2      REQUIREMENTS FOR THE SLAP ACCEPTANCE FUNCTION

6.4.2.a    The SLAP Acceptance Function shall establish a full-duplex
           connection with a remote peer SLAP entity, when a "connect
           request" is received from management, and confirm to management
           that the connection has been established.

6.4.2.b    The SLAP Acceptance Function shall report to management when
           the remote peer SLAP entity establishes a connection.

6.4.2.c    The SLAP Acceptance Function shall terminate a connection
           (empty all buffers, reset all timers and counters, and
           disconnect) with a remote peer SLAP entity when a "disconnect
           request" is received from management, and confirm to management
           that the connection has been terminated.

6.4.2.d    The SLAP Acceptance Function shall report to management when
           the remote peer SLAP entity terminates the connection.

6.4.2.e    The SLAP Acceptance Function shall perform a loop-back test of
           the SLAP-to-SLAP connection, when a "transmit test request" is
           received from management, and report to management the status
           of the connection upon completion of the test.

6.4.2.f    The SLAP Acceptance Function shall perform a reset (empty all
           buffers and reset all timers and counters) of the connection
           when a "reset request" is received from management, and confirm
           to management that the reset has been performed.

6.4.2.g    The SLAP Acceptance Function shall report to management when
           the remote peer SLAP entity issues a reset of the connection.

6.4.2.h    The SLAP Acceptance Function shall report unrecoverable error
           conditions to management.

6.4.2.i    The SLAP Acceptance Function shall process pending management
           requests before pending SLAP_DATA.requests or
           VCA_UNITDATA.indications.




7  CROSS SUPPORT OPTIONS

7.a       This section defines the service options which may be selected by
          a Project organization in order to conform to the Advanced
          Orbiting Systems architecture defined within this Recommendation.
          It also defines the relationship between the selected services
          and the levels of cross support which may be achieved.


7.1  CROSS SUPPORT CONCEPTS

7.1.a     Cross support may occur between different organizations within
          one Agency who are cooperating in the execution of a space
          mission, or between different Agencies. Cross support takes place
          at the level of data structures that are created by one party in
          the cooperative arrangement and are handed over to another party
          for transmission between ground and space systems, using
          transmission resources that are supplied by the supporting party.
          As defined in this Recommendation, cross support therefore
          involves traversing the Space Link Subnetwork at some point
          during the transfer of data.

7.1.b     Two types of cross support, as identified in Figure 7-1, are
          possible. "Symmetric" cross support occurs when party "A" submits
          a data structure "X" to party "B" at a sending node, and receives
          the same data structure "X" back from party "B" at a receiving
          node. "Asymmetric" cross support occurs when party "A" submits a
          data structure "X" to party "B" at a sending node and receives a
          different data structure "Y" (at a higher or lower layer) back
          from party "B" at a receiving node.

7.1.c     When cross support is symmetric, only the data structure itself
          and its pertinent physical attributes (e.g., size, frequency,
          etc.) need to be agreed upon between the parties.

7.1.d     When cross support is asymmetric, use of the same protocols
          within the unbalanced layers is required.

7.1.e     In all cases of cross support, full agreement on any options
          within the protocols and/or data structures is required.

7.1.f     For current information concerning the precise specification of
          cross support services, the CCSDS Secretariat should be
          consulted.

                                  [IMAGE]

                 Figure 7-1:  Cross Support Configurations


7.2  CPN SERVICE OPTIONS

7.2.a     Within the framework of this Recommendation, a particular Project
          organization may select from a set of eight CCSDS service options
          in response to its specific requirements. Generally, the Project
          will select one or more data transfer services across the CPN,
          plus one or more data transfer services across the Space Link
          Subnetwork. Each of the services may operate either
          unidirectionally or bidirectionally, at the Project's choice.

7.2.b     The services available for use by Projects to transfer data
          across the CPN are the CCSDS Path service as specified in Section
          3 and the CCSDS Internet service as specified in Section 4.

7.2.c     The services available for use by Projects to transfer data
          across the Space Link Subnetwork, all of which are specified in
          Section 5, are: the CCSDS Encapsulation service; the CCSDS
          Multiplexing service; the CCSDS Bitstream service; the CCSDS
          Virtual Channel Access service; the CCSDS Virtual Channel Data
          Unit service; and the CCSDS Insert service.


7.2.1     GENERIC SERVICE PROFILE

7.2.1.a   Figure 7-2 presents a generic "options profile" of all of the
          functions associated with CPN services. Note that Path and
          Internet "gateway" functions are associated with the relay of
          Path and Internet protocol data units which originate outside of
          a CPN.

7.2.1.b   The generic CPN service options profile is used in the following
          paragraphs to define the specific set of options associated with
          each of the selected CCSDS services. For asymmetric cross support
          of a particular CCSDS service, a Project organization must
          conform to at least one vertical path through the specific
          options profile for that service.


7.2.2     PATH SERVICE OPTIONS PROFILE

7.2.2.a   The options profile for the CCSDS Path service is shown in Figure
          7-3. The user may interface via the Octet String or Packet
          service options, as defined in Section 3. Alternatively, a "Path
          gateway" function may be entered so that a Logical Data Path
          which originated outside the boundaries of the CPN may traverse
          the CPN, using the CCSDS Path protocol. Note that the Path
          service requires use of Reed-Solomon coding during SLS transfer.


7.2.3     INTERNET SERVICE OPTIONS PROFILE

7.2.3.a   The options profile for the CCSDS Internet service is shown in
          Figure 7-4. The user may interface with the Internet service as
          defined in Section 4. Alternatively, an "Internet gateway"
          function may be entered so that an Internet message which
          originated outside the boundaries of the CPN may traverse the
          CPN, using the CCSDS Internet protocol. Note that the Internet
          service requires use of Reed-Solomon coding during SLS transfer.


7.2.4     ENCAPSULATION SERVICE OPTIONS PROFILE

7.2.4.a   The options profile for the CCSDS Encapsulation service is shown
          in Figure 7-5. Note that the Encapsulation service requires use
          of Reed-Solomon coding during SLS transfer.


                                  [IMAGE]

             Figure 7-2:  Generic CPN Service Options Profile

                                  [IMAGE]

                 Figure 7-3:  Path Service Options Profile

                                  [IMAGE]

               Figure 7-4:  Internet Service Options Profile

                                  [IMAGE]

            Figure 7-5:  Encapsulation Service Options Profile

7.2.5     MULTIPLEXING SERVICE OPTIONS PROFILE

7.2.5.a   The options profile for the CCSDS Multiplexing service is shown
          in Figure 7-6. Note that the Multiplexing service requires use of
          Reed-Solomon coding during SLS transfer.


7.2.6     BITSTREAM SERVICE OPTIONS PROFILE

7.2.6.a   The options profile for the CCSDS Bitstream service is shown in
          Figure 7-7.


7.2.7     VIRTUAL CHANNEL ACCESS SERVICE OPTIONS PROFILE

7.2.7.a   The options profile for the CCSDS Virtual Channel Access service
          is shown in Figure 7-8.


7.2.8     VIRTUAL CHANNEL DATA UNIT SERVICE OPTIONS PROFILE

7.2.8.a   The options profile for the CCSDS Virtual Channel Data Unit
          service is shown in Figure 7-9. The Header Error Control and/or
          VCDU Error Control, if selected, must be present in the data
          structure generated by the service user. Reed-Solomon encoding
          may be applied by the service user, or by the supporting SLS
          element.

7.2.8.b   Note that in order to avoid operational complexities associated
          with error control and modification of the user data structure,
          the Virtual Channel Data Unit service and the Insert service are
          mutually exclusive on a particular Physical Channel.


7.2.9     INSERT SERVICE OPTIONS PROFILE

7.2.9.a   The options profile for the CCSDS Insert service is shown in
          Figure 7-10. The Insert service may not be activated
          simultaneously with the Virtual Channel Data Unit service.


                                  [IMAGE]

             Figure 7-6: Multiplexing Service Options Profile

                                  [IMAGE]

               Figure 7-7: Bitstream Service Options Profile

                                  [IMAGE]

        Figure 7-8:  Virtual Channel Access Service Options Profile

                                  [IMAGE]

      Figure 7-9:  Virtual Channel Data Unit Service Options Profile

                                  [IMAGE]

               Figure 7-10:  Insert Service Options Profile

7.3  CROSS SUPPORT PROTOCOL OPTIONS MATRIX

7.3.a     The relationship between the data structures that are exchanged
          between cooperating parties in all possible symmetric and
          asymmetric cross support configurations are indicated in the
          matrix shown in Table 7-1. Based on its requirements for cross
          support, a Project may use the matrix to select the particular
          symmetric or asymmetric cross support data structure
          configurations which it will use in conjunction with each of its
          selected data transfer service options. For each unique
          configuration, the required stack of agreed CCSDS protocols may
          then be constructed. Further information concerning this matrix
          is presented in Reference [8]

7.3.b     The matrix is organized to show the input data structure (handed
          by one party to a supporting party) on the vertical axis, and to
          show the data structure received back from the supporting party
          on the horizontal axis. The box at the intersection of a row and
          column shows the stack of protocols which are required in order
          to achieve the cross support. The boxes on the diagonal are the
          symmetric cross support configurations where only the data
          structure itself must be agreed between the parties. The off-
          diagonal boxes show the possible asymmetric cross support
          configurations, and indicate the layers of protocol which must be
          agreed and implemented interoperably in order for the cross
          support to occur. Boxes indicated by a "-" are invalid
          configurations.

7.3.c     The key to the matrix is as follows:

      I        =   Internet protocol data unit
      P        =   Path protocol data unit
      E        =   Encapsulation protocol data unit
      M        =   Multiplexing protocol data unit
      B        =   Bitstream protocol data unit
      V        =   Virtual Channel protocol data unit (VCDU or CVCDU)
      PCA      =   Physical Channel Access protocol data unit (CADU)
      (R)      =   Standard Reed-Solomon code - required for Grade-1/2
                    Virtual
                   Channel Data Unit service
      s         =   Symmetric cross support
      -        =   Not applicable
      I_SDU    =   Internet service data unit
      I_PDU    =   Internet protocol data unit
      O_SDU    =   Octet String service data unit
      P_SDU    =   Packet service data unit
      CP_PDU   =   CCSDS Path protocol data unit
      E_SDU    =   Encapsulation service data unit
      M_SDU    =   Multiplexing service data unit
      B_SDU    =   Bitstream service data unit
      VCA_SDU  =   Virtual Channel Access service data unit
      VCDU_SDU =   Virtual Channel Data Unit service data unit
      IN_SDU   =   Insert service data unit
      RF       =   Radio Frequency signal



                 Table 7-1:  Cross Support Options Matrix

                                  [IMAGE]












                                  ANNEX A

                   ADDENDUM ON CCSDS PACKET TIMETAGGING


This Annex, which is part of the Recommendation, defines how a timetag may
be added to the Secondary Header of a CCSDS Packet.


A.1  INTRODUCTION

A.1.a     In many applications there is a firm requirement to stamp a CCSDS
          Packet with a timetag that is relatable to an event of
          significance to the recipient of the application data contained
          within the Packet.


A.1.1     PURPOSE

A.1.1.a   This Annex defines the mechanism to be used for timetagging a
          CCSDS Packet, using the facilities of its Secondary Header.


A.1.2     SCOPE

A.1.2.a   Packet timetagging may be required in a variety of space
          applications, such as ordering sets of user data into the time
          series in which they were generated at the source (in conjunction
          with the Packet sequence counter) or correlating user data with
          other independent data sets.

A.1.2.b   Services operating within Path service end systems (e.g., so-
          called "production data" or "level zero" processing) may impose
          their own additional requirements for Packet timetagging which
          are not specified herein.

A.1.2.c   Packet timetagging may be needed by users of the "Packet service"
          and "Octet String service" options of the CCSDS Path service.
          (Note that timetagging is not provided by the Encapsulation
          service for the Space Link Subnet.)

A.1.2.d   This Annex defines the mechanism to be implemented by users when
          formatting service data units, associated with CCSDS Path
          service, that need timetagging, but not the requirements that
          drive the need for such timetagging.


A.2       METHOD FOR CCSDS PACKET TIMETAGGING

A.2.a     For CCSDS Path service users who require Packet timetagging, the
          Packet Secondary Header shall be used and shall contain a
          standard CCSDS Time Code.

A.2.b     Within both the Packet service and the Octet string options of
          the Path service, the Secondary Header containing the Time Code
          shall be created by the user.

A.2.c     The presence or absence of the Secondary Header within the CCSDS
          Packet shall be signalled by the Secondary Header Flag within the
          Packet Primary Header.


A.2.1     SECONDARY HEADER STRUCTURE

A.2.1.a   The format for the Secondary Header shall be as shown in Figure A-
          1; it consists of an  optional Time Code Field followed by an
          optional Ancillary Data Field.

                                  [IMAGE]

                   Figure A-1:  Secondary Header Format


A.2.1.b   If present, a Secondary Header shall consist of:

A.2.1.c        a Time Code Field only; or

A.2.1.d        an Ancillary Data Field only; or

A.2.1.e        a Time Code Field followed by an Ancillary Data Field.

A.2.1.f   The chosen option is a managed parameter which is implied from
          the Path ID.


A.2.2     TIME CODE FIELD

A.2.2.a   The Packet Secondary Header Time Code Field shall consist of an
          integral number of octets.

A.2.2.b   It is preferred that the Packet Secondary Header Time Code Field
          should contain one of the CCSDS segmented binary or unsegmented
          binary time codes specified in Reference [20].

A.2.2.c   The time code selected (e.g., CCSDS Unsegmented Time Code, CCSDS
          Day Segmented Time Code) shall be fixed for a given Path ID.

A.2.2.d   The characteristics (e.g., ambiguity period, epoch, length,
          resolution) of the time code shall be selected from the options
          in Reference [20].

A.2.2.e   If the characteristics are fixed for a particular Path ID, the
          corresponding P-field (as described in Reference [20]) need not
          be present. If the characteristics are allowed to change for a
          Path ID, the P-field shall be present so as to identify the
          changes.

A.2.2.f   The presence or absence of the P-field in the Packet Secondary
          Header Time Code Fields shall be fixed for a particular Path ID.
          If present, it shall immediately precede the T-field that is
          defined in Reference [20].


A.2.3     ANCILLARY DATA FIELD

A.2.3.a   The optional Ancillary Data Field shall consist of an integral
          number of octets and may contain any ancillary information
          necessary for the interpretation of the information contained
          within the User Data Field of the CCSDS Packet.

A.2.3.b   The format and characteristics of the Ancillary data are not
          specified herein.












                                  ANNEX B

                         ACRONYMS AND TERMINOLOGY


This Annex, which is part of the Recommendation, summarizes the key
acronyms and terminology which are used throughout the document.


B.1   LIST OF ACRONYMS

APID:       APPLICATION PROCESS IDENTIFIER
ARQ:        AUTOMATIC REPEAT QUEUING
B-:         BITSTREAM
B_SDU:      BITSTREAM SERVICE DATA UNIT
B_PDU:      BITSTREAM PROTOCOL DATA UNIT
CADU:       CHANNEL ACCESS DATA UNIT
CCSDS:      CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS
CPN:        CCSDS PRINCIPAL NETWORK
CP_SAP:     CCSDS PATH SERVICE ACCESS POINT
CP_PDU:     CCSDS PATH PROTOCOL DATA UNIT
CP_SDU:     CCSDS PATH SERVICE DATA UNIT
CRC:        CYCLIC REDUNDANCY CODE
CVCDU:      CODED VIRTUAL CHANNEL DATA UNIT
dB:         DECIBEL
E-:         ENCAPSULATION
E_PDU:      ENCAPSULATION PROTOCOL DATA UNIT
E_SDU:      ENCAPSULATION SERVICE DATA UNIT
Eb/No:      INFORMATION BIT ENERGY TO NOISE RATIO
G/W:        GATEWAY
HDR:        HEADER
I:          INTERLEAVE DEPTH OR INFORMATION
ID:         IDENTIFIER
IN_SDU:     INSERT SERVICE DATA UNIT
ISO:        INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
LACW:       LINK ARQ CONTROL WORD
LDP:        LOGICAL DATA PATH
LinkID:     LINK IDENTIFIER
Mb/s:       MEGABITS PER SECOND
M-:         MULTIPLEXING
M_PDU:      MULTIPLEXING PROTOCOL DATA UNIT
M_SDU:      MULTIPLEXING SERVICE DATA UNIT
MSAP:       MANAGEMENT SERVICE ACCESS POINT
MSB:        MOST SIGNIFICANT BIT
N/A:        NOT APPLICABLE
O_SDU:      OCTET SERVICE DATA UNIT
OSI:        OPEN SYSTEMS INTERCONNECTION
P-FIELD:    PREAMBLE FIELD
PCA:        PHYSICAL CHANNEL ACCESS
PCA_PDU:    PHYSICAL CHANNEL ACCESS PROTOCOL DATA UNIT
PCID:       PACKET CHANNEL IDENTIFIER
PDU:        PROTOCOL DATA UNIT
P_SDU:      PACKET SERVICE DATA UNIT
R-S:        REED-SOLOMON
SAP:        SERVICE ACCESS POINT
SC:         SPACECRAFT
SCID:       SPACECRAFT IDENTIFIER
SDU:        SERVICE DATA UNIT
SEC.:       SECONDARY
SL:         SPACE LINK
SLAP:       SPACE LINK ARQ PROCEDURE
SLAP_PDU:   SLAP PROTOCOL DATA UNIT
SLAP_SAP:   SLAP SERVICE ACCESS POINT
SLAP_SDU:   SLAP SERVICE DATA UNIT
SLS:        SPACE LINK SUBNETWORK
SL_SAP:     SPACE LINK SERVICE ACCESS POINT
SN:         SUBNETWORK
SN_SAP:     SUBNETWORK SERVICE ACCESS POINT
SN_SDU:     SUBNETWORK SERVICE DATA UNIT
SYNC.:      SYNCHRONIZATION
T-FIELD:    TIME FIELD
VC:         VIRTUAL CHANNEL
VCA:        VIRTUAL CHANNEL ACCESS
VC_PDU:     VIRTUAL CHANNEL PROTOCOL DATA UNIT
VCA_SAP:    VIRTUAL CHANNEL ACCESS SERVICE ACCESS POINT
VCA_SDU:    VIRTUAL CHANNEL ACCESS SERVICE DATA UNIT
VCDU:       VIRTUAL CHANNEL DATA UNIT
VCID:       VIRTUAL CHANNEL IDENTIFIER
VCDU-ID:    VIRTUAL CHANNEL DATA UNIT IDENTIFIER (= SCID+VCID)
VCLC:       VIRTUAL CHANNEL LINK CONTROL
VCLC_PDU:   VIRTUAL CHANNEL LINK CONTROL PROTOCOL DATA UNIT
VCLC_SAP:   VIRTUAL CHANNEL LINK CONTROL SERVICE ACCESS POINT
VCLC_SDU:   VIRTUAL CHANNEL LINK CONTROL SERVICE DATA UNIT
8473:       ISO 8473 NETWORK LAYER PROTOCOL



B.2   SUMMARY OF TERMINOLOGY

ADVANCED ORBITING SYSTEM:

Those systems, located in space and on the ground, which support Earth
orbiting missions involving manned space stations, manned and unmanned
platforms, and space transportation systems.

AGENCY:

A national or international space organization which is a Member or
Observer of the Consultative Committee for Space Data Systems.

APID QUALIFIER:

A Path service mechanism for supplementing the Application Process ID in
the header of a Version-1 CCSDS Packet so that it may be locally
discriminated from other CCSDS Packets bearing the same APID.

APPLICATION, USER APPLICATION:

The name given to the internal activities of a user of the CPN who is
located at an endpoint of the network.

APPLICATION PROCESS IDENTIFIER, APID:

An 11-bit field within the Primary Header of a Version-1 CCSDS Packet,
which identifies a particular User Application within a local naming
domain.

APPLICATION SERVICES:

Upper-layer communications services provided to interactive space mission
applications such as file transfers, electronic messages, data-base
queries, etc.

ASYNCHRONOUS:

A data transfer technique which does not preserve precise timing or
structural relationships between the transmitted signal and the transfer
mechanism.

AUDIO:

A data stream containing digitized samples of human voice or sound signals.

BITSTREAM DATA:

An undelimited string of bits, each having apparently equal weight, which
has no known structure to a service provider.

BITSTREAM PROTOCOL DATA UNIT:

The protocol data unit of the B_PDU Construction Function of the Space Link
Subnet, having the format of a header followed by a fixed-length block of
data that contains a string of user bits (possibly terminated with fill
data), the boundary between user and fill data being indicated by a pointer
in the header.

BITSTREAM SERVICE (B-SERVICE):

A service within the Space Link Subnet which allows Bitstream Data to be
transferred on a dedicated Virtual Channel.

CCSDS PACKET:

A variable-length, delimited data unit whose structure and header
information is specified by the CCSDS.

CHANNEL ACCESS DATA UNIT:

A protocol data unit within the Virtual Channel Access sublayer of the
Space Link Subnet. A CADU consists of a VCDU or a CVCDU that has been
prefixed and delimited by a Synchronization Marker.

CODED VIRTUAL CHANNEL DATA UNIT:

A Virtual Channel Data Unit to which a block of error-correcting Reed-
Solomon check symbols has been appended.

CONNECTIONLESS:

A communications protocol which operates in a unidirectional fashion,
without handshaking from the receiving end, using a data path which may
dynamically vary.

CONNECTION-ORIENTED:

A communications protocol which operates in a closed-loop fashion by
receiving handshaking acknowledgements from the receiving end, using a pre-
established data path.

CONVENTIONAL:

Belonging to a class of (predominantly unmanned) missions as typified by
space missions flown during the 1960-1990 timeframe.

CROSS SUPPORT:

The capability for one CCSDS Agency to bidirectionally transfer data from
another CCSDS Agency between space and ground systems, through the Space
Link Subnetwork, using its own transmission resources.

DATA UNIT ZONE:

That portion of a Virtual Channel Data Unit into which higher-layer data
units may be placed for asynchronous or isochronous transmission.

ENCAPSULATION PROTOCOL DATA UNIT:

The protocol data unit of the Encapsulation Function of the Space Link
Subnet, having the format of a CCSDS Packet.

ENCAPSULATION SERVICE, FUNCTION (E-SERVICE):

A service or function within the Space Link Subnet which wraps incoming
delimited data units (that are not in CCSDS Packet format) into CCSDS
Packets, during their transfer through the Subnet.

END POINT, END SYSTEM:

The location on the CPN of a User Application, at which CPN services are
terminated.

GATEWAY:

The connecting point between two dissimilar subnetworks.

GRADE OF SERVICE:

A selectable method of data transmission service within the Space Link
Subnet.

GRADE-1 SERVICE:

A Space Link Subnet data transmission service whereby user data are
delivered through the SLS with very high probabilities of being complete
(i.e. no omissions or duplications), in sequence, and error free.

GRADE-2 SERVICE:

A Space Link Subnet data transmission service whereby user data are
delivered through the SLS possibly incomplete (i.e. with omissions),
possibly with duplications caused by onboard storage and retrieval, but
with a very high probability of being error free.

GRADE-3 SERVICE:

A Space Link Subnet data transmission service whereby user data are
delivered through the SLS possibly incomplete, possibly duplicated as a
result of onboard storage and retrieval, and possibly containing errors.

GROUND NETWORK:

The ground data distribution part of the CCSDS Principal Network.

HEADER:

A standard label which identifies a standard data communications structure.

IDLE:

A mechanism for maintaining synchronous data transmission, in the event
that no user data are available, by inserting "fill" data.

INSERT SERVICE, FUNCTION:

A service or function within the Space Link Subnet which allows isochronous
user data to share a Virtual Channel with other types of data.

INSERT SERVICE DATA UNIT:

The data unit which is placed within the Insert Zone of the Insert Protocol
Data Unit during transfer through the Space Link Subnet.

INSERT ZONE:

That portion of a Virtual Channel Data Unit into which Insert service data
units may be placed for isochronous transmission.

INTERNET, INTERNET SERVICE:

The CCSDS service which supports protocol-driven data flow from end-to-end
through multiple, heterogeneous subnetworks.

ISOCHRONOUS:

A data transfer technique which preserves the timing characteristics and
relationships of the transmitted signal.

LAYER:

A functional organization whereby a complex distributed system may be
broken into relatively simple modules of service.

LEVEL ZERO PROCESSING:

See PRODUCTION DATA PROCESSING.

LIFETIME CONTROL:

A method of data transmission whereby data units are discarded if the
number of times that they pass through intermediate nodes (such as routers
and gateways) exceeds a pre-established value.

LINK IDENTIFIER, LinkID:

The LinkID names the Physical Channel Access Protocol Data Unit (PCA_PDU),
and is the addressing mechanism for the Insert service.

LOGICAL DATA PATH:

A preconfigured route between two user application endpoints, through which
data may flow without the need for large communications headers. A Logical
Data Path associates the source, the destination, and the route between
them.

MANAGED OBJECT:

A parameter associated with a CPN service which is exposed to network
management for the purpose of network monitoring and control.

MANAGEMENT:

The set of functions and services provided within a network to supervise,
schedule, and control network resources.

MISSION:

An activity in space under the control of a Project.

MULTIPLEXING PROTOCOL DATA UNIT:

The protocol data unit of the Multiplexing Function of the Space Link
Subnet, having the format of a header followed by a fixed-length block of
data that contains a piece of a contiguous string of concatenated CCSDS
Packets.

MULTIPLEXING SERVICE, FUNCTION (M-SERVICE):

A service or function within the Space Link Subnet which packs CCSDS
Packets together so that they may efficiently occupy the fixed-length data
field of a Coded Virtual Channel Data Unit.

OCTET:

An eight-bit word.

OCTET STRING SERVICE:

A service option within the CCSDS Path service, whereby the CPN creates the
CCSDS Packets which support the Path protocol.

ONBOARD NETWORK:

The onboard data distribution part of the CCSDS Principal Network.

P-FIELD:

The Preamble Field of a standard CCSDS Time Code.

PACKET:

A variable-length, delimited data structure consisting of a set of higher-
layer user data that are encapsulated within standard header information.
(Note: the term "packet" is used generically in this Recommendation, while
the term "Packet" refers to the Version-1 CCSDS Packet.)

PACKET CHANNEL:

A mechanism used by the Multiplexing Function within the Space Link Subnet
to allow multiple users to share one Virtual Channel.

PACKET CHANNEL ID:

The identifier for a Packet Channel, mechanized using the APID field of a
CCSDS Packet.

PACKET SERVICE:

A service option within the CCSDS Path service, whereby users create the
CCSDS Packets which support the Path protocol.

PATH, PATH SERVICE:

The CPN service which, using Logical Data Paths, allows large rates and
volumes of space mission data to flow between relatively static endpoints
without requiring large communications headers.

PATH ENTITY:

A CPN element which supports CCSDS Path service.

PATH ID, PATH IDENTIFIER:

An identifier for a Logical Data Path.

PHYSICAL CHANNEL:

The space/space or space/ground transmission medium.

PHYSICAL CHANNEL LAYER:

The bottom layer of the Space Link Subnetwork.

PRIMITIVE:

An abstract model of the logical exchange of user data and control
information between network layers or sublayers.

PRINCIPAL NETWORK/CCSDS PRINCIPAL NETWORK:

A set of three subnetworks, clustered around special-purpose space data
channels, which provide basic space mission data communications services
using techniques which are standardized by the CCSDS.

PROCEDURE:

A set of functional processes which are used to implement a service.

PRODUCTION DATA PROCESSING:

A value-added service, performed at a CPN endpoint, which prepares user
data for delivery (also referred to as "level zero processing").
PROJECT:

An organization which has the technical and funding cognizance to execute a
particular space mission.

PROTOCOL DATA UNIT:

A data structure which operates across a layer within a distributed system
in order to implement the service offered by that layer.

RECOMMENDATION:

A CCSDS document which provides guidelines from which the CCSDS Agencies
may develop their own Standards.

REED-SOLOMON:

A high performance block-oriented outer coding technique which provides
powerful error-correction capability (named after its inventors, Reed and
Solomon).

SECONDARY HEADER:

An optional field within a Version-1 CCSDS Packet, into which supplementary
information (e.g., a Time Code) may be placed to facilitate value-added
network service.

SERVICE:

A standard capability which is offered within a network layer.

SERVICE ACCESS POINT:

An address on the CCSDS Principal Network where a particular CPN service is
exposed to a user.

SERVICE DATA UNIT:

A data unit which is provided as an input to a service, or which is output
by that service.

SIGNALLING:

The set of functions and services provided within a network to format and
exchange management information between management elements.

SPACE CHANNEL:

A space/space or space/ground data transmission path.
SPACECRAFT IDENTIFIER, SCID:

An identifier, contained within the Virtual Channel Data Unit header which,
when concatenated with the Version Number "01", identifies a local control
authority.

SPACE LINK SUBNET(WORK):

The central subnet within the CCSDS Principal Network, which enables the
transmission of data through space channels.

SPACE LINK ARQ PROCEDURE:

A function within the Space Link Subnet that performs retransmission
control to ensure delivered completeness of higher-layer data.

SPACE LINK LAYER:

The top layer of the Space Link Subnet, composed of the Virtual Channel
Link Control and Virtual Channel Access sublayers.

STANDARD:

A document which commits CCSDS Agency resources to a particular Project-
independent data handling technique.

SUBLAYER:

An internal partitioning of a layered architecture into fine-grained
subdivisions of function.

SUBNET(WORK):

A component of a network which provides local communications services
corresponding to OSI layers 1 and 2.

SYMBOL:

The encoded representation of space mission information as it flows through
space channels.

SYNCHRONIZATION MARKER:

A pattern used to delimit the boundaries of fixed-length data blocks as
they are transmitted through a space channel.

T-FIELD:

The Time Field of a standard CCSDS Time Code.
TELEMETRY:

A term used to characterize the generation of more or less continuous and
predictable sets of space mission measurement data at data rates and
volumes which may be extremely high, and which have a large interaction
with overall communications resources.

TIMETAG:

The digital representation of time information, used to annotate a space
service data unit with respect to its time of generation relative to other
mission events.

VERSION NUMBER:

An identifier, contained within the Virtual Channel Data Unit header, which
defines the protocol data unit in use at the Link layer of the Space Link
Subnetwork.

VIDEO:

A stream of data containing digitized samples of television signals.

VIRTUAL CHANNEL:

A mechanism whereby a single Physical Channel may be shared by different
types of users by creating multiple apparently parallel "virtual" paths
through the channel.

VIRTUAL CHANNEL ACCESS SERVICE:

A cross supported Space Link Subnetwork service which exposes the Data Unit
Zone of a Virtual Channel to users.

VIRTUAL CHANNEL ACCESS SUBLAYER:

A layer of the Space Link Subnetwork which transmits higher-layer data
through the Physical Channel using constant-length data blocks.

VIRTUAL CHANNEL DATA UNIT:

The protocol data unit of the Virtual Channel Access sublayer of the Space
Link Subnet, consisting of a fixed-length CCSDS data structure which is
used bidirectionally on space channels within Advanced Orbiting Systems to
implement an OSI layer-2 protocol.

VIRTUAL CHANNEL DATA UNIT IDENTIFIER (VCDU-ID):

An identifier, consisting of a Spacecraft ID concatenated with a Virtual
Channel ID which (when qualified by the Version Number "01") uniquely
identifies a particular AOS Virtual Channel.

VIRTUAL CHANNEL DATA UNIT SERVICE:

A cross support service within the Space Link Subnet that allows
independently created VCDU or CVCDUs to be transmitted on a Physical
Channel.

VIRTUAL CHANNEL LINK CONTROL SUBLAYER:

A layer of the Space Link Subnet which allows user data to be placed on
individual Virtual Channels.