<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1118990655;
mso-list-type:hybrid;
mso-list-template-ids:378841730 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:2127888462;
mso-list-type:hybrid;
mso-list-template-ids:802741926 67698711 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span lang="DE">Hi John,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal">My comments below in <span style="color:red">red.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best Regards & have a good weekend<o:p></o:p></p>
<p class="MsoNormal">Marcin<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>From:</b> John Pietras <john.pietras@gst.com> <br>
<b>Sent:</b> Donnerstag, 27. Mai 2021 21:00<br>
<b>To:</b> Gnat, Marcin <Marcin.Gnat@dlr.de><br>
<b>Cc:</b> CCSDS SMWG ML (smwg@mailman.ccsds.org) <smwg@mailman.ccsds.org>; Holger.Dreihahn@esa.int<br>
<b>Subject:</b> Thoughts on SICF issues<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">All,<o:p></o:p></p>
<p class="MsoNormal">Erik’s summary slide on the SICF issue(s) earlier today sparked the following thoughts.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">First, it seems to me that Erik’s slide addressed two different topics:<o:p></o:p></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo2">How to carry SICF (or “SICF-like”) information in configuration profiles, and<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo2">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.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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 *<b>content</b>* 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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:red">[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.
<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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 <span style="font-family:"Courier New"">responderPortIdentifier</span> parameter of the transfer service instance. The
<span style="font-family:"Courier New"">responderPortIdentifier</span> 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:<o:p></o:p></p>
<ol style="margin-top:0cm" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level1 lfo4">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 <span style="font-family:"Courier New"">responderPortIdentifier.</span> The Provider generates a port registry with entries for each of the
<span style="font-family:"Courier New"">responderPortIdentifier</span>s at each of the supporting sites. In today’s operational environment, the Provider provides the port registry to the Mission.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level1 lfo4">When a contact (service package in our CSSM terminology) is scheduled at a given site, the Mission uses the
<span style="font-family:"Courier New"">responderPortIdentifier</span> 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.
<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:red">[Marcin] This is correct, at least to the point, when we assume, that the only station specific element is Port Identifier. However until now,
<u>all</u> 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.
<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So, having said what I think is NOT the concern, here’s what I think *<b>IS</b>* 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 *<b>same</b>* 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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:red">[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.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:red">[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).<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">John<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>