[Css-csts] DPP Prototypes

[Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]]

Wolfgang,
Thank you for setting me straight on the protocol violations. I was focused on the text rather than the state tables at the time and it should have been obvious. I will make adjustments as indicated on all of the points.
Best regards,
David

David Zoller
COLSA Corporation
MSFC/HOSC - C107
*Office: (256) 544-1820
*EMail: david.a.zoller at nasa.gov<mailto:david.a.zoller at nasa.gov>

From: Wolfgang Hell [mailto:Wolfgang_._Hell at t-online.de]
Sent: Thursday, February 06, 2014 9:23 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: Margherita.di.Giulio at esa.int; Yves.Doat at esa.int; CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: Re: [Css-csts] DPP Prototypes

David,

Thank you for the flowers ... and thank you for drawing my attention to those parts of the Framework document that required some further tweaking. You will see them all corrected in the next version that I'm going to release.

As regards the Framework Protocol and ASN.1 items, the reason for no specific diagnostic in case a user sends a START invocation to an already active procedure is that this is a violation of the protocol. In such case the provider shall invoke the PEER-ABORT with the diagnostic set to 'protocol error'. This is clearly specified in the state tables. Likewise, if a not active procedure receives a STOP invocation, the service provider shall invoke the PEER-ABORT with the diagnostic set to 'protocol error'. Again, this is spelled out in the state tables.

The extension of the BuffDataProcProcDataInvocExt is actually an error. The extension needed to deal with the completion report is already part of the extension in the Data Processing procedure from which the Buffered Data Processing procedure is derived. Therefore it inherits this extension from the base procedure and therefore I have removed this extension from the Buffered Data Processing procedure. However, to answer your question, I would think that the absence (set to 'notUsed) of a specified extension is treated as an invalid PDU.

The structure PBDPdataTransferModeType is indeed a leftover from a much earlier version. I have removed it.

As regards the NOTIFY invocation as outlined in your message, at least at first glance it looks correct to me. Yves is currently working on further use case scenarios and after completion of that work he will be in the position to give you a definitive answer.

Best regards,
Wolfgang

Am 05.02.2014 23:08, schrieb Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]:
Dear CSTS WG members,
First, Wolfgang, excellent work on the January draft of the Specification Framework. Your command of the English language is better than the vast majority of us native speakers. Being from Alabama, I probably speak "Southern" rather than English :). Please find below just a few cosmetic tweaks in case you did not catch them while you are polishing the final version.

Second, after listening to the discussions during last week's teleconference, I decided to take a step back on the Data Processing Procedure prototypes and try instead to specify and implement a prototype service that incorporates the DP procedures. I have uploaded a draft specification for the Buffered Data Processing (BDP) Prototype Service which details the encompassed procedures and operations and goes into detail for the current available ASN.1 message usage. Initially, I am making use of the framework components as specified but may experiment with extending some of them in the future. Please review the draft to make sure that I am not straying too far from the proper framework usage.

The draft prototype service document is BDP Prototype Service Specification [Draft 20140205].docx and is located in a new directory:

Cross Support Services Area (CSS) > Documents > CSS-CSTS > CWE Private > Working Materials > DPP Prototypes


This link might take you to the correct location after you are logged in:
http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS%2FCWE%20Private%2FWorking%20Materials%2FDPP%20Prototypes&FolderCTID=0x012000A2CFA608DF169C4EB988261660CEFAEB&View={8045374D-F8E0-4356-83CA-993252A38FE8}<http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS%2FCWE%20Private%2FWorking%20Materials%2FDPP%20Prototypes&FolderCTID=0x012000A2CFA608DF169C4EB988261660CEFAEB&View=%7b8045374D-F8E0-4356-83CA-993252A38FE8%7d>

In the process of reviewing the latest updates and developing a prototype service specification, I generated another set of points for clarification on the ASN.1 usage and framework protocol. Please find those below as well.

Best regards,
DZ

David Zoller
COLSA Corporation
MSFC/HOSC - C107
*Office: (256) 544-1820
*EMail: david.a.zoller at nasa.gov<mailto:david.a.zoller at nasa.gov>


