1 / 34

CSTS Specification Framework Changes since San Antonio

CSTS Specification Framework Changes since San Antonio. March / April 2013. General Changes. Layout and formatting of the tables revised and made consistent throughout the document

aaralyn
Download Presentation

CSTS Specification Framework Changes since San Antonio

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSTS Specification Framework Changes since San Antonio March / April 2013

  2. General Changes • Layout and formatting of the tables revised and made consistent throughout the document • The notion of dynamically modifiable procedure configuration parameters has been introduced. “The Configuration Parameters subsection specifies which, if any, of the configuration parameter values may be updated while the service executing the procedure is bound” (1.6.3.2.6).Section 2.3 specifies how Service Management deals with such parameters. For the few procedures having dynamically modifiable configuration parameters, the tables specifying these parameters in section 4 have been updated accordingly

  3. General Changes • The terminology regarding buffers used to block a number of invocations into a single PDU has been cleaned up. The new terms used are ‘forward buffer’ and ‘return buffer’, respectively. The ASN.1 has been revised accordingly and both buffer types are now dealt with as Framework PDUs • References to Service Management have been adapted to the next-generation suite of Service Management Recommendations.

  4. Changes in Section 1 • The definitions of the terms ‘Label List’ and ‘Label List Set’ have been added to section 1.6.1.4. Subsequently the definition of the term ‘Label List’ has been modified to also cover the case that such list contains Event Labels (1.6.1.4.28) • The definition of the term ‘refinement’ has been modified to accommodate the case where the behavior of a procedure is modified without the addition of new parameters (1.6.1.4.44)

  5. Changes in Section 1 • Meaning of the ‘null’ value and the associated ASN.1 NULL type is now better explained (see NOTE in 1.6.3.1.3)“Even though a parameter is characterized as always present, its description may specify that its value may be left unspecified. Given that in ASN.1 a parameter the value of which is not set to a specific value is mapped to the NULL type (see annex E), this for short in this document is expressed as this parameter having the value ‘null’.”

  6. Changes in Section 2 • Figure 2-1 now covers all procedures and operations and their relationship. Table 2-3 has been corrected accordingly

  7. Changes in Section 3 • Text has been added to 3.3.2.2 and 3.3.2.3 to emphasize that the credentials parameters are present only if the given PDU shall be authenticated at the receiving end • In the standard return header, the existence of the diagnostic parameter in case of result = ‘negative result’ was ‘hidden’. Table 3-1 has been modified and structure and text in 3.3.2.6 and 3.3.2.7 have been revised to make the parameter more visible to the reader

  8. Changes in Section 3 • The specification of the procedure-instance-identifier parameter has been rephrased to better explain in which cases the value of this parameter remains undefined, i.e. does not have an instance number (3.3.2.5.1) • 3.11.2.2.3.2 to 3.11.2.2.3.4 have been modified to provide a distinction of events associated with Functional Resources and events associated with procedures • The new paragraph 3.12.1.3 specifies precisely under which conditions a GET invocation is valid • 3.12.1.4 has been extended to specify more precisely the format in which the requested parameters are to be returned

  9. Changes in Section 3 • 3.12.2.2.2.1 has been extended to cover also the case that the list-of-parameters parameter of the GET invocation contains a procedure type or a procedure instance identifier • For various diagnostics 3.12.2.3.1 specifies exactly which diagnostic value is to be used in which error case; additional values have been added for error cases applicable when procedure parameters are queried

  10. Changes in Section 3 • The conditions under which the diagnostic ‘unknown parameter identifier’ is to be used in the GET return are defined in more detail now in 3.12.2.3.1 c); 4.10.4.1.3.1 c) and 4.11.4.1.3. c) for the START return of the Cyclic Report and Notification procedures have been modified accordingly ‘unknown parameter identifier’ — one or more Parameter Identifiers contained in the list-of-parameters parameter are unknown to the service provider (see 3.12.2.2.2)) for one of the following reasons: 1) the Functional Resource specified as part of the parameter name is not associated with the service instance executing the given Cyclic Report procedure instance; 2) the Functional Resource type specified as part of the parameter label is not associated with the service instance executing the given Cyclic Report procedure instance; 3) a parameter with the given Published Identifier does not exist for the specified Functional Resource instance or type.

  11. Changes in Section 3 • A new diagnostic value ‘unknown qualifier’ has been added to the negative acknowledgement of the EXECUTE-DIRECTIVE operation • The specification of the parameters directive-identifier and directive-qualifier of the EXECUTE-DIRECTIVE operation has been rewritten (3.13.2) and the associated ASN.1 updated accordingly. The directive-identifier must be an Object Identifier. This change resolves the former conflict with statements in annex D

  12. Changes in Section 4 • The tables specifying procedure configuration parameters have been updated and contain now for all accessible parameters the reference to the applicable ASN.1 type specification • A NOTE has been added in 4.4.3.2.7 that points out that backpressure may be the result of link congestion or a ‘slow’ user; in the state tables the term ‘congested’ has been replaced by ‘backpressure’ • In the state table of the Buffered Data Delivery procedure (table 4-17) row 9 dealing with the insertion of production status change events into the recording buffer has been removed. The NOTE in 4.5.3.4.3 clearly states that recording itself is outside the scope of the Buffered Data Delivery procedure

  13. Changes in Section 4 • Various changes in 4.8 (Sequence-Controlled Data Processing procedure) had to be made to reflect what is inherited from the parent Data Processing procedure in terms of notifications and what are further extension specific to the Sequence-Controlled Data Processing procedure • The specification of the ‘unknown Functional Resource Type’ and ‘unknown Functional Resource Name’ diagnostic in the Cyclic Report START and Notification START returns (4.10.4.1.3.1 and 4.11.4.1.3) has been aligned with the specification of that diagnostic value in the GET return“… or the Functional Resource Type / Name is not associated with the service instance that executes the Cyclic Report / Notification procedure”

  14. Changes in Section 4 • A NOTE has been added to explain why e.g. in table 4-51 the parameter ‘default list of parameters’ is stated to be not accessible. Such note has been added to 4.9.5.1, 4.10.5.1 and 4.11.5.1.“The default list of parameters is shown in table 4‑51 as not accessible. This is because one cannot query directly the name of the default list. However, one can retrieve the full set of list names and for each list it is stated whether this list is specified to be the default list.”

  15. Changes in annex C (Object Identifier Definitions) • This annex has been updated in accordance with the revised OID tree; all figures have been redrawn

  16. Changes in annex D (Parameter, Event, and Directive Names) • This annex has been updated in accordance with the revised OID tree • Material covering parameters and events associated with procedures has been added • The SANA registry policy has been revised. Annex L provides examples of what the SANA registry will have to contain.

  17. Changes in Annex E (ASN.1) • All changes discussed at the San Antonio meeting have been incorporated. The (few) syntax errors and typos caused by these comprehensive changes have been corrected • Few CHOICE tags have been changed to be in sequence and without gaps • Various type names have been modified and are now built in a consistent manner • Extensions had been named the same way in numerous data structures (extensionParameter). Now specific names have been introduced as to allow an unambiguous reference in the ICS proforma (annex G) to specific parameters, e.g. startInvocationExtension

  18. Changes in Annex E (ASN.1) • The definition of the DataUnitId has been moved to section E3.3 from which it is exported and imported now by all modules using this type. • For the value ranges defined for the PeerAbortDiagnostic the case that procedures could invoke a PEER-ABORT has been removed as such abort would be always via the Association Control procedure • In the ASN.1 modules defining the PDUs of the procedures Buffered Data Processing and Sequence-Controlled Data Processing now the inheritance from the parent Data Processing procedure has been taken into account and the extension of the NOTIFY invocation has been revised accordingly

  19. Changes in Annex E (ASN.1) • Naming of parameters in the extensions of the Process-Data positive and negative returns in the Sequence-Controlled Data Processing procedure has been made consistent • The events reporting configuration changes have been renamed to provide a clear distinction of changes affecting service production and changes affecting procedures. The revised names are svcProductionConfigurationChange and e.g. pBDDconfigurationChange • The OIDs of the events svcProductionOperational, svcProductionInterrupted and svcProductionHalted specified in section E3.17 have been updated to match the OID tree

  20. Changes in Annex E (ASN.1) • Various names have been modified to better reflect the actual contents of the ASN.1 modules: • Section E.16 is now called “CSTS Framework Procedure Parameters, Events and Directives” and the module name has been changed to “CCSDS-CSTS-FW-PROCEDURE-PARAMETERS-EVENTS-DIRECTIVES”. The last element of the module OID is now called “procedureParamEventDirective”. The OID tree and annex K have been modified accordingly • The module in section E.17 is now called “CCSDS-CSTS-GENERIC-SERVICE-OBJECT-IDENTIFIERS”. The last element of the module OID is now called “service-generic-identifiers”. The OID tree and annex K have been modified accordingly

  21. Changes in Annex G (ICS Proforma) • This annex has been developed from scratch with many valuable contributions from John • Since in part the Framework PDUs use fairly complex data types, one has to decide on a case by case basis which (primitive) parameters should be ‘hidden’ in complex types and which parameters should be exposed in the annex G tables; whenever the presence or absence of a parameter is conditional, this parameter shall be exposed • Annex G shall be presented to the CESG as (first?) example of an ICS proforma created as per CESG requirements

  22. Changes in Annex G (ICS Proforma) • The initial draft of annex G had incorrectly assumed that the implementation of a derived procedure would also require the implementation of the parent procedure. This false assumption has been corrected (table G-5) • All numeral labels are now continuous throughout this annex • The terms identifying the peer entities in table G-6 are no longer those of the CESG example, but use now Framework terminology (Service Provider System, Service User System)

  23. Changes in Annex G (ICS Proforma) • Although services developed on the basis of the Framework may communicate via one or more relays, the relay column has been removed from table G-6 since the specification of such relays or gateways is outside the scope of the Framework (cf. 3.4.2.2.4) • In the initial draft all invocation PDUs showed a headerExtension parameter. This was due to an incorrect interpretation of the ASN.1 and has been corrected by removing this parameter • Value constraints of parameters are explained to some detail below the various tables (AVxx) and therefore provide more guidance than only a specific value in the table

  24. Changes in Annex G (ICS Proforma) • As to fully understand the in part quite complex types of PDU parameters, it is generally necessary to refer to more than one ASN.1 module. Where appropriate, text below the table provides some guidance where the relevant information can be found

  25. Changes in Annex J (Acronyms) • The complete Framework document has been scanned and the missing acronyms have been added to this annex.

  26. Changes in Annex K (Object Identifiers) • The OID tree has been redrawn in accordance with the changes agreed at the San Antonio meeting. The figures in annex K have been replaced with figures extracted from the revised OID tree spread sheet • The term ‘radiometric data’ has been replaced by ‘tracking data’ • A few discrepancies between the ASN.1, the Framework document body and the OID tree have been fixed (e.g. productionConfigured is now svcProductionConfigured) • For the Sequence-Controlled Data Processing procedure, the missing OID for the ‘locked’ substate has been added

  27. Changes in Annex L (Published Identifiers) • This new annex illustrates by means of some examples the information that will be maintained in a SANA registry for Published Identifiers

  28. Candidate Issues for RIDs • The referenced Service Management documents won’t be published for quite some time. Is it nonetheless permissible to treat them as normative references? Did we have similar cases in the past that can be used as precedence?

  29. Candidate Issues for RIDs • The parameter responderIdentifier is ‘hidden’ in both the positive and negative extensions of the BIND return. A parameter being unconditionally present should be specified as part of the base PDU parameters rather than extensions • If that change is accepted, further simplifications are possible because the AssocBindNegReturnExt can disappear and only the standard negative return extension parameter is needed • For now, this change has not been implemented to avoid the risk of invalidating the prototyping results

  30. Candidate Issues for RIDs • In ListOfParametersEventsfunctionalResourceName is correctly cast as type FunctionalResourceName, but paramEventNames is cast as type (SEQUENCE OF) Name. ListOfParametersEvents::= CHOICE { defaultList [0] NULL , paramEventNames [1] SEQUENCE OF Name , paramEventLabels [2] SEQUENCE OF Label , listName [3] VisibleString , functionalResourceName [4] FunctionalResourceName , functionalResourceType [5] FunctionalResourceType , procedureType [6] ProcedureType , procedureInstanceId [7] ProcedureInstanceId }

  31. Candidate Issues for RIDs • The Name type permits the selection of frameworkResourceName which is cast as type ProcedureInstanceId which for paramEventNames is not permissible. Name ::= SEQUENCE { functionalResourceName CHOICE { crossSupportResourceName [0] FunctionalResourceName , frameworkResourceName [1] ProcedureInstanceId } , paramOrEventIdPublishedIdentifier } • This can be easily corrected by just changing a few lines in the ASN.1, but has not been done so far as not to invalidate the prototyping results.

  32. Candidate Issues for RIDs • The ListOfParamEventsDiagnostics type has a similar problem in the sense that in part the types are unnecessarily ‘loose’. ListOfParamEventsDiagnostics ::= CHOICE { unknownFunctionalResourceName [1] FRorProcedureName , unknownFunctionalResourceType [2] functionalResourceType , unknownParamEventIdentifier [3] SEQUENCE OF CHOICE { paramEventName [1] Name , paramEventLabel[2] Label } , unknownListName [4] VisibleString , undefinedDefault [5] AdditionalText , unknownProcedureType [6] ProcedureType , unknownProcedureInstanceId [7] FRorProcedureName , outOfRange [8] AdditionalText }

  33. Candidate Issues for RIDs • The FRorProcedureNametype enables unknownFunctionalResourceName to be of the type ProcedureInstanceId and procedureInstanceId to be of the type FunctionalResourceName. FRorProcedureName ::= CHOICE { functionalResourceName [0] FunctionalResourceName , procedureInstanceId[1] ProcedureInstanceId } • Again,this can be easily corrected, but has not been done so far as not to invalidate the prototyping results due to changes of the ASN.1.

  34. Candidate Issues for RIDs • Although extensions of the BIND / UNBIND PDUs are discouraged (cf. 4.3.3.1.11), they are permitted in the Framework (except that 3.5.2.2 excludes extensions of the UNBIND invocation) and it is left to the service specifications to state if these extension are used or not. Wouldn’t it be better in the interest of interoperability not to allow these extensions in the first place?

More Related