[SIS-CFDPV1] updated CFDP Revisions draft

Jeremy.Mayer at dlr.de Jeremy.Mayer at dlr.de
Mon May 27 16:12:08 UTC 2019


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
Cc: Janssen, Jens; madalier at antarateknik.com; Peinado, Osvaldo Luis; 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 <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>; 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

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/5e8da871/attachment.html>


More information about the SIS-CFDPV1 mailing list