[CESG] [EXTERNAL] Complexity of MO Services

Thu Sep 29 17:13:33 UTC 2022

Hi Mario,

Interesting point of view.

But my point was to demonstrate that they are similar in that they are “layered”, but very dissimilar in terms of complexity and clarity.

Best regards, Peter

From: Mario Merri <Mario.Merri at esa.int>
Date: Thursday, September 29, 2022 at 1:46 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Mehran Sarkarati <Mehran.Sarkarati at esa.int>, CESG <cesg at mailman.ccsds.org>
Subject: RE: [EXTERNAL] [CESG] Complexity of MO Services

Hi Peter,

My point was not trying to demonstrate that they are the same, but that they are similar in terms of complexity. That’s all.

Best regards,

__Mario

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Sent: 28 September 2022 20:35
To: Mario Merri <Mario.Merri at esa.int>; CESG (cesg at mailman.ccsds.org) <cesg at mailman.ccsds.org>
Cc: Mehran Sarkarati <Mehran.Sarkarati at esa.int>
Subject: Re: [EXTERNAL] [CESG] Complexity of MO Services

Hi Mario,

I’m going to avoid a lengthy polemic myself.

Yes, it is true that both DTN and MAL have layered architectures.  Many systems do.

No, the MAL and the DTN BPA are not the same.

DTN

  1.  The DTN protocol is defined in Blue Book and it is concretely specified such that it can be directly implemented.  The PDUs are concretely defined, like most CCSDS and Internet protocols.
  2.  A few of the CLAs are specified in this DTN BB.  They are of the form “take the concrete DTN PDU and put it directly into a TCP datagram of the same length”.
  3.  There is more than one possible CLA, because there is more than one underlying “network”, but several are defined in just a few pages of the DTN BB and the mapping is direct from DTN PDU to CLA.
  4.  These are idempotent.
  5.  That’s it.

MAL

  1.  The MAL is defined in abstractions in the BB (which, IMHO, is really an MB because it is abstract).
  2.  The MAL cannot be directly implemented from the BB, additional mappings and bindings are needed.
  3.  The data mappings must be separately defined in a different BB before you can get to anything like a concrete PDU.
  4.  The transport mappings must be separately defined in a different BB.
  5.  There are many possible mappings from the abstract MAL to actual PDUs to actual transport layers.  This is not one to one, it is potentially one to many.
  6.  These mappings are not always idempotent, sometimes separate “by management”, out of band, signals are required.
  7.  This addition of extra layers of abstraction, mappings, and no guarantee of idempotence adds complexity.
  8.  Not really the same at all.

As with most things in this life, you have to read the fine print.  Simple abstract pictures do not do justice to reality.

Cheers, Peter

From: CESG <cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>> on behalf of CESG <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Reply-To: Mario Merri <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>
Date: Wednesday, September 28, 2022 at 2:27 AM
To: CESG <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Cc: Mehran Sarkarati <Mehran.Sarkarati at esa.int<mailto:Mehran.Sarkarati at esa.int>>
Subject: [EXTERNAL] [CESG] Complexity of MO Services

Good morning,

Today while reviewing the CCSDS Bundle Protocol Specification, my attention was caught by the following pictures in the document:
[cid:image001.png at 01D8D3EC.214DA970]
This seems very close to the MO Framework stack, where the Technology bindings allow mapping the services to a given technology, pretty much as the Convergence Layer Adapters in the picture above allow mapping to different network types. I would guess that in the above architecture the Bundle Protocol Agent has, at least partially, a similar role as the MAL. Clearly, the logic of devising such architectures (for both MO and BP) is sound and allows the deployment over different technologies (networks) at the cost of some additional complexity. This complexity has to be hidden to the final users by the availability of productised SW libraries that implement the protocols/services.

I just would like to share this analogy without any polemic. Yes, our standards are sometime complex above all if we move from the format to the services (MO, SLE, BP), but I think that, while services are the present for communications protocols (SLE and BP), they will be the future for space applications (please note that in mainstream IT, services have been the present for quite a while, just think to the Service Oriented Architecture (SOA) and the trend towards microservices). I think that acknowledging this and working all together to bring innovation into the space world is one of the task that CCSDS and CESG has.

Best regards,

__Mario

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 at esa.int<mailto:dpo at esa.int>).
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 at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20220929/e05d722e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 35166 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20220929/e05d722e/attachment-0001.png>