[Css-csts] Frame Status Report (FSR)-related SLE PIDs

[John Pietras]

Ignacio, Howie, and Greg,
The SLS review of the proposed SLE Blue Book updates resulted in several PIDs that centered on the absence of the presence of FSRs in Operational Control Fields (OCFs). The CSTSWG will be taking up these PIDs in the next few weeks. In order for the WG to have the best understanding of the concerns, there are a few questions that I hope you can provide further information about the intended use of FSRs in the context of the SLE services.

The FSR-related PIDs involve both the SLE Return OCF (ROCF) and SLE Forward-CLTU (FCLTU) services.


A.     With respect to the ROCF service, PIDs ROCF-02 (GK-13) through ROCF-05 (GK-16) all deal with various instances where the document identifies CLCWs but not FSPs as the "payload" of the OCF.

1.      The RIDs are all along the lines of "the use of FSRs needs to be addressed", but no specific changes are identified.  What different processing or filtering of the OCFs when they contain FSRs needs to be performed? If it is simply a matter of sending every FSP to the user of the ROCF service instance, that is essentially present in the current ROCF specification. If some sort of FSR-specific filtering/selection is required or desired, the CSTSWG needs to know what those filtering criteria are. For  example, when the OCF payload is a CLCW, the ROCF service instance can be configured to deliver the OCF/CLCWs for either a single TC VCID or for all TC VCIDs.

2.      The original motivation for the ROCF service was to provide a means for returning the CLCWs to the MOC so that COP could be closed in situations where there was  terrestrial bandwidth for returning the downlink frames to the MOC was significantly less than the space-to-ground link BW, or even when the transfer frames were being recorded for subsequent off-line delivery. Does such a use case exist for FSRs? That is to say, will there be anticipated cases where *only* the FSRs will be delivered, and not the whole frames? Alternatively, might there be a use case where the FSRs need to be delivered to somewhere other than the recipient of the return link transfer frames (which would be another justification for the use of the ROCF service to deliver FSRs)? If neither is a use case, then the ROCF may not be a candidate for FSR delivery. Just because the ROCF service *can* deliver anything that is contained in an OCF does not necessarily mean that any particular use of the OCF is a reasonable use of the ROCF service.



B.     With respect to the FCLTU service, PIDs IAS-01 through IAS-03 imply that the FCLTU service should use information in the FSRs to regulate transmission on the forward link in the same way that the FCLTU service currently regulates transmission on the basis of the the NoRFAvail and NoBitLock flags in the CLCW (whether the FCLTU service does or doesn't such regulation, and whether such regulation is based on either or both of these flags, is a configured parameter). These CLCW flags report the status of the whole physical link, so it is reasonable to deduce that if either flag indicates a "no flow" condition nothing is getting through the link. However, it is my understanding (and please correct me if I am wrong) that the security associations are (or may be) established on a per VC basis, and indeed a physical channel may carry a mix of SDLP-protected and non-SDLP-protected VCs. In such situations, it seems possible that a security associated for one or a subset of VCs may be in an errored state, but other VCs may be operating without problem. In such a case, it would seem unwise to have FCLTU shut down the whole forward link (Note that the FCLTU service "sees" only encoded CLTUs - it has no knowledge of the VCs of the frames encoded in those CLTUs).

I hope these questions and observations are a contribution to the discussions on the possible effects of FSRs on the ROCF and FCLTU service.

Best regards,
John

John Pietras
Global Science & Technology, Inc. (GST)
7501 Greenway Center Drive, #1100
Greenbelt, MD 20770
240-542-1155

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20211014/e351c287/attachment.htm>