[Css-csts] Pink SLE FSP Service Specification

[John Pietras]

Wolfgang,

Here are my comments on the Pink Sheet changes, which for the most part seem perfectly reasonable to me. Technically, comments on "Pink Sheets" can only address the changes that are proposed in those sheets. However, having just gone through the exercise of trying to map the FSP managed and monitored parameters onto the underlying production FG Types, I've come across a few other items. I hope that you don't mind my bending the Pink Sheet rules a bit so that I can raise them here.



1.       Section 2.4.1.2, third paragraph, item (a): The third sentence states "The FSP service does not support blocking of TC Frames." I don't understand this sentence, even though I may have written it myself.  There are two uses of the term "blocking" that are defined in the specification: the first refers to blocking/non-blocking operations and the second refers to putting multiple Space Packets into a single TC Transfer Frame. "Blocking of TC Frames" is not defined. One thought is that this may refer to placing multiple TC Frames into the same CLTU. I seem to recall discussing imposing that limitation. However, section 2.4.1.3, paragraph 2, item (c) states "The Forward CLTU Generation SLE-FG BCH-encodes each  block of TC frames [emphasis mine ]into a set of BCH Codeblocks". Also, NOTE 2 under B5.5 talks about limiting the number of frames per CLTU to one long-light-time-delay links, implying that for short delay links multiple frames per CLTU is possible.

If "blocking of TC Frames" is intended to refer to putting multiple frames into the same CLTU, then I suggest the following clarifications:

a.       Remove the sentence "The FSP service does not support blocking of TC Frames" from item (a) of 2.4.1.2. Section 2.4.1.2 deals with the Forward TC VC Data Insertion FG: discussion of how CLTUs are built belongs in 2.4.1.3 (Forward CLTU Generation SLE FG).

b.      Change the sentence in 2.4.1.3 item (c) to read "The Forward CLTU Generation SLE-FG BCH-encodes each TC frame into a set of BCH Codeblocks".

c.       These statements in section 2 are only informative - there is no normative statement regarding how many frames can be put into a CLTU. In Annex D, insert a new requirement and note after D1.2.2.1: "The Forward CLTU Generation FG shall form a CLTU Transfer Data SLE-SDU for each TC Frame Transfer Data SLE-SU.
NOTE - Although the TC Synchronization and Channel Coding specification (reference [x]) allows a CLTU to contain multiple TC frames in general, the SLE FSP service restricts the CLTU to containing a single TC frame.

d.      Delete NOTE 2 of B5.5.



If "blocking of TC Frames" does not refer to putting multiple frames into the same CLTU, and if putting of multiple frames into a CLTU is allowed, then:

a.       Some definition of 'blocking of TC Frames" is needed and

b.      Some mechanism must be specified for determining how many frames are to be put into a CLTU. E.g., a frames-per-cltu managed parameter of the Forward CLTU Generation SLE-FG.



2.       This may just be due to my admittedly-weak understanding of Telecommand, but I don't understand how having segment headers in the frames can be turned off for the FSP service. Annex B specifies that all FSP instances flow their packets through MAP Multiplexing. It's my understanding (again, it may be a misunderstanding) that when MAP Multiplexing is used then segment header must always be used (to identify the MAP channels) except in Control frames, in which case segment headers are never present. So what am I missing here?



3.       Section 3.2.2.6: the first NOTE is for RAF service and should be removed (its content is covered in an FSP version in the notes below).



4.       Section 3.2.2.6: the flavor of this section is slightly different from that in the slides presented in Cleveland, especially regarding the behavior of the responder when the value is incorrect - the slide says that the parameter *should* be ignored by "provider implementations"*, whereas the Pink Sheet say in a (non-normative) note that the parameter *may* be ignored. [*Given that we are reaffirming the notion of provider-invoked Return services, this should be "performer implementations"].  At the risk of micro-editing this section, here are my suggestions:

a.       Put the NOTE explaining the use of this parameter at the beginning , right under 3.2.2.6 responder-port-identifier: " NOTE 1 - The responder-port-identifier parameter is included in the FSP-BIND invocation to support its possible use by particular kinds of gateways. It is used by such gateways to complete the association with the responding SLE application entity, and it is not intended to be used by the responding SLE application entity itself. Beyond this statement, the behavior of such gateways is beyond the scope of this Recommended Standard."

b.      Enumerate the requirement so that a second requirement can be added: "3.2.2.6.1  The responder-port-identifier parameter shall  specify the port identifier of the responding SLE application entity with which the initiator seeks to establish an association." (I'd also recommend substituting "contain" for "specify" to remove the implication that the initiator is defining the port identifier on the fly (as stated in a following NOTE, it has been pre-negotiated), but I don't have a strong feeling about it).

c.       The Cleveland slides stated that the responding SLE application entity should ignore a bad responder port ID, leaving the possibility that an implementation doesn't ignore it, resulting  in the case where  "the BIND fails with no return". However, the state table makes no provision for "failing with no result". I think that what really happens is that the responding SLE application entity must ignore the bad values (in effect, it must ignore the parameter altogether) and return a positive result regardless of the value of the responder-port-ID (assuming, of course, that the invocation is otherwise successful). The BIND "failing without return" occurs when the gateway can't complete the association because of the bad ID - the target responding SLE entity never gets the invocation in the first place, so there is no possibility for the responder to "fail without return". If this is the acceptable interpretation, then:

1)       I propose a second requirement:  "3.2.2.6.2  The responding SLE application entity shall ignore the value of the responder-port-identifier for purposes of determining the validity of the invocation." (This wording allows for the possibility of using the value for something, e.g., an error log).

