[Css-csts] Updated draft FRM Magenta Book on CWE

[John Pietras]

CSTSWG colleagues ---
I have performed another update of the FRM draft Magenta Book (MB). The latest updates include:

-        Updates in response to Wolfgang's review of the previous draft;

-        Modifications in response to recent CCSDS Space Link Services Space Data Link Protocols (SLS-SDLP) WG's changes in the TM, AOS, and USLP (fixed length frame) specifications (more on this below); and

-        Other typo corrections and minor clarifications.

I have uploaded two versions of the draft FRM MB. The first is the update of the "Complete" White Book (v 0.10), which contains whatever draft material has ever been generated about any FR Set and/or FR that has ever been considered over the many years since the FRM book started as a WG-internal Tech Note. Some of the FR Sets/FRs are not going to be included in the first published issue of the FRM MB and so the "Complete" version serves as an archive for a future time if and when the WG desires to add some of those FRs into the Model. Of course, this is just potential source material - the actual future FRs may be organized differently, have different names, etc. The Document Control section of the document also covers the history of the MB since its beginnings as a Tech Note in 2013.

The Complete version of the draft MB can be found at:
https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Functional%20Resource%20Model%20Magenta%20Book/FunctionalResourceModel_MagentaBook-W-10-Complete-210829.docx?d=w54c9805c8a32475484da90e26dba2bef

The second uploaded version is a Draft Red Book (R-0.1) that covers only those FR Sets and FRs for which approved (Tier-1) and candidate (Tier-2) FRs have been defined for the SANA FR Registry. Essentially, this is the current draft of the book that we will eventually propose for publication as Issue-1 of the FRM MB. . Besides deleting all of the future FR Sets and FRs, it is also "clean" - all of the markup changes have been accepted (although there are a few comments flagging items that need to be addressed before publication of the book). Finally, the Document Control section gets a fresh start - if anyone is interested in the changes that occurred in the Tech Note of the previous Complete drafts, please look in the Complete version for that history.

The Red-0.1 version can be found at:
https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Functional%20Resource%20Model%20Magenta%20Book/FunctionalResourceModel_MagentaBook-W-10-Complete-210829.docx?d=w54c9805c8a32475484da90e26dba2bef

I propose that the Red-0.1 version is sufficient to use as a guide/companion document for the subject-matter-expert review of the Tier-2 FRs.

Returning now to the topic of the (SLS-SDLP) WG's recent changes in the TM, AOS, and USLP (fixed length frame) specifications: this past spring, the SDLPWG decided to change the specification of the Only Ide Data (OID) Frames for TM, AOS, and (Fixed-length) USLP from a static content to one in which the transfer frame data field content (but not the frame header or frame trailer) contains pseudo-randomly-generated content, to ensure that the link stays synchronized even during long (for some definition of "long") periods when only OID Frames are on the link. I do not necessarily understand the total logic behind this decision - all that is necessary to say here is that this is now how OID Frames are defined.

In defining the FLF Synchronization, Channel Encoding & OID Generation FR, we had taken advantage of static content of OID Frames (and the static content of OID CADUs - CADUs that contain OID Frames) to pull the OID Frame and OID CADU generation into the functionality of the FLF Synchronization, Channel Encoding & OID Generation FR, even though the AOS and USLP Blue Books formally assign that functionality to the Master Channel Multiplexing functions of those respective SDLPs. Simply put, the content of the OID Data Unit (an OID Frame or and OID CADU, depending on the type of the data units being processed by the FR -see the FF-CSTS) could be set as a static configuration parameter of the FR. Importantly, the content of the OID Data Unit would be opaque to the FLF Synchronization, Channel Encoding & OID Generation FR - the FR would just inject the static content of the OID Data Unit into the data stream whenever a user-data-bearing frame or CADU was not available. Thus the FLF Synchronization, Channel Encoding & OID Generation FR could be "protocol agnostic" with respect to the SDLP.

However, the requirement to randomize the transfer frame data field content (but not the frame header or frame trailer) requires at least some knowledge of the frame structure i.e., what subset of the OID Data Unit need to be static and what part needs to be pseudo-randomized. In other words, the FLF Synchronization, Channel Encoding & OID Generation FR would have to become more SDLP-aware if pseudo-randomized OID Frame and OID CADU generation were to be performed by the FR.

I believe that the simplest solution is to:

a)      Return the responsibility for generation of OID Transfer Frames to the respective MC Mux FRs (AOS and USLP). This is where that functionality is formally allocated in the Blue Books, and it is already assumed, for example, that the AOS MC Mux FR "knows" where the transfer frame data field resides within the transfer frame.

b)     Limit the CADU configuration to use of legacy SDLPs that use a statically-defined "OID CADU". This is consistent with a primary motivation (in EF-CLTU) for the "CADU mode" - to provide a "lowest common denominator" door into the space link for continuous, contiguous, fixed-length-frame space data link protocols. Note that with this limitation the FF-CSTS "CADU configuration" is still valid, it just restricts the types of CADUs that can be transferred (i.e., restricts them to be CADUs of SDLPs for which  the OID CADUs can be static octet strings).

If anyone know of any valid use cases for which this new, simpler approach *won't* be sufficient, please identify them. But unless we have such use cases, I propose we move forward with this simpler approach.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20210830/fd1833f6/attachment.htm>