[cssm] [EXTERNAL] Re: Thoughts on SICF issues

Fri May 28 20:40:42 UTC 2021

I am probably being (intentionally) dense here, but why is SICF even a subject for CCSDS discussion?  It is not defined in any CCSDS literature that I know  of  and it is not in the CCSDS abbreviations.  AFAIK it is a JPL local file type.  Why isn’t this strictly a “local matter”?

Thanks, Peter

From: SMWG <smwg-bounces at mailman.ccsds.org> on behalf of "Marcin.Gnat at dlr.de" <Marcin.Gnat at dlr.de>
Date: Friday, May 28, 2021 at 1:34 AM
To: John Pietras <john.pietras at gst.com>
Cc: SMWG <smwg at mailman.ccsds.org>
Subject: [EXTERNAL] Re: [cssm] Thoughts on SICF issues

Hi John,

My comments below in red.

Best Regards & have a good weekend
Marcin

From: John Pietras <john.pietras at gst.com>
Sent: Donnerstag, 27. Mai 2021 21:00
To: Gnat, Marcin <Marcin.Gnat at dlr.de>
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>; Holger.Dreihahn at esa.int
Subject: Thoughts on SICF issues

All,
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.

[Marcin] Possibly you are right with Holger’s examples mudding the water, but on the other hand I saw from these examples potential to be used as “normal” SICF format as well. So probably we are here not far off.

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:

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

[Marcin] This is correct, at least to the point, when we assume, that the only station specific element is Port Identifier. However until now, all service instances I saw in last 11 years, used the Service Instance ID (SIID) which contained some kind of station identification as well. And the SIID is inside of SICF, thus makes it station-unique. The problem with SIID is, that it’s kind of not clear what is it. Initially I thought It is just an ID. Later I learned, it has to be specifically formatted (“sagr=” etc.) and finally it seems even the values which follow after “=” in SIID are being processed in specific way by specific agencies. Thus at the end, we are effectively completely bound to very specific, very unique SIID form.

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?

[Marcin] That is correct, this is exactly my “issue”. To give another example, missions often have just 2 or 3 space link configurations, but than 5-7 different transfer service configurations, of which maybe 2 are really used normally, but the rest is kind of there. Keeping such setup separated and allow it being combinable (3 space link configs and 7 transfer service configs) is easier to maintain and more flexible. For example it is possible during a space link session to switch between two different transfer sessions by changing the transfer config. In opposition, if we keep everything in one config profile, we would need in total 21 configurations (aaaahhhhrg!) and on-the-fly switching would be cumbersome.

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.

[Marcin] I think I get what you mean, and yes, this may work, as long as the provided/required interface would be than defines in physically separate Information Entity (i.e. another Configuration Profile containing transfer service configuration only).

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210528/2076bff4/attachment-0001.htm>