[cssm] Thoughts on SICF issues

John Pietras john.pietras at gst.com
Thu May 27 18:59:36 UTC 2021

Erik's summary slide on the SICF issue(s) earlier today sparked the following thoughts.

First, it seems to me that Erik's slide addressed two different topics:

1)     How to carry SICF (or "SICF-like") information in configuration profiles, and

2)     The possible separation of transfer service configuration information from the rest of the space link profile information, such that a single transfer service configuration profile could be used with different space link configuration profiles.

Regarding (1), I think that there's some confusion about what is in the SICF and what is in the FRM definitions for the various SLE transfer service and CSTS provider entities. In short, there is no difference in *content* between the two (or at least, the intention is that there is no difference), the only difference is in the representation - the ad-hoc SICF syntax vs the standard FRM syntax. Maybe that's what everyone understands, but I'm afraid that Holger's example may have muddied the waters regarding the parameters that need to be visible across the cross-support interface (which the "regular" SICF format and the FRMs address) vs how those parameters are also represented internally in the systems on both sides of the cross support interface (which is what Holger's ESTRACK enhanced SICF also contains). It's not clear to me why, if the FRM representation of the SLE and CSTS FRs contain the information that is necessary to schedule those services, it is still thought to be necessary to carry opaque SICF files as part of the configuration profiles. And that's where I'll leave this topic for now.

Regarding topic (2), I first want to confirm what I think is NOT an issue: it is NOT an issue that the transfer service configurations need to be specialized for each ground station. As with the SICF files, each transfer service configuration is "portable" across all ground stations that might execute it, and the station-unique information (such as the TCP socket to access a serviced instance at a given ground station) is recorded in a separate "port registry". The link between the SICF and the port registry is the responderPortIdentifier parameter of the transfer service instance. The responderPortIdentifier parameter is just a string name that serves as the key into the port registry. Note that the content and even the format of the port registry is considered sensitive. The general scheme is as follows:

a)      At the Service Agreement level, the Mission and the Provider agree on which types and how many of each transfer service will be provided, and at which sites. Each of these transfer service instances is given a unique responderPortIdentifier. The Provider generates a port registry with entries for each of the responderPortIdentifiers at each of the supporting sites.  In today's operational environment, the Provider provides the port registry to the Mission.

b)     When a contact (service package in our CSSM terminology) is scheduled at a given site, the Mission uses the responderPortIdentifier parameter for each of the scheduled transfer service instances to access the port registry to identify the TCP socket for that transfer service instance at the schedule site.

So, having said what I think is NOT the concern, here's what I think *IS* the concern - that a Mission might want to use the same transfer service profile (e.g., identifiers, timeout period, latency limit, buffer size, etc.) in conjunction with different space link configurations without having to repeat the definition of the transfer service configuration. E.g., if a Mission uses S-band return sometimes and X-band return other times (mutually exclusively) and for both space link configurations it want to use the *same* RAF service instance, as currently constructed the configuration profiles require both S-Band and X-band configuration profiles contain a specification of the same RAF service instance. In CSSM Blue-1 we had the capability to define one RAF transfer service profile and attach it to either the S-band space link profile or the X-band space link profile, as appropriate. I think that Marcin is asking for a version of that same capability. Marcin, do I understand what you are asking for?

If my interpretation is correct, then we could address this issue by changing the interface of the transfer services from a containment relationship to a provided/required interface, and reorganize the configuration profile structure slightly. I won't elaborate on this any more until I get some confirmation that this is the problem that we're trying to solve.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210527/255a785d/attachment.htm>

More information about the SMWG mailing list