Update on CSTS Red Book Issue 1 at CSTSWG Workshop in Darmstadt
Final resolutions for 9 RIDs have been accepted and included in the book, with ongoing issues related to ESA RID FF-5 and the CCSDS SLS Coding and Synchronization WG. Additional changes since the Spring meeting include normative specifications, data transfer mode procedures, and resource sharing in service provision. Further updates are proposed for GVCID bit masks in operational scenarios and normative requirements.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Forward Frame CSTS Red Book Issue 1 Updated Status (Workshop Outcomes) CSTSWG Workshop Darmstadt, Germany 21-24 October 2019 John Pietras Global Science and Technology, Inc.
Summary 9 RIDs were originally submitted all RIDs were accepted and the resulting resolutions have been incorporated into the book Final resolution of ESA RID FF-5 depends on progress (or lack thereof) of the CCSDS SLS Coding and Synchronization (C&S) WG in defining the codes to be used for fixed-length frames on forward links As of 23 September 2019, the C&S WG has not progressed the specification of sync and coding of fixed length frames (FLF) on the forward link The description of FLF coding has been adjusted to represent to current status Seven pseudo-RIDs (WG-internally-generated RIDs resulting from further discovery after review period) as of the end of the Spring 2019 meeting, and the agreed resolutions have been incorporated into the book These original RIDs and their resolutions were documented in the FF-CSTS publication package of 10 July 2019 Since the Spring meeting, three additional changes have surfaced Normative specification of the GVCID bit masks Use SFW BDP data-transfer-mode procedure configuration parameter and type Procedure read-only parameters for data units and current input queue size Sharing of production resources by FF service provision and DTN services (raised at the Workshop) Prototyping questions/lessons regarding Qualified Parameters 2 www.ccsds.org
Normative Specification of the GVCID Bit Masks (1 of 2) ESA RID FF-4 identified an error in paragraph 2.5.5.2. c), which erroneously specified a 5-octet GVCID bit mask instead of the required 4-octet bit mask The affected lines were corrected in the FF-CSTS candidate Blue Book in the publication package The bit masks for TC and AOS frames are currently stated only in the informative operational scenarios of section 2.5, and no bit mask information is provided for USLP TC, AOS, and USLP are now normative for FF-CSTS: their bit masks should also be normative Proposed Change: add the specification of the 3 bits masks to the normative requirements for bit masking for the SCFDP and BFDP procedures Add the following sub-bullets under 4.5.3.1 (which currently reads: If the result of the ANDing of the first 4 octets of the data parameter of the PROCESS-DATA invocation with the gvcid- bit-mask configuration parameter does not match the authorized-gvcid configuration parameter, the PROCESS-DATA invocation shall be invalid, and the service provider shall issue a PROCESS-DATA negative return with the diagnostic invalid GVCID ) a) For Telecommand frames, the value of the gvcid-bit-mask configuration parameter shall be 11000011 11111111 11111100 00000000 (C3 FF FC 00 Hex). b) For Telecommand frames, the bits of the authorized-gvcid configuration parameter that correspond to the TFVN, SCID, and VCID fields of the Telecommand Transfer Frame Primary Header shall be set to the GCVID of the permitted virtual channel. c) For AOS frames, the value of the gvcid-bit-mask parameter shall be 11111111 11111111 00000000 00000000 (FF FF 00 00 Hex). d) For AOS frames, the bits of the authorized-gvcid configuration parameter that correspond to the TFVN, SCID, and VCID fields of the AOS Transfer Frame Primary Header shall be set to the GCVID of the permitted virtual channel. 3 www.ccsds.org
Normative Specification of the GVCID Bit Masks (2 of 2) Proposed Change (concluded) Add the following sub-bullets under 4.5.3.1 (concluded) e) For USLP frames, the value of the gvcid-bit-mask parameter shall be 11111111 11111111 11111111 11100000 (FF FF FF E0 Hex). f) For USLP frames, the bits of the authorized-gvcid configuration parameter that correspond to the TFVN, SCID, Source or Destination ID, and VCID fields of the USLP Transfer Frame Primary Header shall be set to the GCVID of the permitted virtual channel. NOTE Frames transferred by the Forward Frame service contain the SCID of the destination space node. Therefore the Source or Destination ID bit of the authorized-gvcid configuration parameter that corresponds to the Source or Destination ID bit of the USLP Transfer Frame Primary Header (the 21st bit) shall be set to 1 when the Forward Frame service is provided by an ESLT. Add the same 6 sub-bullets under 5.5.3.1 which currently reads If the result of the ANDing of the first 4 octets of the data parameter of the PROCESS-DATA invocation with the gvcid- bit-mask configuration parameter does not match the authorized-gvcid configuration parameter, the service provider shall invalidate the PROCESS-DATA invocation and invoke the NOTIFY operation with event-name set to invalid GVCID and event-value set to the value of the data-unit-id parameter of the invalid PROCESS-DATA invocation. Treat this as an update to the disposition of ESA RID FF-4. This update was approved by the WG 4 www.ccsds.org
Use SFW BDP data-transfer-mode Procedure Configuration Parameter and Type The FF-CSTS BFDP procedure defines its own transfer-mode procedure configuration parameter and type (pBFDPtransferMode, PBFDPtransferModeType) This parameter and type are redundant with the SFW BDP procedure data-transfer- mode parameter (pBDPdataTransferMode, PBDPdataTransferModeType) except the SFW type (which is cast as DataTransferMode) currently has an undefined value (as does the DeliveryMode type) Wolfgang concurs that the undefined values are unnecessary and should be removed from the SFW types Q: DataTransferMode and DeliveryMode are currently constructed as named INTEGER types shouldn t they be ENUMERATED? (Update they are already ENUMERATED in the latest version of the SFW) Proposal for FF-CSTS Use the existing SFW BDP data-transfer-mode type and parameter, delete BFDP-specific parameter and type from table 5-1 and annex F, and add cross-reference to annex M This issue was identified as a result of researching the answer to a prototyping question regarding the contents of qualified parameters Treat this as an additional pseudo-RID, JP-8. This resolution was approved by the WG 5 www.ccsds.org
Specification of Procedure Read-Only Parameters for Data Units and Current Input Queue Size (1 of 2) Both the SCFDP and BFDP procedures add the following read-only parameters: number-of-data-units-received number-of-data-units-to-processing number-of-data-units-processed (i.e., radiated) current-input-queue-size (reports the dynamically changeable current value, as opposed to the starting value reported by the input-queue-size configuration parameter) These parameters are currently designated as service management configuration parameters only They can be accessed via MD-CSTS But the user of the FF service can access them (via the service s CR and IQ procedures) only in terms of the FF-CSTS Provider functional resource i.e., The user has to know the FR Name, which includes the FRIN Wolfgang has (correctly) questioned why these are not procedure configuration parameters, which would allow the user to access them locally i.e., not be required to know the FR Name Treat this as a new pseudo-RID, ESA WH-1 6 www.ccsds.org
Specification of Procedure Read-Only Parameters for Data Units and Current Input Queue Size (2 of 2) Proposed RID Resolution First, WG should consider whether corresponding read-only parameters should be added to the SFW DP procedure In this case, FF s SCFDP and BFDP procedures would just inherit them, and specify the FF- specific service management parameters that correspond to them If the WG declines to add them to the SFW, add them as procedure R-O parameters to SCFDP and BFDP: Change the corresponding configuration parameter IDs and types in table 4-4 to pSCFDPinputQueueSize/PSCFDPinputQueueSizeType pSCFDPnumberDataUnitsRcvd/PSCFDPnumberDatasUnitRcvdType pSCFDPnumberDataUnitsToProcessing/PSCFDPnumberDataUnitsToProcessing pSCFDPnumberDataUnitsRadiated/PSCFDPnumberDataUnitsRadiated Add requirements in 4.8 to specify the corresponding SM parameter classifiers (the same approach as used for procedure configuration parameters) Change the corresponding configuration parameter IDs and types in table 5-4 to pBFDPinputQueueSize/PBFDPinputQueueSizeType pBFDPnumberDataUnitsRcvd/PBFDPnumberDatasUnitRcvdType pBFDPnumberDataUnitsToProcessing/PBFDPnumberDataUnitsToProcessing pBFDPnumberDataUnitsRadiated/PBFDPnumberDataUnitsRadiated Add requirements in 5.8 to specify the corresponding SM parameter classifiers Move the corresponding parameter IDs and type definitions from annex B (Service Object Identifiers) to annex F (Forward Frame Service Procedure Parameters, Events, and Directives) The WG decided to change them on the FF book only, at least for now o o o o o o o o 7 www.ccsds.org
Sharing of Production Resources by FF Service Provision and DTN Services (1 of 3) At the Workshop, the CSTSWG met with Peter Shames to clarify the relationship of DTN to Forward Frame service We clarified that DTN and FF service instances share space links by multiplexing frames transferred through FF with DTN Bundle- containing frames generated within the ESLT Peter requested that this relationship be described in the FF Blue Book It will be added as an informative annex Pseudo RID PS-1 8 www.ccsds.org
Sharing of Production Resources by FF Service Provision and DTN Services (2 of 3) FR representation 9 www.ccsds.org
Sharing of Production Resources by FF Service Provision and DTN Services (3 of 3) Diagram to be used in the new annex 10 www.ccsds.org
Prototyping Questions/Lessons Regarding Qualified Parameters (1 of 2) FF-CSTS prototypers have been uncertain about how to construct qualified parameters In particular, uncertainty about what parameter-identifying OIDs to use in The parameterName parameter, and The syntax parameter of the EMBEDDED PDV The data-transfer-mode parameter was selected as the example to flesh out For me, the issue was what form of qualified parameter are we talking about? A procedure parameter, which uses the procedureName choice of the FRorProcedureName element of the parameterName, uses the procedure parameter ID OID (as specified in the service specification) for both the paramOrEventorDirectiveId element of the parameterName parameter and the syntax parameter of the EMBEDDED PDV, and uses the data type corresponding to the procedure parameter ID OID (as specified in the service specification) for the EMBEDDED PDV, or A service management parameter, which uses the functionalResourceName choice of the FRorProcedureName element of the parameterName, uses the functional resource parameter ID OID (as specified in the SANA FR Registry) for both the paramOrEventorDirectiveId element of the parameterName parameter and the syntax parameter of the EMBEDDED PDV, and uses the data type corresponding to the functional resource parameter OID (as specified in the SANA FR Registry) for the EMBEDDED PDV? 11 www.ccsds.org
Prototyping Questions/Lessons Regarding Qualified Parameters (2 of 2) I concluded that it was more important to implement the procedure parameter form(s) of the parameters, since that is the form that is used by the CR and IQ procedures of the CSTS itself Also, implementing the service management parameter form requires the use of OIDs and type definitions that will be but have not yet been formally specified in SANA Is this conclusion correct? If so, should that be more explicit guidance for CSTS prototyping efforts? The experience of the prototypers indicates that our documentation (SFW, Guidelines, and CSTS specifications) may be insufficient to unambiguously implement qualified parameters Is the needed material all there somewhere in the documentation, or is there missing information? What, if anything, can/should we do to remove this ambiguity? John P. will draft an informative annex for the SFW that illustrates the Qualified Parameter encoding of data-transfer-mode parameter as (a) a procedure configuration parameter and (b) a service management configuration parameter Follow-on question do the service management forms of qualified parameters need to be prototyped as part of a CSTS s approval process? The implementation of external access to FR parameters is not specified, so it s not clear what entity is (or entities are) responsible for forming qualified parameters of the service management parameter form No resolution was reached 12 www.ccsds.org
