<span style=" font-size:10pt;font-family:sans-serif">Thanks Peter,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">yes, makes sense
to me and seems to be a pragmatic way forward:</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- FRM providing
a way to describe parameters, directives and events (I think it is something
we will should do for ground nodes anyway and I would expect space nodes
to be very similar).</span>
<br><span style=" font-size:10pt;font-family:sans-serif">- specific implementation
could be agency-specific initially (based on EDS or not) until a inter
operable protocol is defined (for terrestrial use we could even use CSTS
Monitored Data / Control during that time) </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">The security topic
is, of course, a major one and it keeps coming up in different contexts
again and again (Mars communication, Lunar Communication Networks). We
are currently discussing internally how to address it and will come forward
with some proposal.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Regards,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Felix</span>
<br>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Shames,
Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Felix.Flentge@esa.int"
<Felix.Flentge@esa.int></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"Wilmot,
Jonathan J. (GSFC-5820)" <jonathan.j.wilmot@nasa.gov>, "Ramon
Krosley" <r.krosley@andropogon.org>, "Barkley, Erik J (US
3970)" <erik.j.barkley@jpl.nasa.gov>, "Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)"
<john.pietras@gst.com>, "Pham, Timothy T (US 3300)" <timothy.t.pham@jpl.nasa.gov>,
"Keith Scott" <kscott@mitre.org>, "Tomaso.deCola@dlr.de"
<Tomaso.deCola@dlr.de>, "SEA-SA" <sea-sa@mailman.ccsds.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">13/12/2021
23:19</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Re:
[EXTERNAL] Re: [Sea-sa] Second cut at CSS FRM and SOIS EDS integration
approach</span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Hi
Felix,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Thanks
for engaging in this discussion. It is really important to get diverse
viewpoints heard, so I appreciate it.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Glad
you found the FRM and EDS discussion to be useful. When I dug into
this there was clearly an overlap, or at least a point where they “touch”,
but I think they are sufficiently separate in purpose, and yet aligned
at “touch points”, that we can just integrate them by using the same
terms in the same way where appropriate. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">On
the matter of the MIB, I agree that these are “protocol parameters”,
but in many cases these also directly control and configure protocol behavior.
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">The
SAPs are almost always left off of these diagrams unless we are trying
to specifically address topics relevant to the SAP itself. Since
a SAP is essentially just a sort of abstract API, and we do not usually
define APIs, they can safely be ignored for most protocol design &
deployment purposes. The CLA’s, when and where they are defined,
are one way of handling this in a concrete form.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">On
the whole AMA /ADM topic I think there is a longer discussion. I
just read the whole AMA, ADM, AMM, ADMT, ODM, AMP, ADM Agent, etc, etc,
story. I THINK I understand what they are trying to do, but I need
to check my assumptions with the SIS DTN WG and Ed Birrane. Most
of the functionality seems to be focused upon asynchronous management and
reporting of remote, “agents” of one form or another. The fundamental
aspects defined so far seem to be mostly about controlling the reporting
from the agents, so many bundles processed, lost, etc. I have not
seen anything (yet) that addresses routing updates, potential contact plan
exchange, pointing / orbit updates, or the exchange of any other control
artifacts like ACLs. I think that the AMA / ADM has features that
might be able to handle this, or that the core can be extended in this
way, but as far as I can tell these operations and controls have not yet
been defined. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Security
is weakly described and yet I think it is essential to secure the management
interfaces that will provide these space internetworking services.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">That
said, as far as the functional components that will be needed inside a
space (or ground) entity that supports a Bundle Agent, link layer services,
or an ADM for that matter, I agree that the FRM provides an excellent framework
for this. I think that, just as with the link layer functions, all
of these protocol elements for the DTN, LTP, ADM, etc, can be most suitably
modelled using the CSS FRM features and tool set. And, once these
FRM are defined, and they get implemented inside some set of components,
that we could then use the SOIS EDS to define the interfaces of those components.
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">I
think it all hangs together, but I would like to get verification of this
from others. And I would like to get a better understanding of just
what we might be able to do vis-à-vis extending the existing AMA / ADM
concepts to cover more of the whole DTN secure network management needs.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Does
this make sense to you?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Thanks
again.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Peter</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"><b>From:
</b><Felix.Flentge@esa.int><b><br>
Date: </b>Monday, December 13, 2021 at 4:23 AM<b><br>
To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>
Subject: </b>[EXTERNAL] Re: [Sea-sa] Second cut at CSS FRM and SOIS EDS
integration approach</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">Dear
Peter,</span><span style=" font-size:11pt;font-family:Calibri"> <br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
thanks for sorting out the differences between the EDS and the FRM. It's
very useful and clarified some things for me.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Regarding the AMA/ADM stuff and looking at the discussions in the IETF
DTN WG on its re-charter, I am not sure whether this will be taken up.
The current draft charter (</span><a href="https://datatracker.ietf.org/doc/charter-ietf-dtn/"><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>Delay/Disruption
Tolerant Networking (ietf.org)</u></span></a><span style=" font-size:12pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial">) includes Network
Management (or rather Operations, Administration and Management) but it
does not commit to AMA and, in general, it seems a long way to go.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
For the up-coming IOAG Mars Communication Architecture (to be released
soon), the way forward will probably be to suggest FRM for internal DTN
network management until a time when DTN Network Management will be fully
defined. I do believe that this would be a viable and sensible way forward.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
One minor comments to your slides: slides 4 & 5 describe the MIB as
describing 'Protocol controls'. The MIBs I have encountered at CCSDS (CFDP,
BP) do usually describe only 'protocol parameters'. I think the, Service
Access Point (SAP) with requests/indications may be missing in these figures.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Regards,<br>
Felix</span><span style=" font-size:11pt;font-family:Calibri"> <br>
<br>
</span><span style=" font-size:8pt;color:#808080;font-family:Verdana"><b><br>
_________________________________________</b></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:8pt;color:#808080;font-family:Verdana"><b><br>
ESA - European Space Agency </b></span><span style=" font-size:8pt;color:#00a1e0;font-family:Verdana"><br>
Dr. Felix Flentge</span><span style=" font-size:8pt;color:#808080;font-family:Verdana"><br>
Software Engineer, OPS-GSB<br>
Ground Systems Engineering Department<br>
Directorate of Operations</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:8pt;color:#808080;font-family:Verdana"><b><br>
ESA - ESOC</b><br>
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:8pt;color:#808080;font-family:Verdana"><br>
Phone: +49 6151 90 4075 | Email: Felix.Flentge@esa.int</span><span style=" font-size:11pt;font-family:Calibri">
<br>
<br>
<br>
<br>
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
From: </span><span style=" font-size:9pt;font-family:Arial">"Shames,
Peter M\(US 312B\) via SEA-SA" <sea-sa@mailman.ccsds.org></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
To: </span><span style=" font-size:9pt;font-family:Arial">"Wilmot,
Jonathan J. (GSFC-5820)" <jonathan.j.wilmot@nasa.gov>, "Ramon
Krosley" <r.krosley@andropogon.org>, "Barkley, Erik J (US
3970)" <erik.j.barkley@jpl.nasa.gov>, "Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)"
<john.pietras@gst.com></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Cc: </span><span style=" font-size:9pt;font-family:Arial">"Tomaso.deCola@dlr.de"
<Tomaso.deCola@dlr.de>, "Pham, Timothy T\(US 3300\)" <timothy.t.pham@jpl.nasa.gov>,
"Keith Scott" <kscott@mitre.org>, "SEA-SA" <sea-sa@mailman.ccsds.org></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Date: </span><span style=" font-size:9pt;font-family:Arial">09/12/2021
23:30</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Subject: </span><span style=" font-size:9pt;font-family:Arial">[Sea-sa]
Second cut at CSS FRM and SOIS EDS integration approach</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Sent by: </span><span style=" font-size:9pt;font-family:Arial">"SEA-SA"
<sea-sa-bounces@mailman.ccsds.org></span><span style=" font-size:11pt;font-family:Calibri">
</span></p>
<div align=center>
<hr noshade></div>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Guys,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">I
sent and earlier version of this file out a while ago, and just refined
it. I cleaned up some of the terminology use and also added a couple
of new “here’s what it would look like to use FRM to describe the protocol
innards of SOIS on-board communications components” diagrams. See
pgs 13-14. I did not create a separate diagram to describe the use
of EDS to define ESLT <b><i>real component</i></b> interfaces, but that
is pretty straightforward.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Please
take a look at this stuff and let’s get it right.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Meanwhile
I am off working to understand the whole thicket of SIS AMA, ADM, ADMT,
ODM standards and how they play with DTN, BP, BPSec, etc. As far
as I have dug into it so far, it appears that the AMA/ADM stuff is really
a sort of data model and control language for control of applications and
protocols. As stated in the AMA doc, [I-D.birrane-dtn-ama]:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<ul>
<li><span style=" font-size:11pt;font-family:Calibri">The Asynchronous
Management Architecture (AMA) defines a concept for the open-loop control
of applications (and protocols) in situations where timely, highly-available
connections cannot exist amongst managing and managed nodes in a network.
</span>
<li><span style=" font-size:11pt;font-family:Calibri">While the AMA provides
a logical data model, it does not include the detailed information necessary
to produce interoperable data models. </span>
<li><span style=" font-size:11pt;font-family:Calibri">The ADM defines a
physical data model suitable for managing applications in accordance with
the AMA. This physical model is termed the Asynchronous Management
Model (AMM) and consists of the data types and data structures needed to
manage applications in asynchronous networks. </span>
<li><span style=" font-size:11pt;font-family:Calibri">The ADM document
also provides a template, called the Application Data Model Template (ADMT),
for the standardized representation of application-specific instances of
this model. Using the types and structures defined by the AMM, individual
applications can capture their unique, static management information in
documents compliant with the ADMT. These application-specific documents
are called Application Data Models (ADMs).</span></ul><span style=" font-size:11pt;font-family:Calibri">
</span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">I
have read the AMA and ADM, cover-to-cover, but have not yet dug down through
the AMM and ADMT, I am not yet seeing the relationship of this AMA/ADM
to either the EDS or the FRM since it does not appear to reference either
components nor interfaces. If anything, the relationship might be
between the AMM/ADM and the CSS SM and MD/SC standards. We’ll see.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Feedback
please, on this part.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Thanks,
Peter</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> [attachment
"SEA Protocol FRM EDS model comparison 211209.pptx" deleted by
Felix Flentge/esoc/ESA] </span><span style=" font-size:10pt;font-family:Courier New">_______________________________________________<br>
SEA-SA mailing list<br>
SEA-SA@mailman.ccsds.org</span><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa"><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa</u></span></a></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>