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

[John Pietras]

All,
The SLS review of the proposed SLE Blue Book updates resulted in several PIDs that focused on the presence of FSRs in Operational Control Fields (OCFs). The CSTSWG will be taking up these PIDs next week.

In order for the WG to have the best understanding of the concerns, I sent an email to several of you on 13 October containing several questions about the intended use of FSRs in the context of the SLE services. I received comments from Greg Kazz (GK) on 14 October and from Craig Biggerstaff (CTB) on 18 October. I had a follow-up conversation with Craig on Tuesday (19 October).

Following is the compilation of the original message, Greg’s comments (2021-10-14 GK), Craig’s comments (2021-10-18 CTB), and a summary of my conversation with Craig (2021-10-19 CTB & JP).

Best regards,
John

-------------------------------------

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


  1.  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.

2021-10-14 GK: FSRs are generated on a VCID basis. Some VCs will have them and some possibly won’t. So it makes sense to be able to filter on VCID i.e., one or more VCIDs which make up an SLS Security Association.


2021-10-18 CTB:  Not having ever actually used the ROCF service, it seems logical to deliver all OCFs arriving on the requested VCID(s).  The recipient always has the option of discarding extraneous data.
·        It would be possible to modify the ROCF API to specify requested OCF type(s) – CLCW/FSR/both.  I don’t know the potential benefit of making that change, much less the impact of perturbing what exists now.  It’s as likely that CLCW subscribers would like the ability to filter out the ‘noise’ of FSRs, as the reverse.
·        The only use case for filtering FSRs by VCID would be the scenario where multiple sources (e.g. MOC vs. POC) multiplex frames into the same master channel for uplink.

2021-10-19 CTB & JP: Some additional information about the ROCF service is helpful here. As described in the following bullet (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. Related to the COP, the CLCW contains the VCID of the forward link VC through which the COP is operating. The COP model that the ROCF service is based on assumes that the space vehicle is designed to receive AD frames on one or more forward link VCs, and send the corresponding CLCWs on a specific return link VC or MC. Depending on the number of return link VCs and their relative frequency of transmission, the CLCWs may be able to be sent on a single VC or may have to be sent on all frames of an MC. Also, the CLCWs for multiple forward link VCs, may be returned on the same VC or MC or different VCs or MCs, depending on the design of the spacecraft data system.

To accommodate these various possibilities, when a given ROCF service instance is configured, the configuration information for that service instance includes (1) whether the service instance is *permitted* to return Type 0 (CLCWs), Type 1 (“other”, which includes FSRs) OCFs, or both types (2) the set of return link VCs or MCs from which OCFs are *permitted* to be extracted, and (3) the set of forward link VCIDs (as presented in the CLCW) for which the service instance is *permitted* to return the CLCWs (applies only when CLCWs are being returned). Then, when each ROCF service instance is STARTed, the START invocation identifies (a) which of the permitted OCF types is to be returned, (b) which of the permitted return link VCs or MCs to extract the OCFs from, and (c) for CLCWs only, which of the permitted forward link VCID the OCFs are to be returned (this can be set to ‘null’, which returns the CLCWs regardless of the VCID the appears in the CLCW).

In using the ROCF service to return FSRs, each ROCF service instance can be configured to extract OCFs from one or more VCs or MCs. However, there is no static information identifying the forward link source of the secured data in the FSR that is comparable to the VCID field of the CLCW. I had considered that the Security Parameter Index (SPI) field of the FSR could be used to identify the Security Association (SA), but Craig explained to me that the SA (and therefore the SPI) will very possibly (and maybe likely) change during the course of the contact.

Craig and I concurred that if the ROCF service is used to transfer the FSRs, it should be sufficient for the FSR user of the ROCF service to get all FSRs that are returned on a given return link VC or MC. This is exactly what the ROCF service already supports, under the “other” option for OCF selection. There is no need to change the technical aspects of the ROCF service. However, we agreed that it would be appropriate to add *informational* content (e.g., NOTEs) that address the use of the ROCF service to transfer FSRs.



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.

2021-10-14 GK: NASA/JPL for example does not use the ROCF service because we don’t have that severe of a ground station to MOC BW issue – not sure of other agency or NASA center limitations.


2021-10-18 CTB:  The purpose of the FSR is to report errors encountered by the receiving end of an uplink.  The intended recipient of downlink FSRs is the same location that originated those uplink frames.
·        The FSR is associated with one and only one uplink channel.  It doesn’t make sense to return the FSR using a downlink channel other than the one corresponding to that uplink.  E.g. a downlink-only payload channel would have no need of FSRs.
·        But in the above scenario where multiple sources multiplex frames into the same master channel for uplink, a VC Frame service user could want to receive the FSRs corresponding to its uplink VCIDs.  (Would this also hold true for a CSTS Forward Channel Frame service?  I’m guessing it would.)

2021-10-19 CTB & JP: The intent of the question that I posed in the original email was to ascertain whether it makes sense operationally for a mission ground entity (e.g., a MOC or payload control center) to receive “stand-alone” FSRs – that is, would there be use cases in which a facility would *not* be receiving the full frames that carry the OCF/FSRs. Based on my conversation with Craig, I think that there potentially is such a use case: e.g., consider a scenario in which the spacecraft is configured to return FSRs corresponding to all of the forward link VCs in every frame of the return link MC. Depending on the onboard application, there may not be any data generated by the application if the SA fails, and the ground application that receives the VCs carrying that application data won’t get any VC frames for that VC, and so no OCF/FSRs would be inserted in that return link VC. However, because the FSRs are carried by every VC in that MC, the FSR information fror that forward link SA would be carried in the frame of any return VC of that MC, and so the ROCF service can be used to obtain the status of the SA.

However, as described in 1A above, it is not possible to identify the forward link VC that is carrying the SA from the information available in the FSR. The only way to make such an identification for purposes of filtering the OCFs transferred by an ROCF service instance is if the spacecraft uses a different return link VC or MC for each forward link VC, such that the OCF/FSRs of a given return VC or MC contain only the FSRs of its peer forward link VC. In such a case, the ROCF service instance can be configured to transfer the OCF/FSRs that appear on that specific VC or MC. As described above, this is already within the capability of the ROCF service, and no technical changes need to be made to the ROCF service.




  1.  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).

2021-10-14 GK: I share your concern here, John.

2021-10-18 CTB:  I agree.  The FSR is forensic data to aid in troubleshooting link security failures; it does not prescribe any specific action in response.

2021-10-19 CTB & JP: Craig and I concurred that the FSRs should not be used by the production functions underlying the F-CLTU service to automatically inhibit transmission on  the forward link, especially since it would close off all VCs on the link, not just the one that has a problematic SA. A mission *may* choose to stop transmitting using a given VC by using the status information in the FSRs that are present in the return link transfer frames or the OCFs obtained through an instance of the ROCF service. There is no need to make any changes to the F-CLTU service.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20211022/863e249b/attachment-0001.htm>