[Cesg-all] Re: Rick Schnurr's comments re: AOS Pink Sheets

[Greg J Kazz]

Adrian,

My comments are in ** ** below.

At 7/14/2003 12:20 PM, you wrote:
>At 11:11 AM 7/14/2003, Greg J Kazz wrote:
>>Good catch.  The 3-bit field, VCDU extension field is optional and I will 
>>document it as such. Those missions that don't require it will simply set 
>>these bits to all zeros (same value as when the field was defined as 'spare').
>
>Greg:
>
>1: If the field is optional, how do you know whether a mission is using it 
>or not? [I hope that you aren't going to say "it's managed"....] Doesn't 
>this need some in-line protocol to signal whether the optional field is in 
>use?  It would seem that this assignment materially changes the semantics 
>of the "Signalling Field" and is therefore not in line with the definition 
>of this field in para. 5.4.9.2.1.1.9a


** The rationale for this field is to allow high rate mission to have a 
sequence counter that doesn't rollover during a pass. This would also 
benefit missions flying SSRs using AOS frame retransmission. Those missions 
that do not require the extra field, simply set it to  all zeros, which 
they currently do today, because it is defined as a spare. Those that do 
use it, will increment those bits accordingly. **


>>As to your second question, high data rate missions that plan to use AOS 
>>frame retransmission are requesting it. First customer is MRO (Mars 
>>Recon. Orbiter).
>
>2: Surely Pink Sheets which introduce a material technical change should 
>be accompanied by a corresponding update to the Green Book that provides 
>the rationale for the change? Shouldn't you also build the case for why 
>CCSDS as a whole should approve this change? For instance, if only a 
>limited number of missions want it, maybe it could be handled as a local 
>matter or as "Experimental"?



** AOS was designed for SSF and ESA 's Hercules. Not a large contingent of 
users. **




>3: Plenty of current "high data rate missions" get along without this 
>change. If it's coupled to "high data rate missions that plan to use AOS 
>frame retransmission", then why isn't this change being packaged along 
>with the ARQ procedures, so that everyone can see the whole technical 
>picture and the whole rationale?


** I responded to a final action item #4  from P1A, by releasing the Draft 
Pink Sheets to the successor of P1A i.e.,  the WGs that were approved at 
the last P1A meeting in ESTEC. Now that this action is completed, the whole 
story can be weaved together. **




>4. Section 3.2.2 of the CCSDS Restructuring (Volume 2) states:
>"At some point in the evolution of a Draft Standard that is intended to 
>result in a change to mission support infrastructure, at least one 
>hardware or software prototype (or other implementation) must exist which 
>demonstrates and exercises all of the options and features of the 
>specification in an operationally relevant environment, either real or 
>simulated. This point may be Issue-1, or it may be a later Issue depending 
>on circumstances, but for most documents the implementation must exist 
>prior to issuing a "final" Draft Standard. The WG Chair is responsible for 
>documenting the specific implementation(s) that qualify the specification, 
>along with reports relevant to their testing, or for justifying why such 
>implementation is either inappropriate or should otherwise be waived.  The 
>documentation of the qualifying implementation must include clear 
>statements about its ability to support each of the individual options and 
>features. "
>Where is this point being addressed?

** Next step **







>5: Finally, could you perhaps provide the "audit trail" for this change? 
>Did these Pink Sheets result from an archived discussion on a Space Link 
>Protocols WG, and if so could you please refer to the list ID? Were they 
>approved by the SLS Area before being sent out for formal review?


** It was an approved action item by P1A, which I distributed to P1A and 
you.  See below. **

IV. Pink Page Change to AOS Blue Book

1.  Essentially, replace 3 of the 7 spare bits that precede the frame 
sequence number of the AOS transfer frame to create a new field called, 
"frame cycle number". This number will increment by 1 every time the FSN 
exceeds 2**24 counts. The frame cycle number is a 3 bit, mod 8 counter.



>///adrian
>---------------------------------------
>Adrian J. Hooke
>Chairman, CCSDS Engineering Steering Group (CESG)
>
>>>>Date: Fri, 11 Jul 2003 12:49:27 -0400
>>>>From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov>
>>>>Subject: Re: [Cesg-all] Re: [CMC] RP A3-07 Announcement of 
>>>>Review  Opportunity
>>>>To: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>>>>
>>>>Hi Adrian,
>>>>
>>>>In reading this spec.  it is hard to determine if the new bits are 
>>>>optional or a mandatory extension. In the first instance the 
>>>>parenthetical statement sends one to another point in the document for 
>>>>information on how to extend the field.  The description of the field 
>>>>itself reads as if one must increment the field by one at the appropriate time.
>>>>
>>>>So I ask the question:  Is the intent to require the use of the 
>>>>extension for future implementations or is it an option for people who 
>>>>want to use it?
>>>>
>>>>Second question who wants this change?
>>>>
>>>>Rick
>>>>
>>>>At 03:40 PM 7/10/2003, you wrote:
>>>>>At 11:38 AM 7/10/2003, ccsds_rapporteur wrote:
>>>>>>The following draft CCSDS Recommendation has been placed on line for 
>>>>>>CCSDS Agency review:
>>>>>>      CCSDS 701.0-P-3.1.  Advanced Orbiting Systems, Networks and 
>>>>>> Data Links: Architectural Specification.
>>>>>>                          Pink Sheets.  April 2003.
>>>>>>DOCUMENT DESCRIPTION:  This draft update to the Advanced Orbiting 
>>>>>>Systems, Networks and Data Links: Architectural Specification 
>>>>>>Recommendation modifies the VCDU Header by converting three of seven 
>>>>>>spare bits into a new VCDU Counter Extension 
>>>>>>field.    http://www.ccsds.org/review/rpa307/701x0p31.pdf
>
>