[Moims-sc] [EXTERNAL] [CCSDS] MAL Header - Optimization

[Coelho, César]

Hi Peter,

I understand now what you mean with “different version”. You are talking about the specific mapping from MAL into a concrete Transport binding.
So, the short answer to your question is yes, the version number of the Transport bindings that map the MAL to specific transport protocols will need to be incremented on the new book updates.
Additionally, the version of the MAL itself was also incremented.

Note that the Transport bindings already do have this version field and are ready for this. In both the MAL-SPP, and in the MAL-TCP/IP, this field is called “Version Number”.
It is the first field of the Space Packet Secondary Header, and the first field of the TCP/IP User Data Field.

This means that interoperability between Transport mapping versions can still be achieved.

Best regards,
César Coelho


From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Sent: Monday, May 22, 2023 2:25 PM
To: Coelho, César <cesar.coelho at cgi.com>; moims-sc at mailman.ccsds.org
Subject: Re: [EXTERNAL] [Moims-sc] [CCSDS] MAL Header - Optimization

EXTERNAL SENDER: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
EXPÉDITEUR EXTERNE: Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous ayez l'assurance que le contenu provient d'une source sûre.


If the defined values are within USHORT range that aspect sounds fine, and you won’t have to change the current list.  But the change to these field lengths means that you will not have interoperability between different versions.

I saw nor mention of version number changes.  So I find this change of the fundamental header structures and field sizes, without a change of version number, to be out of compliance with normal CCSDS practices.

I will point out that there are changes in document version numbers for other standards, but these do not involve changes in PDU format nor version numbers.

Regards, Peter


From: "Coelho, César" <cesar.coelho at cgi.com<mailto:cesar.coelho at cgi.com>>
Date: Monday, May 22, 2023 at 1:42 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, MOIMS-SC MOIMS-SC <moims-sc at mailman.ccsds.org<mailto:moims-sc at mailman.ccsds.org>>
Subject: RE: [EXTERNAL] [Moims-sc] [CCSDS] MAL Header - Optimization

Hi Peter,

All the previously defined service areas, services, and operations are within the UOctet range.
They can be casted into the UOctet type.

Best regards,
César Coelho


From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Sent: Saturday, May 20, 2023 1:16 AM
To: Coelho, César <cesar.coelho at cgi.com<mailto:cesar.coelho at cgi.com>>; moims-sc at mailman.ccsds.org<mailto:moims-sc at mailman.ccsds.org>
Subject: Re: [EXTERNAL] [Moims-sc] [CCSDS] MAL Header - Optimization

EXTERNAL SENDER: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
EXPÉDITEUR EXTERNE: Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous ayez l'assurance que le contenu provient d'une source sûre.


It’s your choice, of course, but doesn’t this totally blow backward compatibility?   The only way this would be allowed in most CCSDS specs is if it were given a different version number.

Regards, Peter


From: MOIMS-SC <moims-sc-bounces at mailman.ccsds.org<mailto:moims-sc-bounces at mailman.ccsds.org>> on behalf of MOIMS-SC MOIMS-SC <moims-sc at mailman.ccsds.org<mailto:moims-sc at mailman.ccsds.org>>
Reply-To: "Coelho, César" <cesar.coelho at cgi.com<mailto:cesar.coelho at cgi.com>>
Date: Friday, May 19, 2023 at 7:30 AM
To: MOIMS-SC MOIMS-SC <moims-sc at mailman.ccsds.org<mailto:moims-sc at mailman.ccsds.org>>
Subject: [EXTERNAL] [Moims-sc] [CCSDS] MAL Header - Optimization

Dear SM&Cers,

I would like to propose an optimization in the MAL Headers.
Basically, to change the type of Service Area, Service, and Operation, to UOctet (range is 0 to 255):

Field

Type

Description

From

Identifier

Message Source

Authentication Id

Blob

Authentication Identifier of Message Originator

To

Identifier

Message Destination

Timestamp

Time

Message generation timestamp

Interaction Type

InteractionType

Interaction Pattern Type

Interaction Stage

UOctet

Interaction Pattern Stage

Transaction Id

Long

Unique to consumer

Service Area

UShort

Service Area

Service

UShort

Service

Operation

UShort

Service Operation

Service version

UOctet

Service version

Is Error Message

Boolean

‘True’ if this is an error message; else ‘False’

Supplements

List<NamedValue>

Optional supplementary fields



This optimization also allows the Fully Qualified Short Form Part to be defined using a UInteger (4Bytes) instead of a ULong (8Bytes).
From:  Area Number (UShort – 2B), Area Version (UShort – 2B), Service Number (UShort – 2B), SFP (Short – 2B)
To: Area Number (UOctet – 1B), Area Version (UOctet – 1B), SFP (Short – 2B)

In terms of changes, this is easy to fix in the books, and also in the code.
Let me know if you disagree with this optimization.
If I receive no reply within the next 2 weeks, I will assume that you agree and I will update the book accordingly.

Best regards,
César Coelho


Dr. César Coelho
CGI Deutschland B.V. & Co. KG  | Space
Mornewegstr. 30 | 64293 Darmstadt | Germany
T: +49 173 54100 45 | email: cesar.coelho at cgi.com<mailto:cesar.coelho at cgi.com>

Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20230522/1a29dc1f/attachment-0001.htm>