<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:0in;
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:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@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:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@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:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@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:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@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:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@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:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@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:0in;}
ul
{margin-bottom:0in;}
--></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">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>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>How to carry SICF (or “SICF-like”) information in configuration profiles, and<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>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></p>
<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">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>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">a)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>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></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">b)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>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></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">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">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>