[Css-csts] Updated FF-CSTS Red Book on CWE

[John Pietras]

CSTSWG colleagues ---
I have uploaded the current draft of the FF-CSTS Red Book to the CWE at URL
https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/Forward%20Frame%20CSTS/FF-CSTS-922x3r2.2-191126.doc?Web=1

This version contains the changes resulting from the pseudo RIDs discussed and approved at the fall Workshop. For the most part, the changes involved clarification and addition of the new informative annex that discusses the relationship between the FF service to provision of DTN services by an ESLT (new annex K).  This new annex has already undergone one review cycle with Peter Shames and the current version has been sent to him for concurrence or further revision.

However, there were several changes that could affect the prototyping, depending on whether the prototyping implements the affected items:

1.       The pseudoRID JP-8 replaced the BFDP-specific transfer-mode configuration parameter with the data-transfer-mode inherited from the parent (SFW) Buffered Data Processing procedure. This change could affect the prototypes to the extent that any setting or querying of this parameter must now be done in term of the pBDPdataTransferMode OID and PBDPdataTransferModeType.


2.       PseudoRID ESA WH-1has also introduced technical changes in the specification that may or may not affect the prototyping effort, depending on whether the affected elements are actually being prototyped. Wolfgang's pseudoRID pointed out that the read-only parameters specified in tables 4-4 and 5-4 were specified only as service management parameters, that is, there were no corresponding procedure-level parameters. As a result of the RID, the read-only number-of-data-units-received, number-of-data-units-submitted-to-processing, and number-of-data-units-processed parameters in tables 4-4 and 5-4 have been respecified as read-only *procedure* parameters, and the current-input-queue-size parameters have been deleted. Instead of using the separate current-input-queue-size parameters, the current values of the input queue size are now specified to be reported using the respective input-queue-size configuration parameters of the procedures. These changes might affect the prototyping if the number-of-data-units-received, number-of-data-units-submitted-to-processing, number-of-data-units-processed, or current-input-queue-size read-only parameters are being prototyped.


3.       A third change to the ASN.1 has been made to the ASN.1 has been made to eliminate a possible source of confusion in the FF book. Both the Sequence-Controlled Frame Data Processing (SCFDP) and the Buffered Frame Data Processing (BFDP) procedures had derived-procedure configuration parameters gvcid-bit-mask, authorized-gvcid,  minimum-frame-length, and maximum-frame-length. For the SCFDP procedure, the corresponding parameter identifiers are pSCFDPgvcidBitMask, pSCFDPauthorizedGvcid, pSCFDPminFrameLen, and pSCFDPminFrameLen, respectively (table 4-3). For the BFDP procedure, the corresponding parameter identifiers are pBFDPgvcidBitMask, pBFDPauthorizedGvcid, pBFDPminFrameLen, and pBFDPminFrameLen, respectively (table 5-3). However, each of the four pairs had mapped to the same configuration parameter type, which is simply prefixed "PFDP". E.g., pSCFDPgvcidBitMask and pBFDPgvcidBitMask were both of type PFDPgvcidBitMaskType, etc. These 4 common types were created before we switched to the Embedded PDV approach that heavily relies on the parameter OID being used to identify the syntax of the type of that parameter.

In effect, tables 4-3 and 5-3 that there were two OIDs that could be used to identify the same syntax, which could be confusing for implementers.

Therefore, the following changes were made:

a.       The "PFDP"-prefixed types are now used as core types



b.       Procedure-specific types are cast of those "PFDP"-prefixed types. E.g.,
PSCFDPgvcidBitMaskType ::= PFDPgvcidBitMaskType
PBFDPgvcidBitMaskType  ::= PFDPgvcidBitMaskType



c.       Tthe procedure-specific types are used in tables 4-3 and 5-3 and in annex F. E.g., pSCFDPgvcidBitMask is of type PSCFDPgvcidBitMaskType. In annex F, the OID specification for the classifier pSCFDPgvcidBitMask are immediately followed by the type definition (PSCFDPgvcidBitMaskType ::= PFDPgvcidBitMaskType) to unambiguously specify the OID to identify both the parameter and the syntax.

Possible effects on the prototyping could result to the extent that the prototypes implement the setting and querying of the gvcid-bit-mask, authorized-gvcid,  minimum-frame-length, and maximum-frame-length procedure configuration parameters.

Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20191126/09485e1f/attachment.html>