[SIS-CFDPV1] revised draft specification

Wed Dec 11 07:10:41 UTC 2019

Dear All,

I would support that idea. We could be even more general (also to avoid 
changing the current draft standard wrt to the MIB) to just have one ID 
specified as 'Reserved for Private and/or Experimental Use'.

Regards,
Felix

From:   <Jeremy.Mayer at dlr.de>
To:     <chkoo at kari.re.kr>, <sis-cfdpv1 at mailman.ccsds.org>
Date:   11/12/2019 08:01
Subject:        Re: [SIS-CFDPV1] revised draft specification
Sent by:        "SIS-CFDPV1" <sis-cfdpv1-bounces at mailman.ccsds.org>

Hi Cheol,
I can answer your questions about the Checksum registry: First, I'm not 
sure why the checksum ID's are non-sequential, since I'm not sure what the 
SANA website is sorting by, but if you click the "ChecksumID" column 
header, it should sort correctly. 

I would suggest that, in the scenario which you outlined, the MIB 
containing the supported checksums for a receiving entity should be 
updated via TC and/or the desired checksum should be sent during a 
filestore request, but that's a more impactful change. I am adverse to a 
one-to-one allocation of checksum ID's to agencies, since it ultimately 
negates the purpose of the checksum ID and complicates mission operations 
and cross support: a single receiving CFDP entity at a ground station can 
(and likely will) support multiple missions, some of which may be 
performed from different agencies, each of which may have their own 
checksumming capabilities and requirements. If a single checksum ID is 
allocated to each agency, the receiving entity will be unable to determine 
the "real" checksum in use, unless that data is conveyed via some 
out-of-band mechanism. 

Additionally, different files from a single mission may require different 
checksums, either due to bandwidth constraints, mission phase, and/or 
avionics capabilities, meaning that the receiving entity will have to be 
aware of the mapping between entities, sessions, and checksum 
configurations. This is further complicated by the rise of file-based 
operations and advanced FDIR systems: it may be possible for the sending 
entity to change checksum modes in the event of a failure, in order in 
order to reduce power utilization and/or computational complexity. 

What would be possible is to allocate a single checksum ID to be "MIB 
defined". If that ID is in use, then it's up to the sender/receiver to 
determine the checksum out-of-band, but I think that would require some 
changes to the blue book.

Thanks,
Jeremy 

From: SIS-CFDPV1 <sis-cfdpv1-bounces at mailman.ccsds.org> on behalf of 구철
회 <chkoo at kari.re.kr>
Sent: Wednesday, December 11, 2019 1:48:18 AM
To: sis-cfdpv1 at mailman.ccsds.org
Subject: Re: [SIS-CFDPV1] revised draft specification 

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
_______________________________________________
SIS-CFDPV1 mailing list
SIS-CFDPV1 at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-cfdpv1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-cfdpv1/attachments/20191211/62143c2d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 8524 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-cfdpv1/attachments/20191211/62143c2d/attachment-0001.bin>