[Css-csts] Parameter Names and Published Identifiers

[John Pietras]

Yves,

I started to make detailed comments on your proposed changes, but then I
had a few questions that will affect what I had to write, and so I think
I need answers before proceeding with the detailed comments. My
questions/concerns were sparked by the realization that under the new
"naming" convention as outlined in your rewrite, the parameter list
names are also pairs of (functional resource identifier: parameter
identifier). This implies that a parameter list is constrained to a
single functional resource. I was under the impression that lists could
have arbitrary content.

 

I noticed in the ASN.1 that the Functional Resource Identifier is
optional, although I didn't see this mentioned in any part of the main
text. This might be one way around the issue: if parameter list names
had no Functional Resource (FR) ID component, they wouldn't be
restricted to a single FR. Is this what you had in mind? In any case, I
think that the notion that the FR ID can be optional should be
introduced in the main text.

 

Thinking about this issue made me wonder if we need to declare the
(optional) first part to always be an FR ID. I think the question came
up in Boulder, too. One possible option would be to leave it in the CSTS
SF as a more-generic "domain qualifier" (still a
PublishedIdentifier/OID).  For those service for which Functional
Resources as the qualifier are appropriate, the domain qualifier would
be refined as a Functional Resource Identifier in those service
specifications. Keeping this abstract in the CSTS SF gives us some
robustness in case we want to use one of these procedures for something
that does not readily map into functional resources (e.g., a file
system?).

 

I'll have some more detailed comments once I can frame them in terms of
your response to my question above.

 

One quick comment that I'll make now: The 'unknown names' extension
diagnostic for the GET return is supposed to include "the list of
unknown parameter names". However, when traced through in the ASN.1, it
leads to  the type UnknownNames, which is currently specified as type
VisibleString. I think that this should be changed to match the new
"pair of PublishedIdentifier" definition.

 

While you think about those questions, here are some definitions from
the draft Monitored Data CSTS specification regarding functional
resources:

 

1.       Functional resource type - a logical function or related set of
functions that characterizes a unique instance of space communication
capability. A functional resource type can have at most one of each
monitored parameter type, each event notification type, and each
configuration parameter type.

2.       Functional resource instance - An instance of a functional
resource type.

3.       Functional resource identifier - the unique identifier of an
instance of a functional resource.

 

Using the Space Communication Cross Support Service Management (SCCS-SM
) terminology, examples of these three things are:

a)      A return space link carrier is an example of a functional
resource type. In MD-CSTS, a monitored parameter type is associated with
a functional resource type. E.g., a carrier-lock status parameter is
associated with the return space link carrier functional resource type.

b)      A return S-band space link carrier that is received by the
ground station is an example of a functional resource instance. Note
that SCCS-SM allows a single service package to have carriers via
multiple ground station (or relay satellite) antennas executing
concurrently; that is, a single service package may have multiple
instances of S-band space link carrier executing. So in fact the
different instances might have to be qualified by, for example, the
antenna through with that carrier is received. The allows separate
carrier-lock statuses to be reported for each of the carriers in the
service package.

c)       The identifier for one such return S-band space link carrier is
the OID that is assigned to that instance. Because multiple (in this
case, S-band) return space link carriers can be executing concurrently,
the set of functional resource identifiers must be capable of
distinguishing among these possible instances. For example, the NASA
Space Network is being upgraded to allow multiple return S-Band antennas
on multiple Tracking and Data Relay Satellites (TDRSs) to have their
signals combined, although the "carrier" associated with each of those
antennas will have its own set of monitored data (e.g., there will be
multiple carrier-lock statuses to report). In such a case, the return
S-band carrier functional resource identifiers will have to be
distinguishable by TDRS and the specific antenna on that TDRS (each TDRS
has 3 antennas that can receive at S-band).

 

I freely admit that the definition of functional resource type as "a
logical function or related set of functions that characterizes a unique
instance of space communication capability" is not very concrete, but it
has to generalize to a number of different types of entities, such as
space link carriers (when multiple such carriers can be active
concurrently [e.g., in S and X bands]),  subcarriers (when multiple
subcarriers can exist for a single carrier), and SLE transfer service
instances (of which there might be multiple of the same type [e.g., RAF]
operating concurrently. The key point is that it is a type for which
multiple instances can be operating concurrently in the Service Package,
such that a monitored parameter, control parameter, or event
notification associated with that type must be qualified by an instance
identifier to distinguish it from the other instances of the same
parameter type. E.g., the lock status of the return X-band carrier must
be distinguishable from the lock status of the return S-band carrier if
both happen to be operating concurrently. I welcome any suggestions for
a better, more compact, less abstract definition of functional resource
type.

 

If we hard-code the parameter names to include functional resource
identifiers in the CSTS SF, then these definitions (or better ones)
should be moved into the CSTS SF. However, if we decide to use a
more-abstract "domain qualifier" (or some better name) notion in the
Framework, then these definitions can stay in the MD-CSTS.

 

Best regards,

John

 

From: css-csts-bounces at mailman.ccsds.org
[mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of
Yves.Doat at esa.int
Sent: Monday, November 07, 2011 2:45 AM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Parameter Names and Published Identifiers

 

Dear all, 

Following our discussions last week, I updated the Framework to cope
with the requirements of the Monitored Data Service. I modified the book
to define the parameter name as a concatenation of a Functional Resource
Identifier and a Parameter Identifier. 

Please find an extract of the book covering: 

*	GET operation (pages 1 to 3) making use of parameter name 
*	Information Query Procedure (pages 4 to 7) making use of
parameter name 
*	Cyclic Report Procedure (pages 8 to 15) making use of parameter
name 
*	Annex B (pages 16 to 17) with a new requirement (B2.2) defining
a parameter name 
*	Annex D.3.3 (pages 18 to 22) with the new ASN.1 type:
ParameterOrListIdentifier being a concatenation of a Functional Resource
Identifier and a Parameter Identifier (used for the parameter name)


I extracted those parts as it may be easier to review that topic
separated from the entire book. In case you would prefer to review the
entire book, I would make available an intermediate version on the CWE
web site. 

To John and Fred: 
We have introduced the notion of Functional Resource and I was looking
for a definition without success. Could you please let me know where can
I find one? Alternatively, could you please propose one? 

Considering the short planning discussed in Boulder, I would appreciate
to get rapid feed back. If you would prefer we coud organise a short
teleconference to review that topic. 

Best regards 
Yves 

 
===============================================
GST IT DEPARMENT
===============================================
WARNING
Please, dont open pdf files from unknown source.
 
Adobe confirms PDF zero-day attacks. Disable JavaScript now.
 
http://blogs.zdnet.com/security/?p=5119&tag=nl.e589
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20111114/74b43178/attachment.html