[Css-csts] Re: inaccurate references to FTCF SLE service in FSP specification

[Shames, Peter M (313B)]

Dear CSTSWG Colleagues,

I hate to be the Grinch this Xmas, but after reading through these docs I feel quite strongly that the identified inconsistencies and inadequacies in SLE-FSP, SLE-FCLTU (and potentially even SLE-RM) ought to be remedied.  The CCSDS five year review of documents is exactly the time when such issues should be addressed.   In particular, the references to this mythical FTCF service, and the lack of specificity about what is intended to occur between the input to one or more FSP service instances (with one or more inputs, according to the FSP spec) and the input to the FCLTU service seems like a serious oversight.  Even if the result of this added specificity results in some “all-in’one” implementation at the ground station, as John has suggested, I am left with the following questions:


 *   Does this FSP service (however it is implemented) support packet streams from more than one user?
 *   Does it support merging of packets from multiple instances of the FSP service?
 *   How are priorities handled between packets streams and different users?
 *   How is separating data into different virtual channels handled?
 *   Does this handle merging of both SPP and Encapsulation packets?

I am sure that there are more questions left unresolved, but these alone strike me as big enough to warrant further attention in the text of one or more of these documents.

Thanks, Peter



On 12/21/09 1:56 PM, "John Pietras" <john.pietras at gst.com> wrote:

CSTSWG colleagues ---

The Forward Space Packet (FSP) Pink Book (soon to be Blue-2) makes numerous statements about being carried by an underlying Forward Telecommand Frame (FTCF) SLE service. While in a formal sense this is a possible configuration (it is the one that is illustrated in the Cross Support Reference Model – Part 1 – SLE Services (often simply referred to as the SLE-RM), it is not necessary to have an underlying FTCF SLE service and in fact it cannot be so, since we have operational FSP services without having specified the FTCF service! This inconsistency was brought to my attention by Peter Shames, who asked how it could be possible to operate the FSP over a non-existent SLE service.

In fact, all that is necessary for the FSP SLE service to work is to have the *production processing* associated with the FTCF service and the FCLTU service. The only time that explicit FTCF and/or FCLTU services are needed “beneath” the FSP service is if the FSP service is “staged” across two or more Service Complexes, e.g.,

 1.  MDOS (FSP user) -> (intermediate) Complex A (FSP provider/MAP/ TC frame generation/FOP/FTCF User) -> Complex B (FTCF provider/CLTU generation/PLOP/RF & Mod);
 2.  MDOS (FSP user) -> (intermediate) Complex C (FSP provider/ MAP/ TC frame generation/ FOP/ CLTU generation/ FCLTU User) -> Complex D (FCLTU provider/ PLOP/RF & Mod);
 3.  MDOS (FSP user) -> (intermediate) Complex E (FSP provider/MAP/ TC frame generation/FOP/FTCF User) -> (intermediate) Complex F (FTCF provider/CLTU generation/ FCLTU User) ->
 4.  Complex G (FCLTU provider/ PLOP/RF & Mod)

Indeed, it is my understanding that at least some of the FSP configurations are directly provided by the ground station:
     MDOS (FSP user) -> Complex X (FSP provider/MAP/TC frame generation/FOP/CLTU generation/PLOP/RF & Mod)

Perhaps when the references to underlying FTCF SLE service were first written, it was expected to have an FCTF SLE service specification available shortly after. However, given that this is not the case, it is currently incorrect to state that the FSP service relies on the existence of the FTCF service. Even if and when the FTCF service *is* specified, in would still be inaccurate to imply that the FSP service must run in conjunction wit FTCF (and FCLTU) SLE service.

It is unfortunate that we didn’t discover this sooner, in time at be folded into the current Pink Book.  Is there anything that we can (and want to) do about this in the near term? Is it worth exploring what changes would be necessary to make the FSP book technically correct, even if the changes cannot be folded into the upcoming Blue-2 version?

Best wishes for the holidays,
John

John Pietras

GST, Inc.

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155




_______________________________________________________

Peter Shames
Manager - JPL Data Systems Standards Program
InterPlanetary Network Directorate
Jet Propulsion Laboratory, MS 301-230
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-0584

Internet:  Peter.M.Shames at jpl.nasa.gov
________________________________________________________
"We shall not cease from exploration, and the end of all our exploring
will be to arrive at where we started, and know the place for the first time"

                                                                                             T.S. Eliot



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20091221/4b6d41e4/attachment.htm