[SIS-CFDPV1] New SANA Registry: Checksum Types
Burleigh, Scott C (312B)
scott.c.burleigh at jpl.nasa.gov
Tue Jun 4 14:52:06 UTC 2019
Thanks, Jeremy. A small emendation: output length for all of these first 16 checksum algorithms has got to be 32. The checksum length in the EOF PDU is fixed (Table 5-6).
I’ll update and re-post the Pink Book this morning.
Scott
From: Jeremy.Mayer at dlr.de <Jeremy.Mayer at dlr.de>
Sent: Tuesday, June 4, 2019 6:44 AM
To: Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov>; chkoo at kari.re.kr; osvaldo.peinado at dlr.de
Cc: madalier at antarateknik.com; jens.janssen at dlr.de; sis-cfdpv1 at mailman.ccsds.org
Subject: [EXTERNAL] RE: New SANA Registry: Checksum Types
Morning folks,
Assuming that the registry structure has been accepted, here is the initial structure & data:
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)
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
4 (0x04)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
5 (0x05)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
6 (0x06)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
7 (0x07)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
8 (0x08)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
9 (0x09)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
10 (0x0A)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
11 (0x0B)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
12 (0x0C)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
13 (0x0D)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
14 (0x0E)
Reserved for CFDP
CCSDS 727.0-B-4 (“CCSDS FILE DELIVERY PROTOCOL (CFDP)”), section 4.1.2
0
15 (0x0F)
NULL
A null checksum. If used, the file checksum value shall be set to 0x00.
0
I’m verifying that I did that math right from Prox-1, and will send an update out tomorrow.
Thanks,
Jeremy
From: Burleigh, Scott C (312B) [mailto:scott.c.burleigh at jpl.nasa.gov]
Sent: Dienstag, 4. Juni 2019 04:25
To: 구철회; Peinado, Osvaldo Luis; Mayer, Jeremy
Cc: madalier at antarateknik.com<mailto:madalier at antarateknik.com>; Janssen, Jens; sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Subject: RE: New SANA Registry: Checksum Types
Thanks, Cheol, but actually I would want to make it even more lenient than that.
Nothing in the current specification mandates the implementation of any particular checksum algorithm whatsoever; the modular checksum algorithm is defined but it is nowhere required, and no other algorithms are even defined. What is mandated is that the sending entity must compute the checksum using one of the algorithms registered in SANA (including modular and “no checksum”) and that the receiving entity must compute the checksum using the same algorithm, as indicated by the checksum type in the Metadata PDU – except that when an entity is unable to perform the required calculation for any reason, the checksum value is simply zero (section 4.12); such an inability is not a deviation from the standard.
That is, the vehicle for interoperability here is the PICS rather than the specification, and in practical terms I think that is appropriate: it’s the best way to reconcile preparation for change in the future with limited implementation resources today.
Coming back to the core question: I haven’t heard anybody object strongly to settling on a checksum length of 4 bits, so I will go ahead and revise the Pink Book accordingly. And I think Jeremy’s concept of how to define this registry in SANA makes sense, so I would propose that we go ahead with that as well.
Scott
From: 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
Sent: Monday, June 3, 2019 4:49 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>; Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>
Cc: madalier at antarateknik.com<mailto:madalier at antarateknik.com>; jens.janssen at dlr.de<mailto:jens.janssen at dlr.de>; sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Subject: [EXTERNAL] RE: New SANA Registry: Checksum Types
Hi Scott,
4 bit length for the Checksum type field looks fine to me. And I have one idea to share.
15 possible checksum methods would be disaster for implementers because every checksum method should be implemented as interoperability is the one of key characteristics in CFDP I think.
Can we categorize the checksum field as like, e.g.
0 ~ 5 : CFDP mandatory checksum method and it is space agency’s obligation to implement these, e.g. modular checksum
6 ~ 14 : CFDP optional checksum method, e.g. private, experimental, or patented algorithm
15 : no checksum
Cheol
From: SIS-CFDPV1 <sis-cfdpv1-bounces at mailman.ccsds.org<mailto:sis-cfdpv1-bounces at mailman.ccsds.org>> On Behalf Of Burleigh, Scott C (312B) via SIS-CFDPV1
Sent: Tuesday, June 4, 2019 12:28 AM
To: osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>; Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>
Cc: madalier at antarateknik.com<mailto:madalier at antarateknik.com>; sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>; jens.janssen at dlr.de<mailto:jens.janssen at dlr.de>
Subject: Re: [SIS-CFDPV1] New SANA Registry: Checksum Types
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<mailto:osvaldo.peinado at dlr.de> <osvaldo.peinado at dlr.de<mailto:osvaldo.peinado at dlr.de>>
Sent: Monday, June 3, 2019 7:03 AM
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
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/20190604/6f2dd758/attachment-0001.html>
More information about the SIS-CFDPV1
mailing list