[SIS-CFDPV1] updated CFDP Revisions draft

Burleigh, Scott C (312B) scott.c.burleigh at jpl.nasa.gov
Mon May 27 16:55:32 UTC 2019


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 <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>; sis-cfdpv1 at mailman.ccsds.org
Cc: jens.janssen at dlr.de; madalier at antarateknik.com; osvaldo.peinado at dlr.de; thomas.gannett at tgannett.net; 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/20190527/a71738e9/attachment-0001.html>


More information about the SIS-CFDPV1 mailing list