Review of 921x1r2[Draft_20140127].docx:

·         Page 1-6

o   There are extra spaces in the item:  "l)    space link"

·         Page 1-10

o   1.7.1.4.41 refinement

§  "refinement" should be bolded

·         Page 3-9

o   3.3.2.7.3 is an artifact that can be deleted

·         Page 3-11

o   3.4.2.2.1.3 The type AssocBindNegReturnExt, as defined inE3.5, shall define the syntax of the extended header carrying the responder-identifier required by the negative BIND return.

§  A space needs to be inserted: "in E3.5"

·         Page 4-1

o   4.2.2 ASSOCIATION AND PRIME PROCEDURE HANDLING

§  This heading is no longer applicable to the contents of the section

·         Possibly?  TERMINATION EVENT PROPAGATION


Framework Protocol and ASN.1 Items:

·         If a START invocation is received for a procedure that is already active there is not a predefined diagnostic

o   I plan to return otherReason set to "already active"


·         If a STOP invocation is received for a procedure that is not active there is not a predefined diagnostic

o   I plan to return otherReason set to "not active"


·         BuffDataProcProcDataInvocExt extends the PROCESS-DATA Invocation to specify whether or not to produce  a completion report

o   Is it permissible to set the ProcessDataInvocation.extensionParameter to "notUsed" to default to not produce a completion report? Or would that be a protocol breach requiring a negative return?



·         Page E-49  under E3.16 CSTS FRAMEWORK OBJECT INDENTIFIERS, the structure PBDPdataTransferModeType is defined to specify the configurable parameters of the Buffered Data Processing Procedure

o   My current plan is to return the configurable parameters as individual qualified parameters because this structure does not fit into the GetReturn mold

§  What is the intended usage of this structure? An extension to GetReturn as in BuffDataProcGetReturnExt?

§  Delete this structure?

§  What is the correct location for this structure if it is kept?

o   A nitpick while on page E-49:

§  pBDPInputQueueSize should be pBDPinputQueueSize with a lower case "i" to conform to the convention of the other related OID names



·         From my draft prototype service specification, is it correct to use the procBufferedDataProcessing OID in both locations below?

o   NOTIFY Invocation  (provider to user)

Field

Value

NotifyInvocation
    .standardInvocationHeader
         .invokerCredentials

unused

NotifyInvocation
.standardInvocationHeader
.invokeId

<provider specified>

NotifyInvocation
.standardInvocationHeader
.procedureInstanceId
.procedureType

OID: procBufferedDataProcessing


NotifyInvocation
.standardInvocationHeader
.procedureInstanceId
.procedureRole

primeProcedure

NotifyInvocation
.eventTime

<time in CCSDS Millisecond format>

NotifyInvocation
.eventName
.functionalResourceName

frameworkResourceName

NotifyInvocation
.eventName
.functionalResourceName
.frameworkResourceName
.procedureType

OID: procBufferedDataProcessing

Same as above?

NotifyInvocation
.eventName
.functionalResourceName
.frameworkResourceName
.procedureRole

primeProcedure

NotifyInvocation
.notificationType
.eventName
.paramOrEventId

One of the following OIDs:
dataProcessingCompleted
svcProductionHalted
svcProductionInterrupted
svcProductionOperational

NotifyInvocation
.notificationType
.eventValue

empty


NotifyInvocation
.notificationType
.notificationTypeExtension

notUsed


NotifyInvocation
.extensionParameter

external

NotifyInvocation
.extensionParameter
.external
.identification

syntax

NotifyInvocation
.extensionParameter
.external
.identification
.syntax

OID: bdpNotifyInvocExt

NotifyInvocation
.extensionParameter
.external
.data_value

ASN.1 encoding of a  BuffDataProcNotifyInvocExt structure
BuffDataProcNotifyInvocExt specifies values for:
dataUnitIdLastProcessed dataUnitIdLastOk
productionStatus







_______________________________________________

Css-csts mailing list

Css-csts at mailman.ccsds.org<mailto:Css-csts at mailman.ccsds.org>

http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20140206/8faa6109/attachment-0001.htm