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

Mon Dec 13 22:19:02 UTC 2021

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/20211213/b4062b2c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 10148 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20211213/b4062b2c/attachment-0001.bin>