C2MS12 — Support CCSDS SM&C Services in C2MS

(Note: This is a consolidated and cleaned-up issue for CCSDS SM&C and MAL, which exist in several other C2MS issues.
This information has been collected from those sources and refined for clarity moving forward. Previous issues listed below.)

The CCSDS (Spacecraft Monitor & Control) SM&C defines a set of mission operations services. At the bottom of these
services is an abstract MAL message layer.

It is possible that an abstract MAL message could be mapped to a C2MS version, along with an appropriate addressing
scheme so that SM&C services could flow over a C2MS system, coexisting with C2MS message-based services. The following
is a copy of the current MAL message. It has a header consisting of several fields; after these data fields, this will
be (preliminarily) further discussed following the header section.

Within the header, there are TO and FROM fields. The CCSDS MAL Blue Book states that these fields are “open” in the MAL
abstract definition, although some form of reasonable quality-of-delivery service should also be provided for MAL message
delivery. There is also a service model—this is described in a separate Blue Book—which suggests that each service has an
associated URI.

Finally, there are several MAL mappings defined in various Blue Books—TCP, HTTP, and Space Packets, to name three. These
show how the MAL URI TO/FROM fields are mapped to specific protocol headers such as source/destination IP addresses, HTTP
URLs, and APIDs, to align with the above references. Given that the C2MS message can define services using C2MS subjects,
these can be used directly for the MAL TO/FROM fields or mapped from corresponding URI/URL values.

The REFERENCES section at the end of this description points to several CCSDS reports and multiple implementations in
different programming languages, using a variety of transport mechanisms.

Abstract MAL Header

URI MAL Header

(possible and vague mapping of MAL as C2MS minus fixing up types and the List)

C2MS MAL Header

For C2MS most of the fields can be mapped to C2MS types with exception List<NameType> which should follow the C2MS pattern:
Field Type Description
Supplement.n.Name Scalar Value Optional supplementary fields

An "InteractionType" is:

Interaction Types

(PRELIMINARY)

MAL MESSAGE BODY
After these header items the MAL body appears to consist of a TYPE/VALUE pair that is aligned with a specific message specification from the service.
In other words there is not a name associated with each field.

This means there are 2 options to further map a MAL message to C2MS:
1) bundle up any concrete MAL message's data body into a C2MS blob type and send it on, with the idea that the MAL service receiving it through C2MS
layer will then know what to do with it, because it has its own service definitions.
2) Let the mapper handle this because it's sophisticated and it will map each MAL field to a C2MS field using the appropriate service definition,
(somehow) giving each field in that service (a type/value pair) a name as well.

Alternative approaches?
One alternative approach to all the above would be to take any concrete MAL message, and in total make it a blob-style part of C2MS message in the
data body – and broadcast this message on the C2MS bus – and any particular node implementing SM&C services would receive that message - and
then decode it enough to determine if it's recipient or not.

This is a simpler approach overall but every node that receives such "broadcast" MAL messages will have to look at every
one of them to determine if any particular one is for them or not.

Other approaches considering essentially involved tunnelling a URL based MAL message through C2MS and then inserting/stuffing it into the http "stack" and so on and
this seem messy and possibly a security horror.

REFERENCES
– there's a large number of related ccsds publication found here under the "Mission Operations..." title
---- https://ccsds.org/publications/moims/
– https://en.wikipedia.org/wiki/Message_Abstraction_Layer
– https://github.com/CNES/ccsdsmo-maljava
– https://github.com/CNES/ccsdsmo-malc (note: uses zeromq but not clear if c2ms subject/topics would be mappable to it)
– https://github.com/nasa/CCSDS-MAL-Http-Binding-Xml-Encoding
– https://github.com/CNES/ccsdsmo-malgo
– https://github.com/tanagraspace/ccsdsmo-malc-sepp-apps (fork may have updates)

PREVIOUS or EXISTING ISSUES (Deferred)
The following issues (& related proposals) have previously been submitted on this topic. They have in general been deferred (to 1.3 now). However the intent of this issue is to subsume them all into this one issue which will carry forward.

They are as follows:
– C2MS12-79
– C2MS12-97
– C2MS12-74
– C2MS12-112