[SIS-CFDPV1] updated CFDP Revisions draft

Tomaso.deCola at dlr.de Tomaso.deCola at dlr.de
Tue May 28 00:04:15 UTC 2019


I also agree that having too many possible choices for possible checksum algorithm is probably not necessary. If we consider the most used ones today plus some possibly new more effective versions (who knows!) in the future, going for 4 bits seems reasonable to me.

Tomaso

Sent from my iPhone

On 28. May 2019, at 00:56, Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>> wrote:

But wouldn’t it be a viable alternative simply to say in the registry definition that the checksum ID is a 6-bit integer?  Or, per Cheol’s suggestion, only a 3-bit integer?  I am actually not a fan of restricting this value so much, but a 4-bit integer would give us 14 options for 32-bit checksum algorithms in addition to “modular checksum” and “no checksum”, which might be enough.  A 6-bit integer gives us a total of 64 options, which I strongly suspect would be plenty.

Scott

From: Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de> <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>
Sent: Monday, May 27, 2019 9:12 AM
To: Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>; sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Cc: jens.janssen at dlr.de<mailto:jens.janssen at dlr.de>; madalier at antarateknik.com<mailto:madalier at antarateknik.com>; osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>; thomas.gannett at tgannett.net<mailto:thomas.gannett at tgannett.net>; Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>
Subject: [EXTERNAL] RE: updated CFDP Revisions draft

Hi,
If we are now normatively pointing towards a new registry as the source of checksum ID’s, then we must ensure that all 1-byte checksum ID’s could fit. In the worst case, I would propose that you add a 1-bit value (“extended checksum used”) and a 5-bit “base checksum” value. If a checksum is used whose ID is >0x1F (11111b), than you set the extended checksum used bit, nullify the base checksum, and rely upon a “checksum ID” TLV.

Thanks,
Jeremy

From: Burleigh, Scott C (312B) [mailto:scott.c.burleigh at jpl.nasa.gov]
Sent: Montag, 27. Mai 2019 18:06
To: Mayer, Jeremy; sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Cc: Janssen, Jens; madalier at antarateknik.com<mailto:madalier at antarateknik.com>; Peinado, Osvaldo Luis; thomas.gannett at tgannett.net<mailto:thomas.gannett at tgannett.net>; Cola, Tomaso de
Subject: RE: updated CFDP Revisions draft

A highly salient point, Jeremy.  When I got down to revising the text of the specification I realized that there was a decision to make with regard to the Metadata PDU: the new checksum ID field could be added at the end, after all the TLVs, or a slightly truncated checksum ID field could be plugged into the unused bits of the first octet (as was done with the new “closure requested” flag).  I liked option B because it looked easier to parse, but it does mess up the registry.

In addition, Cheol has suggested that even 6 bits is too long; he would prefer an even shorter checksum ID field that would accommodate far fewer checksum selection options.

I’d like to come to a consensus on this question within the WG if possible.  Anybody else have an opinion here?

Scott

From: Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de> <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>
Sent: Sunday, May 26, 2019 10:37 PM
To: Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>; sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Cc: jens.janssen at dlr.de<mailto:jens.janssen at dlr.de>; madalier at antarateknik.com<mailto:madalier at antarateknik.com>; osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>; thomas.gannett at tgannett.net<mailto:thomas.gannett at tgannett.net>; Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>
Subject: [EXTERNAL] RE: updated CFDP Revisions draft

Hey,
Everything looks fine from my side, except for one not-so-minor issue: The checksum type ID field is 6 bits long, but has been outlined in the proposed registry as an 1-byte value, and we have (tentatively) reserved 0xFF as the NULL checksum. Therefore, the metadata PDU cannot unambiguously define data which is using the NULL checksum.

Thanks,
Jeremy

From: Burleigh, Scott C (312B) [mailto:scott.c.burleigh at jpl.nasa.gov]
Sent: Freitag, 24. Mai 2019 22:17
To: sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Cc: Janssen, Jens; madalier at antarateknik.com<mailto:madalier at antarateknik.com>; Mayer, Jeremy; Peinado, Osvaldo Luis; Thomas Gannett; Cola, Tomaso de
Subject: updated CFDP Revisions draft

Hi, all.  I have made all the changes to the revised CFDP Blue Book that I think are needed in order to make the file checksum algorithm selectable by reference to the new SANA checksum algorithm registry.  The updated document is now in CWE at https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%202.doc?Web=1.  Please take a look at it when you have a moment; I’d like to send a final draft to Tom and ask for a supplementary Agency review soon, maybe as early as next month.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-cfdpv1/attachments/20190528/2598d1a3/attachment-0001.html>


More information about the SIS-CFDPV1 mailing list