C S T S
meeting date
19.12.2007
W G
M E E T I N G
ref./réf. CSTS-WG-191207
page/page
1
date de la réunion
7
Teleconference
meeting place
lieu de la réunion
minute’s date
dates de minute
subject/objet
19.12.2007
chairman Y.Doat (ESA)
présidant
participants F.Lassere (CNES, [email protected])
N.Pfeil (Terma, [email protected])
C.Thomas (CS, cyril.thomas@c-s)
J.Pietras (GST/NASA, [email protected]),
M.Goetzelman (Vega, [email protected])
M.Schabe (ESA, [email protected])
W.Hell (ESA, [email protected])
participants
CCSDS CSTS Working Group
copy/copie CCSDS CSTS Working Group
Members
Description/description
Y.Doat to prepare the Red Book describing the procedure for Object
Identifiers allocation.
(12.04.2005: contact SANA editors in CCSDS)
Yasunori Iwana to prepare the book describing the Radiometric service
based on the generic services and the guidelines for the definition of new
services.
19.12.2007: action superseded by A#11-1007.
T.Ray to prepare the book describing the Return Unframed Telemetry
service based on the generic services and the guidelines for the definition
of new services.
16.06.2006: Action moved from CNES to GODDARD
Behavior: BIND Invocation received while processing a first Bind
Invocation for the same association. This behavior is not possible
provided a clear statement in the Recommendation is present that all state
transitions are atomic.
Y.Doat to make sure that such a statement (See RAF, note 10 in 4.2.2:
atomic) is added to each state table in the book.
21.11.2007 Statement added in draft 0.11, section 5.3.1.2, note 10.
action/action Due date/date limite
A#8.1003 15.05.2004
Suspended
A#5-1104
Closed
A#6-1104
Depends on
A#07-0905
A#02-0107 Closed
265331602
C S T S
meeting date
19.12.2007
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-191207
page/page
2
7
Y.Doat to update the GET operation - The QualifiedParameter definition A#06-0107 Closed
shall be extended to cover time, real and sequence of values. The choice
of values shall be described in the GET operation.
19.12.2007: Closed
T.Ray proposed to compile the User States tables for all procedures and A#09-0107 Once
propose it as a Green Book that would not be binding for implementation.
Recommendation
T.Ray to draft the User State Tables Green Book
draft is under
01.10.2007: Draft delivered in January 2007.
review.
W.Hell to check the service agreement (J.Pietras) and service package
A#11-0107 Open
with Service Management for Service Instance Identifier definition.
04.10.2007 Check with Service Management that the definition of the
values for sagr and spack are properly covered in Service management.
W.Hell to distribute the complete list of updates required in the SLE
books
J.Pietras will update the definitions technical note
19.12.2007 – Action closed
M.Ricart to propose a ‘simple’ diagram for the data processing procedure
(Section 3.4.5).
19.12.2007 -Action will not be completed. Tim to comment
Y.Doat to check the status of the SLE API books (including the ISP)
13.11.2007: Information sent to Secretariat. Wait for Feed-back
J.Pietras to consider the possibility to have a monitoring service
implementing a subset of the functionality (See MoM Heppenheim
section 7.1)
Do we allow a compliant implementation to implement a subset of the
above functionality? E.g. “Cyclic delivery” would be the minimum
functionality to be supported). In case not supported, the provider would
send a negative response to a query.
19.12.2007 – Discussed see teleconference MoM from 19.12.2007
TCP Configuration not addressed. The configuration does not affect the
existing books and could be documented in the ISP (informative annex).
Agreement with Service Management is required (W.Hell)
Return services: Time accuracy down to pico-second (ASN.1 backward
compatible update). T.Ray, J.Pietras to state if change is acceptable from
NASA perspective.
19.12.2007 – NASA agree to update the books for supporting picoseconds
W.Hell to draft a text on PLOP handling (CLCW lock status) in CLTU
and FSP
FSP - W.Hell to clarify of the behavior to be adopted upon the occurrence
of a FOP alert
A#17-0107 28.02.2007
A#01-0707 Closed
A#04-1007 30.11.2007
A#05-1007 01.11.2007
A#06-1007 January 2008
A#07-1007 01.11.2007
A#08-1007 Closed
A #09-1007 01.12.2007
A#10-1007 01.11.2007
C S T S
meeting date
19.12.2007
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-191207
J.Pietras will draft a Radiometric Recommendation white book CSTS
based.
J.Pietras will draft the Notification procedure (reusing draft from 2006?).
19.12.2007 Draft on Web site
FSA will investigate possible contribution for the prototype
(A.Razorenov)
Make sure that there are no dependencies between the specification and
the ASN.1 transfer syntax (N.Pfeil)
19.12.2007 N o dependencies identified. Closed
All reviewed procedures to be updated (All)
19.12.2007: procedures updated
Procedures to be merged in Recommendation (Y.Doat)
page/page
3
7
A#11-1007 31.03.2008
A#12-1007 Closed
A#13-1007 31.01.2008
A#14-1007 Closed
A#15-1007 Closed
A#16-1007 15.01.2008
C S T S
meeting date
19.12.2007
date de la réunion
W G
ref./réf. CSTS-WG-191207
Agenda:
1. Review of actions;
2. Review of Query Procedure;
3. Review of Unbuffered Data Delivery
4. Review of Concept book
5. Review of draft Recommendation
6. Review of Buffered Data Delivery Procedure
M E E T I N G
page/page
4
7
C S T S
meeting date
19.12.2007
date de la réunion
1
2
3
4
5
W G
ref./réf. CSTS-WG-191207
M E E T I N G
page/page
5
7
1. T A B L E O F C O N T E N T S
Review of Actions ...................................................................................................................................... 6
Definitions .................................................................................................................................................. 6
Procedures................................................................................................................................................... 6
3.1
Common to all procedures .................................................................................................................. 6
3.2
Association ......................................................................................................................................... 6
3.3
Query Procedure ................................................................................................................................. 6
3.4
Cyclic Report ...................................................................................................................................... 7
3.5
Unbuffered Data Delivery Procedure ................................................................................................. 7
3.6
Buffered Data Delivery Procedure ..................................................................................................... 7
3.7
Notification procedure ........................................................................................................................ 7
Draft Recommendation ............................................................................................................................... 7
AOB ............................................................................................................................................................ 7
C S T S
meeting date
19.12.2007
date de la réunion
1
W G
ref./réf. CSTS-WG-191207
M E E T I N G
page/page
6
7
Review of Actions
A#06-1007 - See table at the beginning of the minutes.
J.Pietras to consider the possibility to have a monitoring service implementing a subset of the functionality
(See MoM Heppenheim section 7.1)
Do we allow a compliant implementation to implement a subset of the above functionality? E.g. “Cyclic
delivery” would be the minimum functionality to be supported). In case not supported, the provider would
send a negative response to a query.
NASA concern:
 Method for deriving a service shall allow backward interoperability.
 Different level of supports has to be interoperable.
