[SIS-CFDPV1] New SANA Registry: Checksum Types

Jeremy.Mayer at dlr.de Jeremy.Mayer at dlr.de
Mon Jun 3 18:52:38 UTC 2019


Scott,
Sounds fine by me. Taking that into account, I would remove the length restriction on the checksum ID and preallocate 0x04 - 0x0D "for CFDP". Otherwise, it'll be as discussed. Osvaldo, et al: I'll update the registry tomorrow morning and send it out.

Thanks,
Jeremy
________________________________
From: Burleigh, Scott C (312B) [scott.c.burleigh at jpl.nasa.gov]
Sent: Monday, June 03, 2019 7:48 PM
To: Mayer, Jeremy; Peinado, Osvaldo Luis
Cc: Janssen, Jens; madalier at antarateknik.com; sis-cfdpv1 at mailman.ccsds.org
Subject: RE: New SANA Registry: Checksum Types

That sounds fine to me, Jeremy: 4 bits for checksum ID, with 0x0f meaning “no checksum”.  How about if we just say checksum ID “0x0e” is “reserved” for now and figure out what to do with it later on?

Scott

From: Jeremy.Mayer at dlr.de <Jeremy.Mayer at dlr.de>
Sent: Monday, June 3, 2019 10:43 AM
To: Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov>; osvaldo.peinado at dlr.de
Cc: jens.janssen at dlr.de; madalier at antarateknik.com; sis-cfdpv1 at mailman.ccsds.org
Subject: [EXTERNAL] RE: New SANA Registry: Checksum Types

Hi Scott,
I personally would prefer the 6-bit variant, but understand the issue. If we are going to reduce the width of the field, I would go with 4 bits, where 0x0E is "extended checksum" (the location of which can be specified at a later date), and 0x0F is no checksum... or the other way around.

Thanks,
Jeremy
________________________________
From: Burleigh, Scott C (312B) [scott.c.burleigh at jpl.nasa.gov]
Sent: Monday, June 03, 2019 5:28 PM
To: Peinado, Osvaldo Luis; Mayer, Jeremy
Cc: Janssen, Jens; madalier at antarateknik.com<mailto:madalier at antarateknik.com>; sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Subject: RE: 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/20190603/0acf4421/attachment-0001.html>


More information about the SIS-CFDPV1 mailing list