[Css-csts] Ambiguities in SLE RAF B-3

[John Pietras]

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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120127/94cd8c50/attachment.html