Transfer Service Specification Issues

1. Transfer Service Specification Issues CCSDS September 2005 Meeting Atlanta

2. ASN.1 Corrections • F-CLTU was: CltuStartReturn ::= SEQUENCE { performerCredentials Credentials , invokeId InvokeId , result CHOICE { positiveResult [0] SEQUENCE { radiationStartTime Time , radiationStopTime ConditionalTime } , negativeResult [1] DiagnosticCltuStart } }

3. ASN.1 Corrections • F-CLTU shall be: CltuStartReturn ::= SEQUENCE { performerCredentials Credentials , invokeId InvokeId , result CHOICE { positiveResult [0] SEQUENCE { startProductionTime Time , stopProductionTime ConditionalTime } , negativeResult [1] DiagnosticCltuStart } }

4. ASN.1 Corrections • All services state now: SpaceLinkDataUnit ::= OCTET STRING (SIZE (4 .. 65536)) • All services shall state:SpaceLinkDataUnit ::= OCTET STRING (SIZE (1 .. 65536))

5. State Table Issues • Inconsistency return / forward services: 4.2.1.5. The state transition matrix specified in table 4-1 represents one instance of service and thus one association. Once the association is established, if an RAF-BIND invocation for a different association but for the same service instance is received, it shall be rejected with an RAF-BIND return with the result parameter set to ‘negative result’ and the diagnostic parameter set to ‘already bound’. This event shall not affect the association already in place. The state table (‘ready’ and ‘active’ state) in the return services for an incoming BIND invocation simply shows: {peer abort ‘protocol error’} → 1which within the scope of a given association is correct.

6. State Table Issues • Inconsistency return / forward services: On the other hand, we may want to capture in the state table the negative BIND return with the diagnostic ‘already bound’ which however happens on a different association. The forward services attempt that: IF “same service instance” THEN (-fspBindReturn ‘already bound’) ELSE {peer abort ‘protocol error’} → 1 Whatever the preferred approach may be, it shall be applied to all specifications

7. State Table Issues • All return services: For the notification of production status changes, the state table does not show the correct behavior. The notification is unconditionally inserted into the transfer buffer. Instead, the same logic as for the insertion of loss of frame sync has to be applied.

8. Production Status = ‘interrupted’; unspecified latest production time • F-CLTU: FSP specifies in Note 3 following 3.6.2.7.5: If latest-production-time is specified, i.e., it is not ‘null’, the provider will defer the processing of a Packet if the current production-status value is ‘interrupted’ or if the required transmission mode is currently not available. Processing is deferred until either recovery from a temporary problem is accomplished, i.e., the production-status value changes to ‘operational’, or otherwise the latest-production-time would expire (see B3.3). If latest-production-time is unspecified, the provider does not defer the processing of the packet.

9. Production Status = ‘interrupted’; unspecified latest production time • F-CLTU: F-CLTU does not specify the behavior for this case.Strictly speaking, FSP does not specify the behavior either, as this case is only addressed in a not, but not in a requirement.

10. Confliction production time intervals • F-CLTU: F-CLTU does not specify a diagnostic that is appropriate for the case that the production start and/or stop time is earlier than of a previously buffered CLTU.Do we need to add a diagnostic as per FSP?

11. FOP state incompatible with invoked directive • FSP service: • In case a directive cannot be executed because of the present state of the FOP, then the FOP layer returns a reject rather than a negative return to directive. Shall we accommodate that by introducing a new diagnostic in the INVOKE-DIRECTIVE return?

12. Managed(?) Parameters • All return services: In the case of complete online delivery mode, the online frame buffer is intended to overcome limitations of the communications service: bandwidth limitations, outages, and congestion…..The exact size of these buffers is set by service management. Isn’t this rather a provider characteristic?

13. Managed(?) Parameters • All return services: If the online frame buffer becomes full (e.g., because an extended communications outage prevents it from being emptied), the provider shall discard Raf­Transfer­Data­Invocation and Raf­Sync­Notify­Invocation records from the online frame buffer in oldest-first order. The number of frames to be discarded in such event is set by service management. Isn’t it sufficient to make this a documented provider characteristic?

14. Managed(?) Parameters • All return services: During complete online service provision, the RAF service provider shall extract Raf­Transfer­Data­Invocation and RafSyncNotify records from the online frame buffer, insert them into the transfer buffer, and pass RafTransferBuffer SLE-PDUs to the communications service without undue delay, subject only to limitations imposed by the underlying communications service, or to any maximum data rate limitation (‘metering’) that may be imposed through service management. Is there any implementation that actually implements ‘metering’ (except on the router and/or the ultimate data sink)? Shall that then be subject to SM?

15. Managed(?) Parameters • All return services: • The SIs as used today support constraining of the frame quality. However, a parameter ‘permitted-frame-quality is presently not accessible via the GET operation. That appears to be inconsistent with e.g. RCF, where the permitted GVCID list can be obtained. • Do we anticipate an SM role as regards managing the private annotation as bilaterally agreed?

16. Managed(?) Parameters • All forward services: • Is there any need to get SM involved in constraining the expected-cltu-identification? • Is there any need to get SM involved in constraining the expected-event-invocation-identification? • Is there any concern on the SM side as regards support of the THROW-EVENT operation and the associated management actions?

17. Managed(?) Parameters • All services: • The need may arise for actions that need to be taken by local operations personnel, e.g., to recover from production status = ‘interrupted’. This may be seen as part of Complex Management, but is outside the scope of SM. Shall we introduce new language in the Transfer service specifications that makes such distinction clear? • The range of the reporting cycle parameter can be constrained by SM. That appears not to be covered by Yves’ note. Is it covered in SM?

18. User-Side State Machine • All services: • Is there a need to add a user-side state machine to the Transfer-Service Specifications? • If yes, shall / can it be normative or informative?