[SLS-CC] Fw: Notes from today's SEA SAWG Coordination meeting on the SCCS-ARD document updates

Thu Jun 24 09:10:46 UTC 2021

Dear colleagues,
 FYI on the SEA SAWGN coordination meeting (presentation in attachment)

Regards
HE Space Operations for ESA - European Space Agency
Ph.D. Andrea Modenini
Communication Systems & Technologies Engineer 
TT&C and PDT Systems & Techniques Section (TEC-EST)
RF Systems Division
ESTEC
Keplerlaan 1, PO Box 299
NL-2200 AG Noordwijk, The Netherlands
andrea.modenini at esa.int | www.esa.int
T +31 71 56 53439
----- Forwarded by Andrea Modenini/estec/ESA on 24-06-21 11:09 -----

From:   "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
To:     "CCSDS Engineering Steering Group - CESG Exec" 
<cesg at mailman.ccsds.org>, "Enrico.Vassallo at esa.int" 
<Enrico.Vassallo at esa.int>, "D'Amore Giuseppe" <giuseppe.damore at asi.it>, 
"Gilles Moury" <Gilles.Moury at cnes.fr>, "Colin Haddow" 
<Colin.Haddow at esa.int>, "Andrea.Modenini at esa.int" 
<Andrea.Modenini at esa.int>, "Lee, Dennis K (US 332G)" 
<dennis.k.lee at jpl.nasa.gov>, "Ignacio.Aguilar.Sanchez at esa.int" 
<Ignacio.Aguilar.Sanchez at esa.int>, "EXTERNAL-Pietras, John V (US 
332C-Affiliate)" <john.pietras at gst.com>, "Andrews, Kenneth S (US 332B)" 
<kenneth.s.andrews at jpl.nasa.gov>, "Barkley, Erik J (US 3970)" 
<erik.j.barkley at jpl.nasa.gov>, "Hamkins, Jon (US 3300)" 
<jon.hamkins at jpl.nasa.gov>, "Pham, Timothy T (US 3300)" 
<timothy.t.pham at jpl.nasa.gov>, "Bernie Edwards" 
<bernard.l.edwards at nasa.gov>, "Volk, Christopher P (US 335D)" 
<christopher.p.volk at jpl.nasa.gov>, "Ramon Krosley" 
<r.krosley at andropogon.org>, "Kazz, Greg J (US 312B)" 
<greg.j.kazz at jpl.nasa.gov>, "Ricard.Abello at esa.int" 
<Ricard.Abello at esa.int>, "Javier.DeVicente at esa.int" 
<Javier.DeVicente at esa.int>, "Howie Weiss" <Howard.Weiss at parsons.com>, 
"Keith Scott" <kscott at mitre.org>, "Mario.Merri at esa.int" 
<Mario.Merri at esa.int>, "he xiongwen" <hexw501 at hotmail.com>, 
"Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, "Lotten 
Bergstroem (external)" <Lotten.Bergstroem at esa.int>, "Wilmot, Jonathan J. 
(GSFC-5800)" <jonathan.j.wilmot at nasa.gov>, "Klaus-Juergen Schulz" 
<Klaus-Juergen.Schulz at esa.int>, "Enrico.Vassallo at esa.int" 
<Enrico.Vassallo at esa.int>
Date:   24-06-21 00:53
Subject:        Notes from today's SEA SAWG Coordination meeting on the 
SCCS-ARD document updates

Dear SLS, CSS, SIS, SEA, and SOIS colleagues,

We just held a meeting to review the proposed set of changes that the SEA 
Systems Architecture WG (SAWG) is working on to revise the Space 
Communication Cross Support Architecture Requirements Document (CCSDS 
SCCS-ARD, 901.1-M-1). That document presently describes how more than 
fifty-seven (57) normative CCSDS standards may be fitted together, like 
some giant jig-saw puzzle, to mee the needs of users who design and build 
flight and ground communications assets. In the time since that standard 
was published a number of these normative standards have been updated, 
some with new features, and a significant number of new standards have 
been published, especially in SLS and CSS, but also in SEA itself.

We reviewed the major issues we identified with the current document 
structure that requires changes to the chapters for clarity of 
presentation. We also reviewed some of the complexities introduced by new 
standards, such as USLP, optical comm, VCM, and newer security features 
that are driving a change in approach. And we discussed adding all of the 
new standards that have been introduced since this document was published.

