[Css-csts] RE: Ambiguities in SLE RAF B-3
Wolfgang.Hell at esa.int
Wolfgang.Hell at esa.int
Mon Jan 30 11:48:53 EST 2012
John and Martin,
Thank you for the close look that you have taken at these issues. It is
really amazing that after such long time being in actual use, such issues
still surface.
What I'm stating in what follows is my recollection of the related
discussions in the WG. However, since these have happened such long time ago,
chances are that what I believe to remember is not correct and of course I'm
open to any updates that remove actual or perceived ambiguities.
The reason why paragraph 3.1.9.2.12 addresses the abort case only is that for
an orderly closure of the SLE session the extracting of frames and
notifications from the online frame buffer stops due to the RAF-STOP
invocation and not due to the RAF-UNBIND invocation. As such the requirement
stipulated in 3.1.9.2.12 in fact only applies to the case that the
association is aborted as in the other case the data flow was already stopped
before the association is released by the RAF-UNBIND. From a provider
perspective the issue of 'incompleteness' applies only when the association
gets aborted because in that case the transfer buffer content gets lost. I
agree that the NOTE in 3.1.9.2.12 should for the reason addressed above not
address the case of a released association. This was probably intended to
cover the case of a not very smart user implementation that stops processing
frames as soon as the RAF-STOP has been invoked. We do not really prescribe
the user side state machine.
The unbind-reason 'end' was intended to allow a friendly user that signal to
the provider that everything has been accomplished and the resources are no
longer needed. Speaking of the ESA implementation, I confirm that we remove
the service instance and free all resources that it took to implement it
including the online frame buffer. In real life this resulted in all users
being 'unfriendly' and all implementations (except for initial configuration
errors) use 'suspend'. Therefore we don't have problem with 'permanent' SIs
in offline delivery mode. But please note that a conforming implementation is
free to keep the SI alive. This is an implementation choice to be made on the
provider side.
The UNBIND invocation in case of 'suspend' is not ignored. The compound
action {user unbind} is performed, but no further actions are taken. John,
how would you suggest to express that in the given IF THEN ELSE nesting? This
may not be the best way to express it, but I would not regards this to be an
error.
Looking at what is supposed to happen in case of STOP plus UNBIND and
PEER-ABORT, I think that the actions to be performed are correctly specified
with one exception. That is the discussion of resetting the parameters to
those specified in the service package. I can't think of any such parameter
and therefore (although due the absence of such parameters this error has no
effect) this should be removed - or if people feel more comfortable just in
case something might be in a service package as specified tomorrow, then it
has to be made consistent regardless which party initiates the PEER-ABORT.
In summary, it appears to me that two updates are advisable:
- In the NOTE in 3.1.9.2.12 the reference to a released association should be
removed.
- Either any reference to resetting parameter values to those defined in the
service package should be removed or made consistent. I would prefer the
former.
Best regards,
Wolfgang
From: "John Pietras" <john.pietras at gst.com>
To: Martin Götzelmann <martin.goetzelmann at vega.de>, "Wolfgang Hell " <Wolfgang.Hell at esa.int>
Cc: css-csts at mailman.ccsds.org
Date: 30/01/2012 15:37
Subject: [Css-csts] RE: Ambiguities in SLE RAF B-3
Sent by: css-csts-bounces at mailman.ccsds.org
Martin,
Thank you. Going through the nominal path of STOPping first before UNBINDing
provides the “stop release timer” and “reinitialize transfer buffer” actions
comparable to those performed in response to (rafPeerAbortInvocation). That
leaves the “reset parameter values to those specified in the service package”
action, which is performed in response to (rafPeerAbortInvocation) but not
for (rafUnbindInvocation) or when a peer-abortable error is detected by the
provider. Besides not being able to think off the top of my head of
parameters might be initially specified in the service package but then
changed by the execution of the service instance (such that they would have
to be reset on abort), I’m curious if there is a reason why they would be
reset in response to a user-generated PEER-ABORT invocation but not reset
when the provider itself peer-aborts, or if this is just an omission in the
specification.
Best regards,
John
From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Sunday, January 29, 2012 4:56 PM
To: John Pietras; Wolfgang Hell
Cc: css-csts at mailman.ccsds.org
Subject: RE: Ambiguities in SLE RAF B-3
Dear John,
As I was just looking into the B3 Books because of other issues, I have
cross-checked the state table. I think the difference between PEER-ABORT and
UNBIND is that UNBIND is not accepted in the state 'active' and the user must
invoke STOP first. Row 10 in the RAF book specifies the behaviour for the
online complete and offline modes when STOP is invoked and it does say that
any pending transfer buffer shall be transmitted before the STOP return. Of
course, if a BIND is issued in the state 'active' the the provider will abort
the connection because of a protocol error and the data will be lost, but I
beleive that is not the case you wanteded to address.
The other points you raised might still be valid - I also do not understand
why the note following 3.1.9.2.12 refers to "release or abort".
Kind Regards, Martin
From: css-csts-bounces at mailman.ccsds.org [css-csts-bounces at mailman.ccsds.org]
on behalf of John Pietras [john.pietras at gst.com]
Sent: 27 January 2012 22:44
To: Wolfgang Hell
Cc: css-csts at mailman.ccsds.org
Subject: [Css-csts] Ambiguities in SLE RAF B-3
Wolfgang,
I started to trace through the requirements for handling the online frame
buffer in RAF-B-3, and ended up stumbling across some ambiguities and in at
least one case what I believe to be an error. (I believe that these comments
also hold for RCF and ROCF.)
1. Paragraph 3.1.9.2.12 states “In the complete online delivery
mode, the transfer buffer shall be cleared and removal of frames and
synchronous notifications from the online frame buffer shall stop
whenever the association is aborted. ” Should this not also be the case
when the association is released via the UNBIND? The NOTE that follows
states “The requirement 3.1.9.2.12 implies that a truly complete
delivery can only be achieved within a given association. Recovery from
data loss caused by an association termination (release or abort) can
only be accomplished by using the offline delivery mode.” This note
implies that 3.1.9.2.12 also applies to UNBIND as well as abort.
I looked at the state table to see if it could help my understanding.
a) In response to (rafUnbindInvocation) while in state 2, for a
was user-initiated association:
1) The provider performs {user unbind} (stop reporting cycle
timer, stop all return timers, issue (rafUnbindReturn) and
transitions to state 1;
2) if the UNBIND invocation has ‘end’ for the unbind-reason,
the provider releases resources. “Release resources” is used in
section 3.3.2.4.2 but not defined. I assume that it includes
clearing the online frame buffer. If this is so, it might be
helpful to state so in section 3.3.2.4.2 . See more comments
below in item 2 related to the ‘end’ unbind-reason.
3) Curiously, according to the state table, if the UNBIND
invocation does not have ‘end’ for the unbind-reason, the
provider is supposed to “[ignore]”. What is to be ignored? The
UNBIND invocation can’t be said to be ignored if the provider has
acted on it (stopped timers, issued an UNBIND return). This
appears to be an error.
b) In response to (rafPeerAbortInvocation), the provider
performs {clean up} (stop release timer, stop all return timers,
stop reporting-cycle timer, reinitialize transfer buffer, and reset
parameter values to those specified in the service package). {clean
up} contains three more actions (stop release timer, reinitialize
transfer buffer , and reset parameter values to those specified in
the service package) than in the {user unbind} occurs in response to
an UNBIND invocation. Is this correct?
c) Triggered by various error conditions encountered by the
performer, the performer performs {peer-abort ‘xxxx’} (stop release
timer, stop all return timers, stop reporting-cycle timer,
reinitialize transfer buffer, and send (rafPeerAbortInvocation) with
diagnostic set to ‘xxxx’). However, it doesn’t reset parameter
values to those specified in the service package, as required in
response to a PERR-ABORT invocation. Is this correct?
2. In section 3.3.2.4.2 (a) ‘end’ value for the unbind-reason
parameter states “If unbind-reason is ‘end’, any subsequent attempt to
invoke RAF-BIND will fail even if the service instance provision period
has not expired, since the service provider may release the resources
allocated to that service instance.”
a) As a NOTE, this is informative. However, I can’t find any
normative text that supports it. In particular, I would expect the
BIND negative result return to have a diagnostic something like
‘service instance ended’. The presence of the diagnostic would also
add that conditions to the ones that would force the
(-rafBindReturn) that would keep the service instance in the
unbound. Is the inhibition of subsequent BINDs actually implemented
in the API and/or operational implementations.
b) If the intention of the ‘end’ value does indeed include that
subsequent BIND invocations are forbidden, this seems like a
potentially dangerous value for service instances in the offline
delivery mode, especially those that are set up to be basically
“unscheduled”. Given that the user on an offline service instance
has to provide the data start and end times in the START, can STOP
the transfer any time, and can UNBIND with ‘suspend’, the ‘end’
seems unnecessary for offline. This is just an observation – I’m not
making a recommendation.
Best regards,
John _______________________________________________
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