Strawman Forward Frame CSTS Specification Technical Note (June 2010)

1. Strawman Forward Frame CSTS SpecificationTechnical Note (June 2010) John Pietras London, UK October 2010

2. Purpose of the Service Specification • Test the ability of the CSTS Framework to support specification of a forward synchronous link CSTS • Provide a starting point for the definition of an actual Forward Frame CSTS • Identified by the Interagency Operations Advisory Group (IOAG) Space Internetworking Strategy Group (SISG) has identified a need for a CSTS that transfers one of the following stream types in a given service instance: • Advanced Orbiting System (AOS) transfer frames destined for a synchronous forward space link • AOS Channel Access Data Units (CADUs) destined for a synchronous forward space link • Telecommand (TC) transfer frames destined for an asynchronous forward space link • These three stream types are to be supported by a single CSTS type

3. Approach Used in Developing the Specification • Apply appropriate parts of the CSTS Guidelines to create a shortened and simplified CSTS Service Specification • No ASN.1 modules defined • Different “modes” defined for TC Frames and synchronous link PDUs (AOS frames and CADUs) • Driven by current requirement that only one procedure type can be the type of the prime procedure instance • Essentially a CSTS mapping of the Enhanced FCLU SLE service (Orange Book), except: • There is no transfer of TC CLTUs • This capability is already provided by the standard FCLTU SLE service • Transfer of TC Frames is supported • Production of TC frames into CLTUs is included • Multiplexing of frames and CADUs from multiple instances of the F-Frame service is supported

4. Production and Provision of the F-Frame Service

5. Need for Two Prime Procedure Types • The CSTS FW Data Processing procedure is adequate for transfer of asynchronous TC frames, but not synchronous frames and CADUs • Efficient transfer of synchronous link PDUs is hampered by sequence enforcement and locking-on-PDU-expiration behavior of the Data Processing procedure • A different prime procedure type needs to be defined for synchronous PDU transfer • Alternative is to define a single procedure type that has two alternating behaviors and even alternating main operation types. Ugly • The two alternate prime procedures are illustrated as different “modes” of the service • Use of such modes is not formally defined for CSTSes • NOTE – Decision at London meeting to allow management selection of the prime procedure type for each service instance removes the need for these modes

6. F-Frame Procedures (TC Frame Mode)

7. TC Frame Processing Operations

8. TC Frame Processing PROCESS-DATA • Extension parameters • data parameter is extended to contain multiple variable-length (for TC) frames • diagnostic extension adds ‘unsupported VC’

9. TC Frame Processing NOTIFY • Extension parameters • Notification-type extension adds ‘buffer empty’ • ‘data unit processing started” deleted

10. Synchronous Link Mode • The Red-1 CSTSFW PROCESS-DATA operation and Data Processing procedure inhibit data flow for reasons that negate efficient forward synchronous service • Discard PDUs that don’t have the expected next sequence number • Lock the service instance if any PDU expires • Strawman specification postulates a new PUSH-DATA operation that has simplified content and behavior, and a new Forward Synchronous Data Processing procedure that uses it

11. PUSH-DATA Operation • Operation parameters • Standard Operation Header diagnostic extension • data-sequence-counter has no sequence-preservation enforcement requirements • data parameter defined as abstract

12. TC Frame Processing Procedures (Forward Synchronous Mode)

13. Forward Synchronous Data Processing Procedure Operations

14. Forward Synchronous Data Processing PUSH-DATA • Extension parameters • data parameter is extended to contain multiple delimited frames • data-sequence-counter is refined to count transferred PDUs (not PUSH-DATA invocations) • diagnostic values extended • ‘invalid time’ • ‘late data’ • ‘unable to store’

15. Forward Synchronous Data Processing NOTIFY • Extension parameters • notification-type extension values • ‘data processing successfully completed’ • ‘expired’ • buffer empty’

16. Summary of Suitability of Red-1 CSTSFW for the F-Frame Service • Red-1 CSTSFW cannot support F-Frame service as-is • A simpler forward data transfer data operation and a simpler procedure that uses that operation are needed • CSTS rules don’t allow service-original operations, but they do allow service-original procedures • A stand-alone simpler operation (such as PUSH-DATA) could be defined in the FW, or the base PROCESS-DATA operation could be simplified and the “TC”-type behavior added by the Data Processing procedure • Once the simpler forward data transfer operation is available in the FW, the procedure based on it could either be contained in the FW itself or created as a service-original procedure in the F-Frame service specification • The issue regarding two prime procedure types has been solved by decision at London meeting

17. Possible Solutions • PUSH-DATA in FW as base operation • Simple Data Processing procedure in FW, or • service-original simple data processing procedure in the service specification • Make PROCESS-DATA simpler • Make Data Processing simpler (using simpler PROCESS-DATA) in FW • Create “TC” Data Processing procedure by extending Data Processing procedure • Need to investigate a transfer buffer to bundle invocations • Need to investigate a more-efficient reporting/notification scheme