We are attaching the presentation where we discussed these issues and how 
we plan to address them.  This is an unusual request for a WG, which 
typically do this sort of work behind closed doors, but since this 
document cross cuts all of your WGs we thought it useful and, we hope, 
valuable to you. Since we have focused on ABA deployments the only Area 
that is not directly affected yet is SIS.  SOIS, and others, also raised 
some issues having to do with relay architectures, off-Earth instances of 
what are essentially treated as Earth-bound ESLT services in the ABA 
context.  Most of this will be addressed in the “ABCBA” and Solar System 
Internet (SSI) configurations that are  in the next batch of updates.

I am attaching the presentation here.  Please review it in the context of 
the current CCSDS 901.1-M-1 document, which these changes will update.  In 
particular, for SSI and relay sorts of configurations, the SSI 
sub-sections, even as they are now, should provide the necessary framework 
of functions, deployments, and examples to cover these future concerns.

What follows is my scribbled notes from the WebEx.  If there are any 
issues please provide corrections so that we have a “complete enough” of 
minutes with which to make progress in resolving issues.

Last comments: This is a complicated set of topics, with some distinct, if 
not clearly articulated, sets of relationships.   In this document we wish 
to make these as clear as we can.  In some cases we have identified open 
issues that we, the CCSDS members, really ought to address.  And in some 
cases we have new people, in new leadership positions, who will need help 
to understand the complexities and to help lead us to satisfactory, 
consensus-based, outcomes.   My personal request is that we try and work 
together, for the greater good, to develop and document outcomes that work 
for all of us and our user base.

Thanks, Peter

Brief Meeting Notes – 23 June 2021

Attendees: Shames, Krosley, De Cola, Pham, Vassallo, Sanchez-Aguillar, de 
Vicente, Hamkins, Volk, Haddow, Calzolari, Edwards, Kazz, Barkley, Wilmot, 
Schulz, Modenini (please update if I left anyone off this list)

Discussion notes: relative to pages in the attached presentation

Pgs 5-6, Andrews:  What is the  relationship of this CCSDS 901.1-M-1 
SCCS-ARD doc to the existing SLS Overview of Space Communication Protocols 
(OSCP), CCSDS 130.0-G-3?  Do we need both?
Answer: The OSCP is a  useful doc, and it  covers the SLS (and some SIS) 
protocol stack, but the OSCP is not an architecture document and it does 
not address CSS  at all, nor really much about SIS.   It may be a useful 
companion to  the the SCCS-ARD, but it is much more limited in coverage of 
topics and only addresses a limited set the protocol stack and deployment 
issues.  It is up to  SLS to determine whether they wish to retain this 
document.

Pg 6, Calzolari: Raised the issue of the “Forward / Return File service, 
that it is a low IOAG priority (stated as “minus infinity”), and that 
agencies are doing as they wish to implement some sort of “split mode” 
CFDP file delivery agent.
Answer:  Agreed that this is a low priority for CCSDS, and that it may be 
better for CCSDS to reject it, but that is not the role of this WG, we 
just make note of such problems.  Agreed that Agencies are free to 
implement “split mode CFDP” in any way they deem suitable, but that this 
is not a standard approach nor is it likely to be cross-supported.

Pgs 8-9:  The group agreed that the use of the proposed revisions to Sec 
4, and the new tables in Sec 6, made a lot of sense and were much  clearer 
than the alternative.

Pg 11, Schulz: There was a later question as to whether this document is 
just listing possible options or making concrete recommendations about 
selections of future standards that are preferred.
Answer: The inclusion of “R<n>” markings in various tables are, in fact, 
intended to draw attention  to the CCSDS Recommended paths forward.  We 
can, and should, revisit this as a group and provide such guidance 
wherever  we can.  One stated example is recommending use of USLP for high 
rate, bi-directional, mission comms, such as for human rated missions, 
along with FF-CSTS.

Pg 12, Pham: The question was raised about inclusion of the EF-CLTU Orange 
Book in this document, particularly in Sec 4 Services, because it is of 
interest to the ISS and Artemis missions.  This also came up again in the 
context of Table 6-8, pg 17.
Answer: There is agreement that we do need to address the use of this 
Experimental, Orange Book, spec for these important missions, but also 
agreement that we  should not warp the already complicated structure of 
this  document to meet the needs of these slow moving missions that are 
retaining these older protocols.  The recommendation is to put a new Note 
(N4) in table 6-8 (see pg 17) to the effect that while AOS forward links 
are recommended to be supported by FF-CSTS, that they may be supported, in 
CLTU form, using  F-CLTU or the obsolescent EF-CLTU.  A similar note may 
be  useful in Sec 4.