E.g. Monitoring service with cyclic only and derived with query capability. A user would not bind to
the same service depending on the required functionality.
2
Definitions
Review of John Pietras technical note from 04.12.2007
 Cross support service data unit (CS-SDU): Not used in current draft recommendation. Candidate for
deletion.
 Cross Support is to be understood between ground elements or between ground elements and space
elements. Cross Support needs to be further qualified and should be covered by the Architecture WG.
 Connection oriented should be replaced by a “reliable mechanism” for data transfer.
 Complete and timely delivery mode shall be added.
 SLE Transfer Services and Cross-Support Services: relation to be clarified.
 Provision and production for cross-support transfer service need to be better defined in particular the
border line.
3
Procedures
3.1
Common to all procedures
The procedures extending operations do not need a “purpose” subsection explaining the background of the
extension. The “behavior” subsection should contain that information.
3.2
Association
Merged in Recommendation
3.3
Query Procedure
Can be merged with the Recommendation.
C S T S
meeting date
19.12.2007
date de la réunion
3.4
W G
ref./réf. CSTS-WG-191207
M E E T I N G
page/page
7
7
Cyclic Report
Section 3.1.2 shall stating that the semantic of the data exchanged must be defined by the service using this
procedure.
Section 3.1.2.3: ‘delivery cycle out of range’. The procedure shall define the constraints applicable to that
diagnostic (e.g. the permissible range is to be agreed by management).
3.1.2.3.2 Replace TRANSFER-DATA by START.
F.Lassere will update the procedure by 21.12.2007 for merging it into the Recommendation.
3.5
Unbuffered Data Delivery Procedure
Can be merged with the Recommendation.
3.6
Buffered Data Delivery Procedure
Merged in the Recommendation
3.7
Notification procedure
The START registers to the required notifications. Do we want the standard notification to be always sent by
default? In case a service uses two instances of the procedure it would get the standard notifications
duplicated. This behavior is not desired.
It is noted that some procedures includes by default the NOTIFY operation. In case a service is defined and
uses one of those procedure and the Notification procedure, the NOTIFY operation may be redundant for the
standard events.
Alternative:
 Allow a procedure to be extended with a NOTIFY operation;
 Keep the Notification procedure and allow turning off/on the standard notification.
 Another one??
4
Draft Recommendation
One book agreed.
5
AOB
Next teleconference: 06.02.2008 15:00 (Darmstadt time).