[SIS-CFDPV1] New SANA Registry: Checksum Types
Burleigh, Scott C (312B)
scott.c.burleigh at jpl.nasa.gov
Mon Jun 3 15:28:27 UTC 2019
Almost. We have not yet quite come to consensus on just how long the checksum ID should be.
Our original idea was 8 bits, but in that case the checksum ID would have to follow the TLVs in the Metadata PDU. I worry about backward compatibility in this approach, as a CFDPv0 entity would send a Metadata PDU containing no checksum ID at all and a receiving CFDPv1 entity would perceive this as a truncated Metadata PDU. Obviously this can be worked around in code, but it just seems like something that could go wrong across multiple implementations.
When I drafted the changes to the Blue Book, I realized that there were still 6 reserved bits in the first octet of the Metadata PDU. If we placed the checksum ID there, then there would be no difference in Metadata PDU length between the old and new CFDP; I think this is advantageous, but it would limit us to 64 checksum IDs (including 0 for modular checksum and 63 - that is, 0x3f - for "no checksum").
Cheol Koo has proposed that a 2-bit checksum ID, leaving 4 reserved bits, would actually be plenty. Tomaso has proposed a 4-bit checksum ID (16 IDs including 0 for modular checksum and 15 [0x0f] for "no checksum") instead. Chenyunjun has proposed a 3-bit checksum ID but agrees that a 4-bit code would be okay. My own preference is still for a 6-bit checksum ID but I too am okay with a 4-bit code; I would worry about running out of checksum algorithm IDs in the future if we were too restrictive.
I would propose that we come to a firm consensus on a 4-bit checksum ID so that we can move ahead with the new SANA registry today. Anyone who strongly objects, please speak up before Pasadena close of business today (1700 Monday Pacific Time, 0100 Tuesday CET, 0900 Tuesday Seoul time).
Scott
From: osvaldo.peinado at dlr.de <osvaldo.peinado at dlr.de>
Sent: Monday, June 3, 2019 7:03 AM
To: Jeremy.Mayer at dlr.de; Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov>
Cc: jens.janssen at dlr.de; madalier at antarateknik.com
Subject: [EXTERNAL] AW: New SANA Registry: Checksum Types
After following the interesting discussion, is it the final format for SANA?
Thanks, Osvaldo
Von: Mayer, Jeremy
Gesendet: Montag, 27. Mai 2019 07:34
An: Burleigh, Scott C (312B); Peinado, Osvaldo Luis
Cc: Janssen, Jens; madalier at antarateknik.com<mailto:madalier at antarateknik.com>
Betreff: RE: New SANA Registry: Checksum Types
Happy Monday folks!
Alright, taking this all into account, here are the new contents:
ChecksumID
Name
Polynomial
(Normal representation)
Reference
Output Length (bits)
0 (0x00)
Modular Checksum
CCSDS 727.0-B-4 ("CCSDS FILE DELIVERY PROTOCOL (CFDP)"), section 4.1.2
32
1 (0x01)
Proximity-1 Checksum
Editors note: I need to calculate this.
CCSDS 211.2-B-2 ("PROXIMITY-1 SPACE LINK PROTOCOL - CODING AND SYNCHRONIZATION SUBLAYER"), Annex C
32
2 (0x02)
CRC-32C
0x1EDC6F41
32
3 (0x03)
CRC-32
0x04C11DB7
32
255 (0xFF)
NULL
A null checksum. If used, the file checksum value shall be set to 0x00.
0
I still need to deep-dive the prox-1 checksum.
Thanks,
Jeremy
From: Burleigh, Scott C (312B) [mailto:scott.c.burleigh at jpl.nasa.gov]
Sent: Donnerstag, 16. Mai 2019 08:36
To: Mayer, Jeremy; Peinado, Osvaldo Luis
Cc: Janssen, Jens; madalier at antarateknik.com<mailto:madalier at antarateknik.com>
Subject: RE: New SANA Registry: Checksum Types
I like decimal, or both.
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: Wednesday, May 15, 2019 10:02 PM
To: Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>; osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>
Cc: jens.janssen at dlr.de<mailto:jens.janssen at dlr.de>; madalier at antarateknik.com<mailto:madalier at antarateknik.com>
Subject: [EXTERNAL] RE: New SANA Registry: Checksum Types
Jetlag strikes again.
One question for everyone on this chain: Should the checksumID be decimal, hex, or both? Once that's answered, I'll provide the next revision of the initial contents for this registry.
Thanks,
Jeremy
From: Burleigh, Scott C (312B) [mailto:scott.c.burleigh at jpl.nasa.gov]
Sent: Mittwoch, 15. Mai 2019 17:42
To: Mayer, Jeremy; Peinado, Osvaldo Luis
Cc: Janssen, Jens; madalier at antarateknik.com<mailto:madalier at antarateknik.com>
Subject: RE: New SANA Registry: Checksum Types
Jeremy, thanks! One tiny change: the fifth entry in this list has ChecksumID = 0, which I think should be 255. And if you wanted, you could add "727.0-B-4 ("CCSDS FILE DELIVERY PROTOCOL (CFDP)"), section 4.1.2" to the Reference text for checksumID 0 in the first entry.
Scott
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: Tuesday, May 14, 2019 10:39 PM
To: Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>; osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>
Cc: jens.janssen at dlr.de<mailto:jens.janssen at dlr.de>; madalier at antarateknik.com<mailto:madalier at antarateknik.com>
Subject: [EXTERNAL] RE: New SANA Registry: Checksum Types
Hey,
Whoops, thanks for the catch. I agree with both of your suggestions, so the general structure will now look like:
Structure and type of registry:
1. ChecksumID: an integer between 0 and 255
2. Name: The human-readable name of the checksum ID (CRC-32, etc)
3. Polynomial (optional, when required): an variable length integer describing the polynomial.
4. Reference (optional): A link to the specification which describes this checksum.
5. Output length (bits): An integer between 0 and 64 (Expanded to include 64 bit hashes)
And the initial data will look like:
ChecksumID
Name
Polynomial
(Normal representation)
Reference
Output Length (bits)
0
Modular Checksum
CFDP Modular checksum.
32
1
Proximity-1 Checksum
Editors note: I need to calculate this.
CCSDS 211.2-B-2
32
2
CRC-32C
0x1EDC6F41
32
3
CRC-32
0x04C11DB7
32
0
NULL
A null checksum. If used, the file checksum value shall be set to 0x00.
0
Scott, does this look correct?
Thanks,
Jeremy
From: Burleigh, Scott C (312B) [mailto:scott.c.burleigh at jpl.nasa.gov]
Sent: Dienstag, 14. Mai 2019 20:45
To: Peinado, Osvaldo Luis; Mayer, Jeremy
Cc: Janssen, Jens; madalier at antarateknik.com<mailto:madalier at antarateknik.com>
Subject: RE: New SANA Registry: Checksum Types
Wups, I wasn't paying close enough attention to this conversation. Can the registry be edited? I see two things I would like to adjust:
* Checksum ID needs to be a number between 0 and 255, not 0 and 256, as it has got to fit into an 8-bit field.
* I'd suggest that we use 255 for the NULL checksum. ChecksumID 0 needs to be the modular checksum for which the reference is reference is 727.0-B-4 ("CCSDS FILE DELIVERY PROTOCOL (CFDP)"), section 4.1.2; this will give use backward compatibility with the original CFDP specification, which does not include checksum ID in the metadata PDU and therefore will always use the modular checksum.
Scott
From: osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de> <osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>>
Sent: Thursday, May 9, 2019 3:13 PM
To: Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>; Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>
Cc: jens.janssen at dlr.de<mailto:jens.janssen at dlr.de>; madalier at antarateknik.com<mailto:madalier at antarateknik.com>
Subject: [EXTERNAL] AW: New SANA Registry: Checksum Types
Thank you Jeremy
Now we have all the information that I need
Just talk about the new registry here at the SANA meeting
Best Regards
Osvaldo
Von: Mayer, Jeremy
Gesendet: Freitag, 10. Mai 2019 00:09
An: Burleigh, Scott C (312B); Peinado, Osvaldo Luis
Cc: Janssen, Jens; madalier at antarateknik.com<mailto:madalier at antarateknik.com>
Betreff: RE: New SANA Registry: Checksum Types
Alright (and adding Mehmet)
Taking that into account, here's an initial list of checksums:
ChecksumID
Name
Polynomial
(Normal representation)
Reference
Output Length (bits)
0
NULL
A null checksum. If used, the file checksum value shall be set to 0x00.
0
1
Proximity-1 Checksum
Editors note: I need to calculate this.
CCSDS 211.2-B-2
32
2
CRC-32C
0x1EDC6F41
32
3
CRC-32
0x04C11DB7
32
Thanks,
Jeremy
From: Burleigh, Scott C (312B) [mailto:scott.c.burleigh at jpl.nasa.gov]
Sent: Donnerstag, 9. Mai 2019 23:53
To: Mayer, Jeremy; Peinado, Osvaldo Luis
Cc: Janssen, Jens
Subject: RE: New SANA Registry: Checksum Types
Right, file checksum is a 32-bit integer transmitted in the EOF PDU.
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: Thursday, May 9, 2019 2:37 PM
To: osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>; Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>
Cc: jens.janssen at dlr.de<mailto:jens.janssen at dlr.de>
Subject: [EXTERNAL] RE: New SANA Registry: Checksum Types
I would suggest added one column though:
Output length (bits): An integer between 0 and 32(Scott, this is the correct max, right)
From: Mayer, Jeremy
Sent: Donnerstag, 9. Mai 2019 23:36
To: Peinado, Osvaldo Luis; Burleigh, Scott C (312B)
Cc: Janssen, Jens
Subject: RE: New SANA Registry: Checksum Types
That will also be the document reference. If everyone is in agreement with the columns which I have provided, I would be happy to populate an initial set of options.
From: Peinado, Osvaldo Luis
Sent: Donnerstag, 9. Mai 2019 23:35
To: Burleigh, Scott C (312B); Mayer, Jeremy
Cc: Janssen, Jens
Subject: AW: New SANA Registry: Checksum Types
Thank you
Von: Burleigh, Scott C (312B) [mailto:scott.c.burleigh at jpl.nasa.gov]
Gesendet: Donnerstag, 9. Mai 2019 23:33
An: Mayer, Jeremy; Peinado, Osvaldo Luis
Cc: Janssen, Jens
Betreff: RE: New SANA Registry: Checksum Types
Right, for the "modular checksum" registry entry the reference is 727.0-B-4 ("CCSDS FILE DELIVERY PROTOCOL (CFDP)"), section 4.1.2.
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: Thursday, May 9, 2019 2:05 PM
To: osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>
Cc: jens.janssen at dlr.de<mailto:jens.janssen at dlr.de>; Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>
Subject: [EXTERNAL] RE: New SANA Registry: Checksum Types
Nuts, I forgot to do that part... Scott, do you have the document available?
From: Peinado, Osvaldo Luis
Sent: Donnerstag, 9. Mai 2019 23:04
To: Mayer, Jeremy
Cc: Janssen, Jens; Burleigh, Scott C (312B)
Subject: AW: New SANA Registry: Checksum Types
Jeremy
Can you please give me the approved document where we need to reference to?
Thanks
Osvaldo
Von: Mayer, Jeremy
Gesendet: Donnerstag, 9. Mai 2019 22:52
An: Peinado, Osvaldo Luis
Cc: Janssen, Jens; Burleigh, Scott C (312B)
Betreff: New SANA Registry: Checksum Types
Hey,
I just want to make this quick, so you can point it out in your meetings: We (SIS, particularly CFDP v1/DTN) wish to start a new registry, describing various checksum types. This will eventually be required for the next revision of CFDPv1, in order to allow self-describing checksum algorithms.
So, based on the SANA registry creation document:
Name: Checksum Identifiers
Structure and type of registry:
1. ChecksumID: an integer between 0 and 256
2. Name: The human-readable name of the checksum ID (CRC-32, etc)
3. Polynomial (optional, when required): an variable length integer describing the polynomial.
4. Reference (optional): A link to the specification which describes this checksum.
I think this is a reasonable start to a document; Scott, Osvaldo, Jens: any suggestions?
Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-cfdpv1/attachments/20190603/0211d138/attachment-0001.html>
More information about the SIS-CFDPV1
mailing list