[CESG] CCSDS liaison presentation to IOAG

[Shames, Peter M (312G)]

Ciao Nestor,

I have just looked at some of the slides in this deck in detail and must admit I am confused and troubled by some of the statements.  The particular ones that are a concern are pg 17 (forward file service) and pg 19 RUFT vs ANSI/AIAA S-124-2007e.  The other general concern is just why we are now asking the IOAG for approval for so much of our work.

Pg 17 Forward File Service

What concerns me about this is the whole discussion of "We assume that this is an application of GFT(Generic File Transfer)  to CFDP injection with the injection processing occurring either in the Ground Station or in the MOC. This means COP-1 + CFDP can be closed either at the Ground Station or the MOC."  My understanding is that the whole GFT and Forward File approach is that GFT is used to transfer the file from the user to the Ground Station and then the CFDP agent runs in the ground station, for forward and return.  It is certainly possible that GFT could be used between one mission MOC and another mission MOC, but I do not recall that as being a configuration that the IOAG considered.  Also, I do not really think it is an issue whether it is one agency doing this or two, the same services and interfaces can work.

But the key point where there is an issue is this: If it is a mission MOC running the CFDP agent,  processing a file into CFDP PDUs, and running the COP at the link layer (where it is needed), then the cross support service is NOT GFT, it is just normal link layer SLE services.

>From my earlier involvement with the IOAG as these service definitions were being developed what was envisioned was a MOC to Ground Station configuration in a cross support mode.  I think if we start to introduce this MOC A to MOC B to GS discussion we stray into territory we might better off avoid.  I think we ought to stick to just the MOC A to GS B discussion and leave the rest of this complexity out of it.  There is quite enough complexity just dealing with that configuration vis-a-vis where the CFDP and COP is run.  And the complexity there is that someone, somehow, must both implement that CFDP, ENCAP (or SPP), frame creation, frame merging into a VC, encoding, and COP in the GS along with the means to define how it is to be done and manage it.  The normal SLE F-CLTU has none of these features, in fact, that is why CSTS Forward Frame was invented, since it can do all of that.

Pg 19 RUFT vs ANSI/AIAA S-124-2007e

The issue here is that the RUFT is, as you state, somewhat complex since it is now being defined to not only do the "unframeed telemetry", but the concept has been extended to really be a "return anything that shows up, framed or unframed."   This is an interesting concept, but it is beyond what was originally envisioned in the RUFT.  However, this concept, as stated, does not include all of the capabilities of that ANSI/AIAA S-124-2007e spec.  The ANSI/AIAA S-124-2007e spec specifically provides for the return of both clock and data, not just the data.  The reason for this was to support use of this SLE variant with physical layer link encryption boxes that require synchronized clock and data at the input.  This is a feature that must be in RUFT if it is to replace the ANSI spec, but I do not think that it is in the present RUFT discussion, which has veered away from this use in returning both encrypted data and data that is "broken" and not frame synchable, to this more generic "framed or unframed" data approach that does not, to my knowledge, any longer include the encrypted stream clock and data feature.

The last comment that I wish to make is that by going down this "Let's ask the IOAG if they like this" path, for more than just the SSI ADD, we are shifting the CCSDS to IOAG interface from what it has been, I.e. the IOAG provides something like "requirements" that the CCSDS must then, using its own processes, turn into standards, to a situation where we are now asking the IOAG for permission to do our work.  I think that this is a slippery slope and we should not go in this direction or we will wind up with an even longer, and more convoluted path for approving standards and we, CCSDS will give up control over what we produce.

I urge you to reconsider this approach.

Regards, Peter





From: Nestor Peccia <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>
Date: Friday, May 2, 2014 5:15 PM
To: CMC <cmc at mailman.ccsds.org<mailto:cmc at mailman.ccsds.org>>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: [CESG] CCSDS liaison presentation to IOAG

Dear all,

Please find attached the CCSDS liaison presentation to be done at the mini IOAG to be held on Tuesday 6th May 2014 during the SpaceOps 14 Conference



ciao
nestor

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20140505/fa6d588e/attachment.html