[Css-dts] Re: Another SLE RAF Question

[Michael Stoloff]

Brian,

This is not the first time that this particular question has come up.  What 
follows is just my interpretation of the CCSDS RAF Blue Book Issue 1 and my 
understanding of the JPL implementation of RAF service.  I have copied the 
CCSDS Data Transfer Services working group on this message, and I welcome 
any corrections or differing interpretations.

My first comment is to suggest that use of start and stop times with online 
delivery mode is probably not a good idea to begin with.  In practice, both 
JPL and ESA generally set those times to "null" for online delivery 
mode.  I believe that the start and stop times in the RAF-START operation, 
while permitted in online delivery mode, were intended primarily for use 
with offline delivery mode, which is how we use them.

However, the RAF Blue Book does permit use of start and stop times with 
online delivery mode, so the question you raise ("Should the service return 
frames that were previously returned in [a prior] session?") is a valid 
one.  Various drafts of the specification answered that question 
differently, and the RAF Blue Book Issue 1 may even contain some language 
that is at least ambiguous and possibly incorrect (another reason not to 
use this feature).

This issue was discussed explicitly by the working group during the review 
process that preceded publication of the RAF Blue Book.  My recollection of 
that discussion is that the working group intended that once a frame is 
delivered, it is actually removed from the online frame buffer and, thus, 
is not available for re-delivery following a re-bind.  This is in contrast 
to the offline frame buffer, where the contents are intended to be 
persistent for some time (days or even weeks).

I am not certain of the behavior of the actual JPL implementation.  I 
believe that, in the case of complete online delivery mode, the JPL service 
provider would re-deliver frames even though they had been delivered in a 
previous session.

I hope that this information is of some use to you.  As previously noted, 
comments, corrections, and other interpretations are welcome.

--Regards,
   Michael

At 02:27 PM 8/14/2003 -0400, Brian Safigan wrote:
>Michael,
>
>I thought I asked you this question before, but I can't find the email, so 
>sorry if you already answered this.
>
>CSOC and Avtec has a difference in interpretation of the RAF 'Complete 
>Online Delivery Mode' implementation. We implemented an online frame 
>buffer that stores all of the frames of a pass to a file. When a user 
>'Starts' the service in Complete Online Delivery Mode, they specify the 
>range of times to return.
>
>The difference in interpretation has to do with what happens if a user 
>Stops and Restarts the service with the same range of times to return. 
>Should the service return frames that were previously returned in the 
>first session?
>
>The specification is not clear on this. CSOC pointed out that...
>
>According to RAF Spec 3.1.8.2.4 "While the RAF service provider is in 
>state 3 ('active') and the transfer buffer is not full, the provider shall 
>remove RafTransferDataInvocation and RafSyncNotifyInvocation records from 
>the online frame buffer and insert them, in the same sequence, into the 
>transfer buffer."
>
>The word 'remove' implies that the frame will not be available for future 
>sessions. However later in the spec...
>
>3.1.8.2.10 "In the case that the user invokes the RAF-STOP operation or 
>the association becomes unbound, the user may, after re-binding if 
>necessary, invoke a new RAF-START operation, with a start time in the 
>past, to effect delivery of the data buffered in the online frame buffer. 
>Any frames with an ERT older than the start time specified in the 
>RAF-START operation and any notifications falling into the same interval 
>shall be removed from the online buffer."
>
>We interpret this to imply that the frames from the ENTIRE pass should be 
>available for retransmission in case the user restarts the service. 
>However, I can see how CSOC may be correct. If the frames are in fact 
>removed from the buffer, I assume it is only removed for a single service 
>instance (since several service instances may be assigned to the same 
>physical channel).
>
>Could you please clarify this and tell us how you and ESA interpreted this?
>
>Thanks for your time,
>Brian Safigan
>Avtec Systems
>(703) 219-1861