Pgs 12-20, Andrews: Ken raised a question about the meaning of the column 
headings in the tables on pgs 12-20.  In many cases the column headers are 
observed to be the same as the protocol names on the rows.  What are these 
really intended to represent?  Barkley wanted to make sure that “Interface 
Binding Signature” is clearly defined in the document.
Answer:  The column headers are really intended to name the 
Service/Function that is being provided.  The rows are intended to map out 
the stack of protocols that support that service interface, which is, in 
effect, the interface binding signature for the service.  Recommendation 
is to reword the column headers to reflect their role as Service / 
Function (e.g “Deliver tracking data” instead of TD-CSTS)  and the row 
entries as the  protocols that form the “stack”.

Pg 14, Haddow/Barkley: The question of just what was meant by “Raw 
Radiometric” data, or, for that matter, “Validated Radiometric” data was 
raised.  This is in the context of using TGFT [64] and XFDU as the 
transport method and data format.
Answer: Agreed that the XFDU format, required content description, must be 
provided in order for the use of TGFT to make sense.  Agreed that this is 
an issue that the MOIMS Nav WG is in the best position to address.
Typo?  There was also a question about the “N” in the Raw Radiometric 
column  of this table instead of an “M”?

Pg 14, de Vicente/Volk: The question of just how the D-DOR WG currently 
returns their voluminous file data, using the RDEF [38] formatted files 
was raised.
Answer: The response shown, using SFTP, was stated to be accurate.  We 
need a reference for this.

Pg 15, Haddow/Barkley: Why is HTTP over TLS [55] the protocol shown to 
carry SM “information entities”?
Answer: This is intended to be future looking, and SM transport protocol 
is likely to be HTTP/REST therefore it is safe (enough) to use it in this 
table as a [Future] protocol.  Agreed.

Pg 17, Sanchez-Aguilar, Pham, Schulz, and others: This table generated a 
lot of discussion.  We traced AOS and TC, in particular, down through the 
stacks and into the notes.  There was agreement that this was a pretty 
good way to describe all of the complexities inherent in what has, in 
fact, been standardized.  There was also a strong desire to understand 
just what we were trying to describe and to review these tables in detail. 

Issues:
1.      How does the TC path work?
2.      How does the AOS path work?
3.      How do the USLP (fixed and variable) path(s) work?
4.      Why does F-CLTU for TC S&CC reference C2 which is only about 
optical comm?
5.      Can we put a note, N4, into the cell for AOS forward and F-CLTU 
indicating that both F-CLTU, and EF-CLTU, can be used, with some local 
wrangling, to support synchronous AOS forward links, but that FF-CSTS is 
recommended?
6.      Just how much of what is in this table should be shown as 
“Recommended” as opposed to just “Optional”
Answer: Table still needs work and probably a new N4 note, at a minimum. 
Request: That this group undertake a careful review to make sure that 
these tables make sense and that they are accurate.

Pg 17, Sanchez-Aguilar, Wilmot: How does this table address TC commands 
sent from a relay, or a relay S/C running DTN to a leaf node over a local 
/ proximate protocol such as WiFi?
Answer:  All of these sorts of ABCBA and SSI deployment questions will be 
addressed in the SSI sub-sections of the document which will be worked in 
the next round of edits.  The SSI sections in the current edition should 
be reviewed with an eye toward whether this already provides a viable 
framework for such discussions.  It defines a pretty broad variety of node 
types and possible / example configurations.

Pg 18, Schulz: What is the role of this document?  Is it to provide 
recommendations or just documentation?
Answer: There is the intent to provide recommendations of best options 
where we can reach consensus on what those might be.  See discussion on pg 
11. We will provide the current draft document, and the “R<n>” parts to 
anyone who requests it.

Pg 21-24, Barkley: Is any simplification of the whole complex set of three 
almost identical VCM protocols going to be possible?   It seems that 
Agency interests drove us to this awkward and complicated situation.
Answer: While the SEA SAWG would also like to get this situation fixed we 
are in the same situation as we stated in Pg 6 (and 29-30) in regard 
Fwd/Ret CFDP.  It is up to the CCSDS Areas and WG to fix this stuff up. 
The best we can do is to point out that there are issues and to attempt to 
describe them as clearly as possible.  We would like to encourage that 
this be done, the current situation is awkward, at best.

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/sls-cc/attachments/20210624/1fde2f6a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SCCS-ARD_5yr_refresh-210623.pptx [Read-Only].pptx
Type: application/octet-stream
Size: 1426404 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-cc/attachments/20210624/1fde2f6a/attachment-0001.obj>