<font size=2 face="sans-serif">Hi Erik,</font>
<br><font size=2 face="sans-serif">The security and access aspect is certainly
important, already today. For ESTRACK the notion of permanent SICFs or
permanent configuration just means that the configuration is not changed
per pass. It does not mean it is permanently available available. In fact
we use something similar to the Simple Schedule of Services to load and
activate during pass time the permanent configuration for the mission(s)
using the station. If someone tries to access e.g. an SLE SI outside the
agreed pass, not even the SLE BIND will not work.</font>
<br>
<br><font size=2 face="sans-serif">I am sure NASA/DSN does something similar.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,<br>
Holger</font>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | H-293<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Barkley, Erik
J (US 3970)" <erik.j.barkley@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int>, "Marcin.Gnat@dlr.de" <Marcin.Gnat@dlr.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"SMWG" <smwg-bounces@mailman.ccsds.org>,
"smwg@mailman.ccsds.org" <smwg@mailman.ccsds.org>, "Anthony
Crowson" <anthony.crowson@telespazio.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">11/02/2021 19:50</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">RE: [EXTERNAL]
Re: [cssm] SACP: configuration of tranfer services</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 face="Georgia">Just to add a quick comments to this thread,
the DSN also employs permanent SICFs for SLE instance configurations. Much
like what Colin has indicated the implementers complained that it was just
too much trouble to deal with dynamic SICFs as that would involve more
testing and more things could go wrong, etc. However given the changing
cyber security landscape I would ask if, eventually, can you afford not
to have dynamically generated SICFs or some other equivalent such that
access is very much controlled on a tracking pass by tracking pass basis
– especially if you are supporting human spaceflight? I think it
is something we should keep an eye on.</font>
<br><font size=3 face="Georgia"> </font>
<br><font size=3 face="Georgia">Best regards,</font>
<br><font size=3 face="Georgia">-Erik</font>
<br><font size=3 face="Georgia"> </font>
<br><font size=3 face="sans-serif"><b>From:</b> SMWG <smwg-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Holger.Dreihahn@esa.int<b><br>
Sent:</b> Wednesday, February 10, 2021 23:45<b><br>
To:</b> Marcin.Gnat@dlr.de<b><br>
Cc:</b> SMWG <smwg-bounces@mailman.ccsds.org>; smwg@mailman.ccsds.org;
Anthony Crowson <anthony.crowson@telespazio.de><b><br>
Subject:</b> [EXTERNAL] Re: [cssm] SACP: configuration of tranfer services</font>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="Arial">Hi Marcin,</font><font size=3 face="sans-serif">
</font><font size=3 face="Arial"><br>
I remember having implemented SLE SICF generation for our scheduling system
(2008?) and I think we have put some thinking in how to do that. As Colin
correctly remarks, the feature of pass specific SICFs is not used - simply
too many files.</font><font size=3 face="sans-serif"> <br>
</font><font size=3 face="Arial"><br>
However, the trick at the time was to distribute the information for SLE
SICF creation to the two relevant places: The mission agreement with the
(SLE) service requirements and the ground station model with the ground
station capabilities (amongothers the SLE services supported formulated
as templates). The two are used for determine 'does the station have the
required capabilities' and then to combine the information as shown below
to the configuration (slide 45 of attachment):</font><font size=3 face="sans-serif">
<br>
<br>
<br>
</font><img src=cid:_2_7D44B7787D44AF280028E254C125867A width=1381 height=339 style="border:0px solid;"><font size=3 face="Arial">
</font><font size=3 face="sans-serif"> <br>
<br>
</font><font size=3 face="Arial"><br>
Some background: Our scheduling is service based, so in addition to the
SLE services we define the underlying production services as operational
services (TM, TC, DDOR, Ranging, etc.), which are required (mission agreement)
and matched with station capabilities (station model). Those production
services are in fact subject to configuration profiles, which can be refined
by missions per pass or requested service.</font><font size=3 face="sans-serif">
</font><font size=3 face="Arial"><br>
In orinciple the complete configuration profiles could be defined by FRM
parameters.</font><font size=3 face="sans-serif"> <br>
</font><font size=3 face="Arial"><br>
I know it's not exactly what you discuss, but maybe of some interest.</font><font size=3 face="sans-serif">
<br>
</font><font size=3 face="Arial"><br>
Best regards,</font><font size=3 face="sans-serif"> </font><font size=3 face="Arial"><br>
Holger</font><font size=3 face="sans-serif"> <br>
<br>
<br>
</font><font size=3 face="Arial"><br>
Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | H-293<br>
+49 6151 90 2233 | </font><a href="https://urldefense.us/v3/__http:/www.esa.int/esoc__;!!PvBDto6Hs4WbVuu7!cUFMLvyNBxsXjIEqxu_xPyOODmdz7sNc8DmT2jFOhzJdaKN8-vi73Ny7pJZjU4K_DJAqVlE$"><font size=3 color=blue face="Arial"><u>http://www.esa.int/esoc</u></font></a><font size=3 face="sans-serif">
<br>
<br>
<br>
</font><font size=3 color=#5f5f5f face="Arial"><br>
From: </font><a href=mailto:Colin.Haddow@esa.int><font size=3 color=blue face="Arial"><u>Colin.Haddow@esa.int</u></font></a><font size=3 face="sans-serif">
</font><font size=3 color=#5f5f5f face="Arial"><br>
To: </font><font size=3 face="Arial">"Anthony
Crowson" <</font><a href=mailto:anthony.crowson@telespazio.de><font size=3 color=blue face="Arial"><u>anthony.crowson@telespazio.de</u></font></a><font size=3 face="Arial">></font><font size=3 face="sans-serif">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Cc: </font><font size=3 face="Arial">"SMWG"
<</font><a href="mailto:smwg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Arial"><u>smwg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Arial">>,
"</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="Arial"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="Arial">"
<</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="Arial"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="Arial">></font><font size=3 face="sans-serif">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Date: </font><font size=3 face="Arial">10/02/2021
18:46</font><font size=3 face="sans-serif"> </font><font size=3 color=#5f5f5f face="Arial"><br>
Subject: </font><font size=3 face="Arial">Re:
[cssm] SACP: configuration of tranfer services</font><font size=3 face="sans-serif">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Sent by: </font><font size=3 face="Arial">"SMWG"
<</font><a href="mailto:smwg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Arial"><u>smwg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Arial">></font><font size=3 face="sans-serif">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="sans-serif"><br>
<br>
<br>
Hi Marcin, Anthony, <br>
ESOC has effectivly
moved to permanent SICfs. The NIS (Neywork Interface System - Handles MCS
- Groundstation SLE links) was designed to be able to use dynamic as well
as permanent SICFs and the missions screamed about the prospect of having
to use dynamic ones, much preferring to use permanent ones. <br>
<br>
Cheers for now, <br>
<br>
Colin <br>
<br>
<br>
---------------------------------------------------------------------------------------------------------<br>
Dr. Colin R. Haddow,<br>
HSO-GI, European Space Agency,<br>
European Space Operations Centre,<br>
Robert-Bosch-Str 5,<br>
64293 Darmstadt,<br>
Germany.<br>
<br>
Phone; +49 6151 90 2896<br>
Fax; +49 6151 90 3010<br>
E-Mail; </font><a href=mailto:colin.haddow@esa.int><font size=3 color=blue face="sans-serif"><u>colin.haddow@esa.int</u></font></a><font size=3 face="sans-serif"><br>
---------------------------------------------------------------------------------------------------------<br>
<br>
<br>
</font><font size=3 color=#5f5f5f face="sans-serif"><br>
<br>
From: </font><font size=3 face="sans-serif">"Anthony
Crowson" <</font><a href=mailto:anthony.crowson@telespazio.de><font size=3 color=blue face="sans-serif"><u>anthony.crowson@telespazio.de</u></font></a><font size=3 face="sans-serif">>
</font><font size=3 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=3 face="sans-serif">"</font><a href=mailto:Marcin.Gnat@dlr.de><font size=3 color=blue face="sans-serif"><u>Marcin.Gnat@dlr.de</u></font></a><font size=3 face="sans-serif">"
<</font><a href=mailto:Marcin.Gnat@dlr.de><font size=3 color=blue face="sans-serif"><u>Marcin.Gnat@dlr.de</u></font></a><font size=3 face="sans-serif">>,
"</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="sans-serif"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="sans-serif">"
<</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="sans-serif"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="sans-serif">>
</font><font size=3 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=3 face="sans-serif">10/02/2021
18:23 </font><font size=3 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=3 face="sans-serif">Re:
[cssm] SACP: configuration of tranfer services </font><font size=3 color=#5f5f5f face="sans-serif"><br>
Sent by: </font><font size=3 face="sans-serif">"SMWG"
<</font><a href="mailto:smwg-bounces@mailman.ccsds.org"><font size=3 color=blue face="sans-serif"><u>smwg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="sans-serif">>
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="sans-serif"><br>
</font><font size=3 color=#004080 face="sans-serif"><br>
Hi Marcin,</font><font size=3 face="sans-serif"> </font><font size=3 color=#004080 face="sans-serif"><br>
</font><font size=3 face="sans-serif"> </font><font size=3 color=#004080 face="sans-serif"><br>
As I would see it, and as I think we had it in the old Blue-1 book, the
service instance identifiers and the parameters you feel are missing are
part of the service package, not the SA or CP. Your 3 spacecraft configurations
would be 3 configuration profiles. The SP request may identify a specific
station or antenna; at any rate, the SP itself will identify the aperture
and the service instances, and at least port IDs. <br>
There was a discussion which I don’t think was ever fully resolved, about
service instance identifiers. The original concept had them being dynamically
defined for each service package. But the “stop-gap” SICF approach ended
up with people getting used to “permanent” SI IDs and being reluctant
to change that. Certainly I think it would be unhelpful to have to reproduce
the same config multiple times just to use different SI IDs for different
apertures. <br>
Basically what you suggest in your second and third bullets looks about
right, modulo discussion on permanence of SI IDs.</font><font size=3 face="sans-serif">
</font><font size=3 color=#004080 face="sans-serif"><br>
</font><font size=3 face="sans-serif"> </font><font size=3 color=#004080 face="sans-serif"><br>
I think the FRM parameters identified as just “reporting” mean they cannot
be changed during production. Clearly they have to be set somewhere, i.e.
“by management”, as part of setting up the service packages.</font><font size=3 face="sans-serif">
</font><font size=3 color=#004080 face="sans-serif"><br>
</font><font size=3 face="sans-serif"> </font><font size=3 color=#004080 face="sans-serif"><br>
Anthony</font><font size=3 face="sans-serif"> </font><font size=3 color=#004080 face="sans-serif"><br>
</font><font size=3 face="sans-serif"> <b><br>
From:</b> SMWG <</font><a href="mailto:smwg-bounces@mailman.ccsds.org"><font size=3 color=blue face="sans-serif"><u>smwg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="sans-serif">>
<b>On Behalf Of </b></font><a href=mailto:Marcin.Gnat@dlr.de><font size=3 color=blue face="sans-serif"><u>Marcin.Gnat@dlr.de</u></font></a><font size=3 face="sans-serif"><b><br>
Sent:</b> 26 January 2021 15:32<b><br>
To:</b> </font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="sans-serif"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="sans-serif"><b><br>
Subject:</b> [cssm] SACP: configuration of tranfer services <br>
</font>
<div align=center><font size=3 color=white face="sans-serif">- <b>CAUTION:
</b>This message was sent from outside of Telespazio Germany. Please do
not click links or open attachments unless you recognize the source of
this email and know the content is safe. Please report all suspicious emails
to "</font><a href=mailto:support@telespazio.de><font size=3 color=blue face="sans-serif"><u>support@telespazio.de</u></font></a><font size=3 color=white face="sans-serif">"
as an attachment. -</font></div>
<br><font size=3 face="sans-serif"><br>
Dear SMWG, <br>
<br>
In course of some implementation work and discussion with my developers,
I came to the point where I think we shall have some closer discussion
soon (in one of our teleconferences and definitely later during spring
meetings). <br>
<br>
The protagonist: configuration (profile) of the transfer service (known
currently under nicknames “SLE configuration” or “SICF”). <br>
<br>
The place and time: somewhere in snowy Bavaria during Winter 2020/2021,
Corona situation. <br>
<br>
The Synopsis: during implementation of VEEEEEERY remotely similar profiles
into DLR’s new scheduling system, my developers asked me how they shall
treat the Service Instance Identifiers in the profile. When I looked at
their initial implementation, I noticed, that they did put the complete
configuration (service) profile in “one piece”, according to the current
list from FRM and to what I told them. It does not correspond to the full
flexibility of the actual planned SACP (this was not the intention). Anyhow,
I realized two things: </font>
<p><a name="Gruß"></a><font size=3><br>
1. Not all of SLE parameters were there (GVCID,
Port and User identifiers, etc…) <br>
2. Defined as such now, projects would need
to define multiple configuration profiles, being actually the same, differing
only with Service Instance Identifier, for each Service Instance. In our
case, for example for TerraSAR mission, we have actual 3 spacecraft configurations
for the antenna, but in total 32 service instances for different stations,
antennas and cortexes. This maybe does not multiply 1x1, but at least we
would need 32 configuration profiles (I can almost hear the project people
coming to get me)! <br>
<br>
Okay, this is to some extent my own fault, as I burdened the implementation
of “some kind of configuration profile” to my developers, and maybe did
not thought about it in front. But it shows I think also some shortcomings
we have with the concept (maybe it will shape up still). <br>
<br>
To the first point, I quickly noticed, that – even I made a list of parameters
based on FRM – actually not all parameters are really exposed. When looking
to the export of Holger out of FRM and the schema files, I noticed than
there is number of parameters which are marked only as “reporting” thus
in first place not visible to SACP (hence my omission). And so, all Initiator
and Responder Id’s as well as PortId’s and the GVCID’s are marked as
“reporting” or “read-only” if you like. How are we going to set them?
<b>Shouldn’t they be also configurable, similar like Service Instance
ID?</b> <br>
<br>
From this: <br>
</font><img src=cid:_4_7F573EE8726048300028E254C125867A style="border:0px solid;"><font size=3><br>
<br>
To this: <br>
</font><img src=cid:_4_7F574240726048300028E254C125867A style="border:0px solid;"><font size=3><br>
<br>
Second topic is the actual (operational) separation of the antenna configuration
and the transfer services configuration. Currently (at least at DLR) this
looks like this: <br>
</font><img src=cid:_4_7F574638726048300028E254C125867A style="border:0px solid;"><font size=3><br>
<br>
There are few antenna configurations (which may be effectively also identical
throughout different antennas) and number of SLE configurations (Service
Instances). To be fully honest, the multiplication of the SLE config is
just due to the different Responder ID and Port ID’s, resulting also in
separate Service Instance ID, the rest of the config is typically the same
(for a specific RCF or FCLTU service). <br>
<b><br>
How do we want to handle that with our current concept of SACP?</b> <br>
<br>
I know we had some brief discussions on that, and there is some three page
(chapter 3.4.2) information on intended use in the TechNote of John. It
speaks relatively high level about two options, reusing SICF files (kind
of an extension to the actual SACP config) and also by dynamically setting
the abovementioned parameters. <br>
<br>
First option says, that SICF files shall be there, and the Responder and
Provider ID’s and Ports shall be fixed in Service Agreement and for specific
Site and Mission, and later on only these shall be used. It does not actually
however says anything on how actual SICF is bound to the specific Service
Package nor Service Package Request nor Configuration Profile. We have
Ports and their ID’s, but how do I know which SICF shall I use? Shall
there be also predefined ONE fixed SICF? <br>
<br>
Second option of using the extended/abstract parameters in Service Package
may allow for dynamic provision of the so called “scheduledSocket”
which would be just the ProviderPort. So far so good, but still I miss
the rest of the SLE/CSTS configuration, especially wrt to what I wrote
above. <br>
<b><br>
Here is where the I lost the trace of the hunted game. And maybe we need
here some discussion. ?</b> <br>
<br>
I was thinking – just to came into with some proposal – of the following
(better ideas are welcome!): <br>
<br>
- To not destroy everything else we already
somehow managed to set up wrt SMURF, SPDF and SACP… <br>
- …We could use extended list (as at
the beginning) in the Service profile, with Service Instance ID, PortID’s,
GVCID’s etc., having predefined some parameters (i.e. Buffer sizes), whereas
leaving all of these “variable ones” undefined. That way we would have
limited number of Configuration Profiles (a set of few generic ones for
the spacecraft, universally engageable in every station). <br>
- When booking the Service Package (sending
the Request) we could “overwrite” the previously mentioned parameters
using AbstractParameter Class (for example “InitiatiorID” and “ServiceInstanceID”
and “GVCID”). The same would be true for SPDF – the values there would
be shown in AbstractParameter class (and for example additionally station
defined PortID would be provided). This would allow to use all of our Books
/ Formates as they are, and have individual SLE configuration for each
pass/service package. <br>
- The disadvantage of the above method
would be, that there would need to be some kind of automated generation
of Service Instance ID and GVCID on user side and the ProviderPort on provider
side. Otherwise we come into danger of crazy users/providers not filling
these parameters, or filling them wrongly or even filling them different.
<br>
<br>
Okay… I’m done for today ? <br>
<br>
Cheers <br>
Marcin</font><font size=3 face="Courier New">_______________________________________________<br>
SMWG mailing list</font><font size=3 color=blue face="Courier New"><u><br>
</u></font><a href=mailto:SMWG@mailman.ccsds.org><font size=3 color=blue face="Courier New"><u>SMWG@mailman.ccsds.org</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg__;!!PvBDto6Hs4WbVuu7!cUFMLvyNBxsXjIEqxu_xPyOODmdz7sNc8DmT2jFOhzJdaKN8-vi73Ny7pJZjU4K_oOrp91M$"><font size=3 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</u></font></a><font size=3>
</font>
<p><font size=3 face="Courier New">This message is intended only for the
recipient(s) named above. It may contain proprietary information and/or<br>
protected content. Any unauthorised disclosure, use, retention or dissemination
is prohibited. If you have received<br>
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect<br>
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (</font><a href=mailto:dpo@esa.int><font size=3 color=blue face="Courier New"><u>dpo@esa.int</u></font></a><font size=3 face="Courier New">).<br>
_______________________________________________<br>
SMWG mailing list</font><font size=3 color=blue face="Courier New"><u><br>
</u></font><a href=mailto:SMWG@mailman.ccsds.org><font size=3 color=blue face="Courier New"><u>SMWG@mailman.ccsds.org</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg__;!!PvBDto6Hs4WbVuu7!cUFMLvyNBxsXjIEqxu_xPyOODmdz7sNc8DmT2jFOhzJdaKN8-vi73Ny7pJZjU4K_oOrp91M$"><font size=3 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</u></font></a>
<br><font size=3 face="Courier New">This message is intended only for the
recipient(s) named above. It may contain proprietary information and/or</font>
<br><font size=3 face="Courier New">protected content. Any unauthorised
disclosure, use, retention or dissemination is prohibited. If you have
received</font>
<br><font size=3 face="Courier New">this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures
to protect</font>
<br><font size=3 face="Courier New">personal data, in case of data privacy
queries, please contact the ESA Data Protection Officer (</font><a href=mailto:dpo@esa.int><font size=3 color=blue face="Courier New"><u>dpo@esa.int</u></font></a><font size=3 face="Courier New">).</font>
<br>
<br>
<PRE>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</PRE>