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

[John Pietras]

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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120130/3474a8eb/attachment-0001.htm