[CESG] SOIS Comment on MIB configuration data: [EXTERNAL] Fw: SLS reply to SEA Conditions on Poll CESG-P-2019-12-002 Approval to release CCSDS 131.3-P-1.1, CCSDS Space Link Protocols over ETSI DVB-S2 Standard (Pink Sheets, Issue 1.1) for CCSDS Agency review
Margherita.di.Giulio at esa.int
Margherita.di.Giulio at esa.int
Tue Feb 4 15:07:42 UTC 2020
Dear All,
having seen the thread of discussions, I’d like to recall that there is
(or should be) an ongoing activity about the assessment of commonality of
data representation between Recommendations belonging to different CCSDS
domains.
At the CESG Meeting in Mountain View we noted the following:
“Management Information Base: different domains may have similar needs to
represent the information that they manage. There is , possibly, an
intersection between the Management Information Bases Electronic Data
Sheets (EDS: SOIS), the Functional Resource model (FR: CSS), and network
management concerns (SIS). This topic to be further explored by joint
meetings by involved Areas “
At the CESG Meeting in Darmstadt, Jonathan presented a couple of slides
(Title: “Operational Interfaces for On-Board Service Management, Protocol
Management Information Base (MIB)) which only introduced the topic. So,
this matter still needs to be actually tackled.
The MoM of the Darmstadt meeting records the following action(s) :
- AI/S19-1 JW : JW to produce a short presentation to introduce the
notion of MIB, data formats (template) , commonality and possible
relationship to other Areas.
- Status: Not much progress since the CESG Telecon. Some discussion
took place during the Technical Meeting. This action is closed, but a new
AI is issued:
- New AI : J.Wilmot: to call a Telecon involving SOIS, SIS, CSS to
assess data representation aspects (e.g. MIB) in different CCSDS domains
and brainstorm about commonalities. Outcome to be presented at CESG
Mid-term Telecon.
I think we shall keep pursuing the definition of a CCSDS “formalism” for
data representation.
With respect to Jonathan’s comments to the CESG Poll about “SLP over ETSI
DVB-S2 Standard” I think that only once the formalism has been established
it will make sense to request that CCSDS Recommendation, which containing
MIB or configuration data, shall stick to it
Finally, I'd like to ask Jonathan to let us have an update at the upcoming
CESG Telecon.
Kind regards,
Margherita
--------------------------------------------------------------
Margherita di Giulio
Ground Station Systems Division
Backend Software Section (OPS-GSB)
European Space Agency ESA/ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49-6151-902779
e-mail: Margherita.di.Giulio at esa.int
From: "Shames, Peter M\(US 312B\) via CESG" <cesg at mailman.ccsds.org>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>,
"Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>
Cc: "CCSDS Engineering Steering Group - CESG Exec"
<cesg at mailman.ccsds.org>, "Kazz, Greg J\(US 312B\)"
<greg.j.kazz at jpl.nasa.gov>, "Tom Gannett" <thomas.gannett at tgannett.net>,
"Massimo.Bertinelli at esa.int" <Massimo.Bertinelli at esa.int>, "Andrews,
Kenneth S\(US 332B\)" <kenneth.s.andrews at jpl.nasa.gov>
Date: 03/02/2020 21:33
Subject: Re: [CESG] SOIS Comment on MIB configuration data:
[EXTERNAL] Fw: SLS reply to SEA Conditions on Poll CESG-P-2019-12-002
Approval to release CCSDS 131.3-P-1.1, CCSDS Space Link Protocols over
ETSI DVB-S2 Standard (Pink Sheets, Issue 1.1) for CCSDS Agency review
Sent by: "CESG" <cesg-bounces at mailman.ccsds.org>
Hi Gippo and Jonathan,
It may come as no surprise that I think both of you are "right" in some
sense, but that the best path may lie in the middle of the two positions
that you have staked out.
I think Gippo is "right" in that in most of our specs where we have MIB
specified we do not tend to make it be a formalized part of the spec.
I think that Jonathan is "right" in that some added formality would make
these MIB values be more easily interpreted and exchanged for
interoperability.
Where I differ from Gippo is that I think you could add more clarity in
how the MIB and its fields are defined without straying into the "this is
how you implement it" territory. In fact, just using those Tables 5-1 and
5-2 as examples, the only way to read that is that "transfer frame length"
is an integer with a range and that CRC is an enumerated list that
references specified, documented, algorithms. In the case of Table 5-2 it
is even clearer that Transmission Mode is an enumerated list, Baseband
pulse shaping is a float, and that scrambling code, and other fields, are
integers. That is what they state, either explicitly, i.e. "List of
integers", or implicitly, i.e. fractional numbers with a decimal point.
Specifying these as a data type and value range pair instead of the
ambiguous "allowed values" is not implementation, just clarity.
Where I differ from Jonathan is that some of the interface detail
specificity that is possible with the EDS and DoT may be overkill for this
purpose, which is not necessarily thought of as an "interface". It may,
as is pointed out in many specs that include a "MIB", just be a list of
the kinds of parameters that implementations may choose to put into a
table, or embed in code, in their implementations. From the PoV of the
standard these may be treated as "implementation concerns". That means
that there is not any "thou shall" language about how to implement them.
But that doesn't mean that they aren't important, nor does it mean that
treating them a little more formally wouldn't be a good thing.
From the PoV of our users I will assert that knowing just exactly which
choices were made during the implementation of programs that are intended
to interoperate is essential. It may not be a concern HOW they are
implemented, that is an implementation choice, but it certainly matters
THAT they are implemented and which options are available. This is
something that could well be handled in a fully specified PICS that fills
out the PICS pro forma for two (or more) imp[lementations. But that, I
will assert, would be made more simple if all of the data types and values
that might appear in a MIB were clearly identified, and in a way where
they are easy to document. Use of the EDS / DoT is a documented method
for doing this, but so is use of the PICS pro forma, as long as the data
type and value ranges that are possible are clearly specified along with
the options that are actually implemented,
I think a little more clarity in the specs that include MIBs would be a
benefit to everyone.
Cheers, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Monday, February 3, 2020 at 5:38 AM
To: "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>
Cc: Gilles Moury <Gilles.Moury at cnes.fr>, Kenneth Andrews
<kenneth.s.andrews at jpl.nasa.gov>, "Massimo.Bertinelli at esa.int"
<Massimo.Bertinelli at esa.int>, Peter Shames <peter.m.shames at jpl.nasa.gov>,
Tom Gannett <thomas.gannett at tgannett.net>, Greg Kazz
<greg.j.kazz at jpl.nasa.gov>
Subject: SOIS Comment on MIB configuration data: [EXTERNAL] Fw: SLS reply
to SEA Conditions on Poll CESG-P-2019-12-002 Approval to release CCSDS
131.3-P-1.1, CCSDS Space Link Protocols over ETSI DVB-S2 Standard (Pink
Sheets, Issue 1.1) for CCSDS Agency review
Jonathan,
first of all, it is our understating that the specific comment
addressed by this discussion is a comment and not a condition.
Can you please confirm?
For the remaining part of this e-mail I include in cc also Greg as you
expressed similar comments for SLP documents.
You are talking about the "formality of protocol MIB definitions" and in
your attached file you actually start from the tables in CCSDS 131.3-P-1.0
Chapter 5 adding two columns.
Actually the column "Units" is not really an addition as the column
"Allowed Values" in the book actuary covers your two columns Units and
Range.
The real addition is column "Data Type" that is really computer oriented;
i.e. an implementation detail IMO.
However section APPLICABILITY for this book (and for most of the SLS Area
books) clearly states that "The Recommended Standard includes
comprehensive specification of the services and protocol for
inter-Agency cross support. It is neither a specification of, nor a
design for, real systems that may be implemented for existing or future
missions." giving a full justification for the way Managed Parameters are
presented.
The details you are asking are really pointing to the implementation and
also depend on the way the real system is implemented (e.g. an hardware
encoder on board could use different programming languages and
characteristics with respect to an on ground decoder running over
sophisticated software).
Even sympathising with the fact that "missions could exchange the MIB
configuration data", I find this is not pertinent for these SLS Books but
it rather represents something that should be addressed by other standards
as e.g. your Electronic Data Sheets or the exchange of Service Management
Data or the CSTS Functional Resource Model.
Best regards
Gian Paolo
From: "Wilmot, Jonathan J. (GSFC-5820)"
<jonathan.j.wilmot at nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "Massimo.Bertinelli at esa.int" <Massimo.Bertinelli at esa.int>,
"Gilles Moury" <Gilles.Moury at cnes.fr>, "Andrews, Kenneth S (JPL-332B)[Jet
Propulsion Laboratory]" <kenneth.s.andrews at jpl.nasa.gov>, "Tom Gannett"
<thomas.gannett at tgannett.net>, "Shames, Peter M (JPL-312B)[Jet Propulsion
Laboratory]" <peter.m.shames at jpl.nasa.gov>
Date: 31-01-20 20:46
Subject: RE: [EXTERNAL] Fw: SLS reply to SEA Conditions on Poll
CESG-P-2019-12-002 Approval to release CCSDS 131.3-P-1.1, CCSDS Space Link
Protocols over ETSI DVB-S2 Standard (Pink Sheets, Issue 1.1) for CCSDS
Agency review
Gian Paolo,
I think we should have a broader discussion on the issues with this
topic of operational interoperability. Maybe bring it up at the next CESG
telecon. CCSDS has been inconsistent with the formality of protocol MIB
definitions. I am pushing to have MIB definitions be complete enough with
unique names such that a missions could exchange the MIB configuration
data. This way both ends of a protocol would operationally match.
Please let me know if the attachment makes sense.
Kind regards,
Jonathan
Jonathan Wilmot
NASA/GSFC Code 582
cFS Software Architect
CCSDS SOIS Area Director
301-286-2623
From: Gian.Paolo.Calzolari at esa.int <Gian.Paolo.Calzolari at esa.int>
Sent: Tuesday, January 28, 2020 4:15 AM
To: Wilmot, Jonathan J. (GSFC-5820) <jonathan.j.wilmot at nasa.gov>
Cc: Massimo.Bertinelli at esa.int; Gilles Moury <Gilles.Moury at cnes.fr>;
Andrews, Kenneth S (JPL-332B)[Jet Propulsion Laboratory]
<kenneth.s.andrews at jpl.nasa.gov>; Tom Gannett
<thomas.gannett at tgannett.net>
Subject: [EXTERNAL] Fw: SLS reply to SEA Conditions on Poll
CESG-P-2019-12-002 Approval to release CCSDS 131.3-P-1.1, CCSDS Space Link
Protocols over ETSI DVB-S2 Standard (Pink Sheets, Issue 1.1) for CCSDS
Agency review
Jonathan,
here attached the mail already sent to Peter etc.
The requested work on the other books is already in progress (approved
projects) and there is no reason to defer the start of the Agency Review
for the Pink Sheets to 131.3-B for this.
With respect to your specicif comment "It should be an overall goal to
provide for common operational interfaces for Managed parameters published
in CCSDS standards. To that end, more specific common data types should be
provided: signed/unsigned Integer, Boolean, Enumerations (ON, OFF),
(Short, Normal, Both) …, float, etc. This would allow the exchange of MIB
parameters based on common names and types between organizations. The
binary encoding of those MIBs could be specified in CCSDS Electronics data
sheets, or XTCE." can you please clarify what you want precisely and
formulate it one or more PIDs in the usual FROM/TO from?
Otherwise there is no way to consider this comment.
Best regards
Gian Paolo
----- Forwarded by Gian Paolo Calzolari/esoc/ESA on 28-01-20 10:11 -----
From: Gian Paolo Calzolari/esoc/ESA
To: "Shames, Peter M \(312B\)" <peter.m.shames at jpl.nasa.gov>
Cc: "Andrews, Kenneth S \(332B\)" <Kenneth.S.Andrews at jpl.nasa.gov>,
"Gilles Moury" <Gilles.Moury at cnes.fr>, Massimo Bertinelli/estec/ESA at ESA,
"Tom Gannett" <thomas.gannett at tgannett.net>, "Burleigh, Scott C \(312B\)"
<scott.c.burleigh at jpl.nasa.gov>, "Erik Barkley" <Erik.Barkley at jpl.nasa.gov
>
Date: 27-01-20 18:18
Subject: Re: SLS reply to SEA Conditions on Poll CESG-P-2019-12-002
Approval to release CCSDS 131.3-P-1.1, CCSDS Space Link Protocols over
ETSI DVB-S2 Standard (Pink Sheets, Issue 1.1) for CCSDS Agency review
Dear Peter,
I wonder if you had time to consider this SLS reply.
I also copy Scott (that expressed your same condition) and Erik (that
expressed the same concern as comment) reiterating that the work to allow
uplink of AOS and USLP fixed-length frames is in progress for all the 3
coding books concerned. However the contribution from some book editors is
less timely than the one from the 131.3 Book Editor.
Unless there is clear intention of penalising the faster book editor,
there is no reason to defer the start of the Agency Review for the Pink
Sheets to 131.3-B.
Thank you all for a prompt reaction to fix this issue.
Gian Paolo
From: Gian Paolo Calzolari/esoc/ESA
To: "Shames, Peter M \(312B\)" <peter.m.shames at jpl.nasa.gov>
Cc: "Andrews, Kenneth S \(332B\)" <Kenneth.S.Andrews at jpl.nasa.gov>,
"Gilles Moury" <Gilles.Moury at cnes.fr>, Massimo Bertinelli/estec/ESA at ESA,
"Tom Gannett" <thomas.gannett at tgannett.net>
Date: 20-01-20 17:43
Subject: SLS reply to SEA Conditions on Poll CESG-P-2019-12-002
Approval to release CCSDS 131.3-P-1.1, CCSDS Space Link Protocols over
ETSI DVB-S2 Standard (Pink Sheets, Issue 1.1) for CCSDS Agency review
Dear Peter,
despite the poll, will only close in some time, SLS have internally
discussed about your "APPROVE WITH CONDITIONS" vot.
The conditions are attached (thanks to Gilles!).
Here below the SLS position.
-------------------------------
The SLS Area and the C&S WG reject SEA AD Conditions because the work
requested by SEA AD is already agreed and in progress in the C&S WG.
.C&S WG has currently 3 CWE projects running:
1) Space link protocols over ETSI DVB-S2 standard, Issue 2
This update to the Blue Book will produce issue 2, enabling the use USLP
frames as well as allowing space-to-space and ground-to-space links
applications.
https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=692&ContentTypeId=0x0100B63160D64FE81342BE42A874DE7E703D
This is the project undergoing poll for Agency review.
2)“TM Synchronization and Channel Coding” Issue 4
The Recommended Standard for TM Synchronization and Channel Coding
contains specifications to be used by space missions on synchronous
communications links. This update to the Blue Book will produce issue 4,
and will add a short chapter that specifies a subset of codes to be used
in ground-to-space links. Input of USLP frames will also be addressed.
https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=688&ContentTypeId=0x0100B63160D64FE81342BE42A874DE7E703D
This project is pending on NASA input.
3) Flexible Advanced Coding and Modulation Scheme for High Rate Telemetry
Applications, Issue 2
This update to the Blue Book will produce issue 2, enabling the use USLP
frames as well as allowing space-to-space and ground-to-space links
applications.
https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=690&ContentTypeId=0x0100B63160D64FE81342BE42A874DE7E703D
This project is pending on ESA input.
Therefore there is no reason to defer the start of the Agency Review for
the Pink Sheets to 131.3-B.
--------------------------------------------
Best regards
Gian Paolo
[attachment "PS DVBS2 condition.docx" deleted by Gian Paolo
Calzolari/esoc/ESA]
This message is intended only for the recipient(s) named above. It may
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo at esa.int).[attachment "DVB_S2 MIB tables.xlsx"
deleted by Gian Paolo Calzolari/esoc/ESA]
This message is intended only for the recipient(s) named above. It may
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo at esa.int).
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20200204/08af76f9/attachment-0001.htm>
More information about the CESG
mailing list