[Sea-sa] [EXTERNAL] Re: Second cut at CSS FRM and SOIS EDS integration approach

Wed Dec 15 13:43:20 UTC 2021

Thanks Peter,

yes, makes sense to me and seems to be a pragmatic way forward:
- 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).
- 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) 

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.

Regards,
Felix

From:   "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
To:     "Felix.Flentge at esa.int" <Felix.Flentge at esa.int>
Cc:     "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>, 
"Ramon Krosley" <r.krosley at andropogon.org>, "Barkley, Erik J (US 3970)" 
<erik.j.barkley at jpl.nasa.gov>, "Holger.Dreihahn at esa.int" 
<Holger.Dreihahn at esa.int>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)" 
<john.pietras at gst.com>, "Pham, Timothy T (US 3300)" 
<timothy.t.pham at jpl.nasa.gov>, "Keith Scott" <kscott at mitre.org>, 
"Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>, "SEA-SA" 
<sea-sa at mailman.ccsds.org>
Date:   13/12/2021 23:19
Subject:        Re: [EXTERNAL] Re: [Sea-sa] Second cut at CSS FRM and SOIS 
EDS integration approach

Hi Felix,

Thanks for engaging in this discussion.  It is really important to get 
diverse viewpoints heard, so I appreciate it.

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. 

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.    

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.

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.  

Security is weakly described and yet I think it is essential to secure the 
management interfaces that will provide these space internetworking 
services.

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.  

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.

Does this make sense to you?

Thanks again.

Peter

From: <Felix.Flentge at esa.int>
Date: Monday, December 13, 2021 at 4:23 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Subject: [EXTERNAL] Re: [Sea-sa] Second cut at CSS FRM and SOIS EDS 
integration approach

Dear Peter, 

thanks for sorting out the differences between the EDS and the FRM. It's 
very useful and clarified some things for me. 

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 (Delay/Disruption Tolerant Networking (ietf.org) ) 
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. 

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. 

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. 

Regards,
Felix 

_________________________________________ 
ESA - European Space Agency 
Dr. Felix Flentge
Software Engineer, OPS-GSB
Ground Systems Engineering Department
Directorate of Operations 
ESA - ESOC
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany 
Phone: +49 6151 90 4075 | Email: Felix.Flentge at esa.int 

From:        "Shames, Peter M\(US 312B\) via SEA-SA" 
<sea-sa at mailman.ccsds.org> 
To:        "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>, 
"Ramon Krosley" <r.krosley at andropogon.org>, "Barkley, Erik J (US 3970)" 
<erik.j.barkley at jpl.nasa.gov>, "Holger.Dreihahn at esa.int" 
<Holger.Dreihahn at esa.int>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)" 
<john.pietras at gst.com> 
Cc:        "Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>, "Pham, Timothy 
T\(US 3300\)" <timothy.t.pham at jpl.nasa.gov>, "Keith Scott" 
<kscott at mitre.org>, "SEA-SA" <sea-sa at mailman.ccsds.org> 
Date:        09/12/2021 23:30 
Subject:        [Sea-sa] Second cut at CSS FRM and SOIS EDS integration 
approach 
Sent by:        "SEA-SA" <sea-sa-bounces at mailman.ccsds.org> 

Guys,

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 real component interfaces, but that is pretty straightforward.

Please take a look at this stuff and let?s get it right.

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]:

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. 
While the AMA provides a logical data model, it does not include the 
detailed information necessary to produce interoperable data models. 
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. 
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).

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.

Feedback please, on this part.

Thanks, Peter
 [attachment "SEA Protocol FRM EDS model comparison 211209.pptx" deleted 
by Felix Flentge/esoc/ESA] _______________________________________________
SEA-SA mailing list
SEA-SA at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20211215/69461f66/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20211215/69461f66/attachment-0001.bin>