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

Wed Dec 15 19:21:21 UTC 2021

Hi Felix,

Thanks again for keeping this dialogue going.  The more that we can all communicate with the intent to reach a common understanding the better off we will all be.

FRM – I agree completely that the FRM, with some suitable broadening of focus, should be able to describe abstract protocol functions in space just as it does on for ground stations.  In fact, it should also serve equally well for any protocol functions within an MOS.

EDS – since these are intended to describe interfaces of fully realized components, whether hardware of software, I also agree that they should be as useful on the ground as they are in space deployment.  Here too, however, they may require some broadening of focus and some new interface bindings.  That said, at the protocol level I do not believe that the EDS and DOT provide anything other than the means to describe the PDUs that get emitted at the interfaces of spacecraft devices that spacecraft on-board comm links.

So I would agree that implementations, per se, will continue to be agency (or vendor) specific, but that interoperable descriptions of the interfaces of these components can be produced with EDS and DOT, after any necessary new binding types are added to the DOT.

For CSTS MD & SC I do not see how these can be generalized for use in space, but I do agree that the FRM set, and the functionality that MD and SC offer, can be expanded to cover DTN related services and components on the ground.  I do not think that the MD-CSTS and SC-CSTS can be generalized for use in space deployments.

In contrast, I do believe that the AMA / ADM standards that are being defined in the IETF for use with DTN can be used both in space and terrestrially.  They are defined to be used in an asynchronous mode and with potentially delayed delivery or in disconnected environments.  So they are immune to the usual issues related to delay and disconnection.  Based on the analysis I have done, I believe that the issue with using AMA and ADM is that right now they only offer reporting and monitor data delivery, they do not (yet) offer DTN network management in any sort of active control sense, and they are not yet well secured.

In fact, the whole issue of how to secure communications, and to secure the network and its management, in a multi-agency interoperable way is still very much in discussion.  There are security mechanisms built into BPv7 and BPSec, and these support encryption, authentication, and both together.  Using these to manually secure communications is possible.  These features can be used, as is, with pre-emplaced keys and relying upon pre-determined, and implicitly trusted, “identities” of participating nodes and users.  The problem, to my way of thinking, is that there is as yet no established and formalized way to define and use unimpeachable identities of communicating nodes and other entities that participate in communications, for configuration, control, and reporting on any sort of multi-agency network.

I just gave a presentation to the CMC that detailed the concepts that I have been exploring about how to secure the future CCSDS DTN functions.  It was well received and it had review by several of the CCSDS Security and DTN experts.  This is conceptual, and much more work needs to be done to make it a reality, but I offer it up here for consideration and to request feedback.  Perhaps we can use this as a sort of conceptual framework around which we can formulate the specific standards that we agree are needed to reach a viable, secure, future multi-agency DTN deployment.

Thanks, Peter

From: <Felix.Flentge at esa.int>
Date: Wednesday, December 15, 2021 at 5:43 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Erik Barkley <erik.j.barkley at jpl.nasa.gov>, "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>, John Pietras <john.pietras at gst.com>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>, Keith Scott <kscott at mitre.org>, Ramon Krosley <r.krosley at andropogon.org>, SEA-SA <sea-sa at mailman.ccsds.org>, Tim Pham <timothy.t.pham at jpl.nasa.gov>, "Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>
Subject: Re: [EXTERNAL] Re: [Sea-sa] Second cut at CSS FRM and SOIS EDS integration approach

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/c79841d7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMC Sec arch overview - identities 8Dec21.pdf
Type: application/pdf
Size: 1779506 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20211215/c79841d7/attachment-0001.pdf>
-------------- 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/20211215/c79841d7/attachment-0001.bin>