2)      Rephrase what is now NOTE 4 to address more specifically how it is that a BIND operation will fail because of an invalid responder-port-identifier: "In case the association between user and provider is established via a gateway and the value of the responder-port-identifier parameter is incorrectly set, the gateway will not be able to relay the BIND invocation to the target responding SLE application entity. The lack of a return for the FSP-BIND operation will trigger the 'return timeout' event on the user side. As specified in XXX, the user will abort the association by invoking the FSP-PEER-ABORT operation with the diagnostic parameter set to 'return timeout'."



5.       Requirement 3.6.2.10.1 (MAP-identifier): The NOTE appears to be levying behavioral requirements (e.g., "the packet will be queued but not processed ..."). Is this just a summary of behavior that stated normative somewhere else in this document (e.g., annex B) or in the TC Space Data Link Protocol Blue Book, or is it state uniquely in this NOTE? If it's stated uniquely in this book then it should be turned into normative statements. If there are normative statements elsewhere, a cross-reference would be nice.



6.       Section 4.1.3, NOTE 1, last sentence: the phrase "missing return event" may still mislead someone into thinking that this is an event (i.e., Incoming Event). Unless I am wrong, I think that the intent of this sentence is "Therefore, following an FSP-UNBIND invocation, the 'return time' PEER-ABORT may be triggered by a missing return."



7.       I see that there has been no change to the fourth sentence of the second-to-last paragraph of section 2.6.4.5: "Prior to the start time of a service instance,...". I had pointed out that the only formally-defined notion of a time of viability of a service instance is the service instance provision period - "start time of a service instance" is undefined. Your PowerPoint slide on the topic asked "The concept of the service instance provision period shows up in various places - is that adequate given that (most of the) real world implementations actually operate with permanent/default service instances?" I was not present of the discussion of this item (if any) in the CSTSWG meeting, but my counter-question would be, even if a service instance is permanent, how is the notion of "start  time of the service instance" different from "start [or beginning] of the service instance provision period"? They seem the same to me.

Also, the typo still exists in that sentence - it should read "... SLE Complex Management and SLE Utilization Management must mutually ..."


8.       In the comments that I had made on FCLTU last year, I had raised the question about what the CLTU-GET-PARAMETER operation should return when the value of clcw-physical-channel or clcw-global-VCID is requested when there is no CLCW-bearing return VC. Your PowerPoint slides identify 3 possible solutions: use default values that are indicative of the "not used" status (as is does for EFCLTU); allow anything to be put in, with understanding that they are meaningless when the FCLTU service instance is otherwise configured to ignore them; or modify the ASN.1. I wasn't in the CSTSWG meeting when this was discussed so I don't know the outcome (the Minutes of the Meeting don't mention it).  Regarding the FSP service, table 3-1 also includes the clcw-physical-channel and clcw-global-VCID as managed parameters, although (unlike FCLTU) they are not listed as gettable parameters via FSP-GET-PARAMETER. Nevertheless, similar questions apply. In particular, is it possible to configure an FSP instance to *not* use CLCWs - e.g., to send bypass-only commands "in the blind"? If so , whatever decision you've made regarding how to treat clcw-physical-channel and clcw-global-VCID for a non-existent CLCW-bearing channel should also be applied to the FSP book.



9.       Regarding the repeated frame transmission topic (a.k.a. "hammer mode"), I don't see any problems with your approach. However, if I understand it correctly, the purpose of the repetition-limit managed parameter seems to be to limit the values of the cop-control-frames-repetition and sequence-controlled-frames-repetitions managed parameters. If that's true, then I'll make the observation I don't think until now that we've introduced managed parameter to control other managed parameters in the SLE specifications. That is, we have had managed parameters that limit the values that can be used in the operations and managed parameters that set a configuration value. Strictly speaking, I don't think that this is necessary:  the upper bounds on clcw-physical-channel and clcw-global-VCID might be set by implementation or Agency and doesn't necessarily have to be managed on a case-by-case-basis between UM and CM.  Also, none of these three parameters (repetition-limit, cop-control-frames-repetition and sequence-controlled-frames-repetitions) have been added to the gettable parameters in table 3-11, even though it seems that they might be as interesting to the user as any of the other gettable parameters that simple reflect to configuration of the service. Were these parameters omitted from table 3-11 to keep the ASN.1 unchanged or because they were determined to be of no possible interest to the user?



Best regards,

John



-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Wolfgang.Hell at esa.int
Sent: Friday, March 22, 2013 9:38 AM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Pink SLE FSP Service Specification





Dear CSTS Working Group Members,



At the Cleveland meeting we had a session to review various issues that had been found mostly by John in the most recent SLE Blue Books. I have uploaded to the CWE (CSS-CSTS - CWE Private - SLE Services) the 'pink' version of FSP which I believe fixes all known problems with the exception of the handling of gettable, but not yet initialised parameters for which we need to come to a consensus position in the WG. The most important changes are that now the FSP-THROW-EVENT operation can be disabled for a given service instance and that the repeated transmission of TC frames is now supported. As a consequence, there are new managed parameters that will have to be taken into account on the Service Management side.



For both of these changes I have opted for the least intrusive modification.

Please have a look and let me know, if with these changes in place FSP in your view covers the operational needs.



Best regards,



Wolfgang





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.





_______________________________________________

Css-csts mailing list

Css-csts at mailman.ccsds.org<mailto:Css-csts at mailman.ccsds.org>

http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130401/15458837/attachment-0001.html