[SIS-CFDPV1] revised draft specification

구철회 chkoo at kari.re.kr
Wed Dec 11 00:48:18 UTC 2019


Hi, Scott.

I like your idea. I am currently working on the modification of CFDP software from my side, and I love to perform the supplementary interoperability test when the updated ION and interoperability test plan are available.

I don’t see many testing items are required for this supplementary testing. However as I sent it earlier to you there is a tricky issue with regard to handling condition code of ‘Unsupported checksum type(1011)’. In order to make that situation, the ‘Unsupported checksum type’ is generated, happen, a CFDP (sending) entity should be able to generate a checksum field by a checksum algorithm that the other CFDP (receiving) entity does not support. As there are not much choices in selection of checksum algorithms, it can be tricky because one CFDP entity may have to implement an unnecessary checksum algorithm that is even not consistent with CFDP Checksum Identifiers in SANA registry (https://sanaregistry.org/r/checksum_identifiers).
   * short question : why are the number of the checksum ID in the SANA not consistently sequential? E.g., 4,5,(6?),7,(8?),9,10,11,12,13,14,6,8,15.

After thinking about this issue, I like to propose an idea. Why don’t we allocate a Checksum ID to each space agencies, e.g., KARI reserve 5 as a checksum ID for potential use. Then KARI can freely choose the checksum algorithm for checksum ID 5, e.g., just a copy of modular, CRC32 or whatever or in-house algorithm for sure. When KARI put the 5 at the checksum type field in Metadata PDU, with all the interoperability testing with space agencies, the ‘Unsupported checksum type’ condition code should be designated at the FIN PDU from a receiving CFDP entity since all space agencies except KARI doesn’t have any reference for the checksum ID of 5. How do you think?

Cheol

From: SIS-CFDPV1 <sis-cfdpv1-bounces at mailman.ccsds.org> On Behalf Of Burleigh, Scott C (US 312B) via SIS-CFDPV1
Sent: Wednesday, December 11, 2019 1:21 AM
To: sis-cfdpv1 at mailman.ccsds.org
Subject: [SIS-CFDPV1] revised draft specification

Hi, all.  Following some additional discussion of the RID dispositions proposed in the Darmstadt meeting, we now have got a final (I hope) draft specification posted to CWE at https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.doc?Web=1; PDF is at https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.pdf.

This draft has gone to the Secretariat for final editing, but the technical stuff won’t be changing unless we discover a problem in interoperability testing.

Speaking of which, I hope to do that (small, supplementary) interoperability test in January.  Cheol and Chenyunjun, please take one more look at the markups in the revised spec to make sure the final tweaks are reflected in your code?  I need to modify ION’s CFDP as well and hope to have that done in early January.  We’ve discussed a plan for this supplementary testing, and we should try to tie off that discussion and finalize the plan sometime in the next couple of weeks.  (Holidays in the U.S. will complicate this, but it should still be doable.)

The end is in sight, I swear.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-cfdpv1/attachments/20191211/80819ddd/attachment.html>


More information about the SIS-CFDPV1 mailing list