[Css-csts] Pink SLE FSP Service Specification
Wolfgang.Hell at esa.int
Wolfgang.Hell at esa.int
Wed Apr 10 08:43:15 EDT 2013
John,
Thank you very much for your very thorough review of the draft FSP Pink
Sheets. I certainly do not mind your bending of the Pink Sheet rules. On the
contrary, I appreciate the additional input that certainly contributes to
further improving the Book. In what follows, you'll find my response to your
comments. I really hope that the two of us get a chance to discuss the
various SLE issues, but I understand that you will at most be partially
available for the Tuesday session.
1. Blocking of TC frames
What this term was meant to refer to is indeed putting several TC frames into
one CLTU. I remember that we concluded at the time when we produced the
initial version of the FSP Book that the gain of TC link bandwidth efficiency
when using very long CLTUs is small while the overhead when it comes to
retransmissions is significant. Therefore it was agreed to constrain FSP to
the single TC frame per CLTU configuration. It appears to me that these
considerations are still valid and I therefore suggest that we keep this
constraint.
Sorry that I contributed to the confusion when I added section B5.5 as to
cover the option of repeated TC frame transmission. I will remove the
discussion on why a single TC frame per CLTU should be used in 'hammer mode'.
And what concerns the long two-way light-time, the intended message here was
that the 'hammer mode' should only be used on such links. If the round-trip
time is short, one is much better off when using COP-1.
Given all that, I gratefully accept your suggestions a) to d) with two minor
tweaks:
a) as per your suggestion;
b) as per your suggestion. In addition I have modified 2.4.1.3 d) from "The
Forward CLTU Generation SLE-FG forms a CLTU by appending Start and Tail
sequences to the BCH Codeblocks representing the block of one TC frames." to
" "The Forward CLTU Generation SLE-FG forms a CLTU by appending Start and
Tail sequences to the BCH Codeblocks representing one TC frame.
c) as per your suggestion;
d) I did not delete NOTE 2 completely, but kept the first sentence that reads
"For a link with long light time delay, the repeated transmission of frames
can improve the probability that a sequence of frames is successfully
received during a limited transmission session." This might be helpful to
readers who have not been confronted with the ' hammer mode' so far.
2. Absence of the Segment Header
The Segment Header is required when at least one of the following conditions
is TRUE:
- the (optional) MAP addressing is used on the given VC;
- TC packets may be larger than the data field of the maximum size TC frame
and therefore need to be segmented.
If neither of the two conditions is TRUE, the segment header can be omitted.
CCSDS 232.0 provides the related information:
4.1.3.2 Frame Data Unit
4.1.3.2.1 General
4.1.3.2.1.1 A Frame Data Unit shall consist of either
a) an integral number of User Data octets; or
b) a Segment Header followed by an integral number of User Data octets, if
the Segment
Header is used on the Virtual Channel.
4.1.3.2.1.2 If the Segment Header is present, the User Data contained in a
Frame Data Unit
shall consist of one of the following:
a) a complete Packet;
b) multiple Packets;
c) a portion of a Packet;
d) a complete MAP_SDU;
e) a portion of a MAP_SDU.
4.1.3.2.1.3 If the Segment Header is not present, the User Data contained in
a Frame Data
Unit shall consist of one of the following:
a) a complete Packet;
b) multiple Packets;
c) a complete VCA_SDU.
4.1.3.2.1.4 The Segment Header is required for any Virtual Channel which has
more than
one MAP or which transfers service data units larger than permitted in a
single Transfer
Frame. Its use is optional otherwise, except that if it is used in any
Transfer Frame carried on
a Virtual Channel, it must be used for all Transfer Frames carrying Frame
Data Units (not
Control Commands) on that Virtual Channel.
NOTE – A Frame Data Unit that has a Segment Header is called a Segment.
Hence one special case of the MAP multiplexing is that only a single MAP is
supported on a given VC in which case the MAP address is not used at all. If
in addition all TC packets are sufficiently short to fit into a single TC
frame, the segment header can be omitted. Given that even a well-informed
person like you raises such question is a strong indication that we need to
add related information to the FSP Book. I read annex B again and my
impression is that the case that no MAP multiplexing is used is adequately
addressed. So at least for now I have not introduced any changes there.
However, I have inserted the following NOTE after 3.6.2.10.2: NOTE –
Segment Headers have to be generated if a) Space Packets may exceed the
length of the user data zone of the maximum and/or if b) MAP addressing is
used on the given telecommand Virtual Channel.
Please let me know if you regard that to be sufficient or if there is a need
to add more tutorial type of information.
3. RAF NOTE in FSP
I have removed that NOTE.
4. Handling of the responder-port-identifier parameter in the BIND invocation
After we had prepared the Cleveland slides, further rounds of discussions
took place and a softer way of dealing with this problem was proposed, mainly
as not to make implementations that check this parameter 'not compliant'.
However, what we are talking about are anyway new versions of the SLE
services and therefore this should not really matter too much. And having
read through your material, I agree that we better come up with unambiguous
requirements. Therefore I have gratefully adopted your suggestions on how to
modify the FSP Book.
5. Potential risk of Space Packets not being processed in case the MAP
multiplexing scheme is 'Polling Vector'.
The NOTE following 3.6.2.10.1 is only intended to provide a warning that with
that a segments queue might get blocked. This is not a requirement, but a
consequence of how the MAP multiplexing is performed. I have added a forward
reference to annex B that specifies the behaviour.
6. Missing return
I share your concern. I have therefore modified the last sentence of NOTE 3
in 4.1.3 to now read: "Therefore, following an FSP-UNBIND invocation, the
‘return timeout’ FSP-EER-ABORT may be triggered by a missing return."
7. Service instance provision period
For some reason, out 'to-do' list had flagged this issue as not being
applicable to FSP and therefore no change had not been made. I now have
updated the FSP Book the same way as the return service specifications have
been modified. Also the typo has been corrected.
8. Not initialised, but gettable and not gettable parameters
I think that you are raising two separate issues:
a) Shall we make any (managed) parameter or user-controlled parameter that
gets added to an SLE specification always gettable at the expense of the
associated ASN.1 changes? What I have seen in practice, the GET-PARAMETER
operation is hardly used and therefore at least in the case of F-CLTU we had
postponed the update of the list of gettable parameters until we felt that
the overall scope of the changes were anyway such that the extension of the
gettable parameters list was not really a cost driver. In this spirit, I have
refrained from extending the FSP list of gettable parameters at this point.
Should the WG identify a strong need to make all parameters gettable, I'll be
happy to update the FSP Book accordingly, but until we have a WG decision, I
prefer to leave the specification alone in that regard.
b) Do we need to deal with not yet initialised, but gettable parameters?
After the Cleveland meeting, this topic has been discussed on various
occasions and in addition to the options already listed in the Cleveland
presentation I made yet another suggestion that if accepted avoids the issue
completely. We could as part of the service specifications define initial
values for all those parameters that for the time being could be retrieved
using the GET-PARAMETER operation before being initialised. I feel that this
topic will require some further discussion within the CSTS WG. Therefore I
have deferred related FSP updates until we have reached agreement in the WG.
9. repetition-limit managed parameter
I did not feel comfortable introducing this parameter. In fact, I do not see
that it would ever play a role in FSP. The only reason it is there is that
CCSDS 231.0 introduces it (and there it is really needed) and I thought that
it might be good to have that parameter then also as a managed parameter in
FSP. But strictly speaking it does not serve any purpose from a functional
point of view and could be removed.
I will upload to the CWE (CSS-CSTS - CWE Private - SLE Services) a new FSP
version which reflects the changes as discussed above. Obviously, this isn't
the final version since there are a few items for which we still need some
discussion in the WG as to agree on how to resolve them.
Best regards,
Wolfgang
|------------>
| From: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|John Pietras <john.pietras at gst.com> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"Wolfgang.Hell at esa.int" <Wolfgang.Hell at esa.int> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"css-csts at mailman.ccsds.org" <css-csts at mailman.ccsds.org> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|01/04/2013 19:28 |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|RE: [Css-csts] Pink SLE FSP Service Specification |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|css-csts-bounces at mailman.ccsds.org |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
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
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
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.
More information about the Css-csts
mailing list