[Sea-sa] [EXTERNAL] Re: Request for a special working meeting on some key Cross Support architecture document issues

[Holger.Dreihahn at esa.int]

Dear Keith and Peter,
I think for DTN and it's technical applicability, we are all on the same 
page. The matter for us is that ESA's next generation of satellites will 
implement CFDP Class 2 and we see no way to get CFDP C1 over BP over LTP 
'on-board'. As such I was presenting an architecture, which is from a 
satellite point of view 'pure' CFDP Class 2, but the CFDP Class 2 
implementation on ground is distributed over several places, basically to 
address a number of requirements and operational constraints as outlined 
below. To make this on-ground CFDP Class 2 distribution inter operable, 
and we believe we can use a external (commercial) ground station services 
within that architecture, we have proposed, drafted and tested one 
(relatively simple) additional service: The CSTS CFDP Return PDU Service. 

However, as Keith says Peter has a different starting point (Fwd/Rtn File 
Service) and I was just presenting what we have discussed in ESA for a 
CFDP Class 2 scenario because I saw similarities. That should have served 
as input for the discussion of the meeting on the 20th, that's all.

Best regards,
Holger


Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | H-293
+49 6151 90 2233 | http://www.esa.int/esoc



From:   "Dr. Keith L Scott" <kscott at mitre.org>
To:     "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>, "Shames, 
Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Cc:     "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>, "Gian 
Paolo Calzolari" <Gian.Paolo.Calzolari at esa.int>, "Gilles Moury" 
<Gilles.Moury at cnes.fr>, "Kazz, Greg J (US 312B)" 
<greg.j.kazz at jpl.nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" 
<jonathan.j.wilmot at nasa.gov>, "Klaus-Juergen Schulz" 
<Klaus-Juergen.Schulz at esa.int>, "Sanchez Net, Marc (US 332H)" 
<marc.sanchez.net at jpl.nasa.gov>, "Margherita.di.Giulio at esa.int" 
<Margherita.di.Giulio at esa.int>, "Burleigh, Scott C (US 312B)" 
<scott.c.burleigh at jpl.nasa.gov>, "SEA-SA" <sea-sa at mailman.ccsds.org>
Date:   14/01/2021 15:35
Subject:        Re: [EXTERNAL] Re: Request for a special working meeting 
on some key Cross Support architecture document issues



I think the issues Peter mentions in the original email are all the result 
of taking a hard look at the ‘easy’ problem of writing a TGFT-to-CFDP 
gateway, and they’ll recur for every application we want to run between 
the ESLT and SUN (e.g. messaging, …)
 
I think an end-to-end CFDP/DTN solution is much cleaner (fewer protocols, 
no application-specific gateways) and could still meet the requirements 
Holger mentions:
If you have to run CFDP class-2, run it over DTN (it’ll be inefficient but 
it’ll work)  As Scott mentioned, CFDP class-1 over BP would be better.
If you have to control every bit that is sent up to the spacecraft, route 
the DTN bundles (e.g. including those that contain CFDP PDUs) via the EUT 
and write software THERE that allows operators to inspect/pass/deny/modify 
them (this is code that doesn’t exist yet but that I argue is much simpler 
than a TFGT-to-CFDP gateway) and go ahead and build the CLTUs there if you 
like.
Bonus: works transparently (to CFDP) when the transfer is split among 
several ESLTs
 
I get that DTN isn’t deployed yet, but the seems to be to develop new 
protocols / applications and to deploy THEM – is that really easier than 
deploying DTN?
 
 
                                V/r.
 
                                --keith
 
 
From: "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>
Date: Wednesday, January 13, 2021 at 2:51 AM
To: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Cc: Eric Barkley <erik.j.barkley at jpl.nasa.gov>, Gian-Paolo Calzolari 
<Gian.Paolo.Calzolari at esa.int>, Moury Gilles <Gilles.Moury at cnes.fr>, Greg 
Kazz <greg.j.kazz at jpl.nasa.gov>, Jonathan Wilmot 
<jonathan.j.wilmot at nasa.gov>, "Klaus-Juergen. Schulz" 
<Klaus-Juergen.Schulz at esa.int>, Keith Scott <kscott at mitre.org>, "Sanchez 
Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov>, 
"Margherita.di.Giulio at esa.int" <Margherita.di.Giulio at esa.int>, Scott 
Burleigh <scott.c.burleigh at jpl.nasa.gov>, SEA-SA 
<sea-sa at mailman.ccsds.org>
Subject: Re: [EXTERNAL] Re: Request for a special working meeting on some 
key Cross Support architecture document issues
 
Dear Peter, 
When I talk about CFDP below, I mean CFDP class 2. DTN would of course be 
the technically sound solution to a lot of problems and we would not need 
to invent new services. However, in practice the adoption of CFDP class 
two was apparently what was possible for the next generation of 
satellites. On top of that, flight control teams often insist on being in 
control of everything going up to the spacecraft, so we invented the CSTS 
Return CFDP PDU service to relay CFDP PDUs (NAK etc.) from the ESLT to the 
EUN, where the CFDP PDUs are merged into the CLTUs anyway sent from the 
EUN to the ESLT and finally the spacecraft. At that point SLE CLTU does 
the job, although it's clear that CSTS Forward Frame is needed for high 
rate uplinks, or would allow closure of the CFDP class 2 protocol loop in 
the ESLT. 

The feature of the reduced CFDP PDUs we envisage for a more complicated 
scenario: Here CFDP class 2 shall be used to transfer files from the 
spacecraft over several ESLTs to a central location on ground (payload 
processing). No BP involved unfortunately. 

I hope that clarifies some aspects. 

Best regards, 
Holger 

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | H-293
+49 6151 90 2233 | http://www.esa.int/esoc 



From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int> 
Cc:        "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>, 
"Gian Paolo Calzolari" <Gian.Paolo.Calzolari at esa.int>, "Gilles Moury" 
<Gilles.Moury at cnes.fr>, "Kazz, Greg J (US 312B)" 
<greg.j.kazz at jpl.nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" 
<jonathan.j.wilmot at nasa.gov>, "Klaus-Juergen Schulz" 
<Klaus-Juergen.Schulz at esa.int>, "Keith Scott" <kscott at mitre.org>, "Sanchez 
Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov>, 
"Margherita.di.Giulio at esa.int" <Margherita.di.Giulio at esa.int>, "Burleigh, 
Scott C (US 312B)" <scott.c.burleigh at jpl.nasa.gov>, "SEA-SA" 
<sea-sa at mailman.ccsds.org> 
Date:        11/01/2021 23:51 
Subject:        Re: [EXTERNAL] Re: Request for a special working meeting 
on some key Cross Support architecture document issues 




Dear Holger, 
  
Thanks for the reply re what you are contemplating.  It helps to offer an 
understanding of what you have been thinking about. 
  
If I read this correctly we will still need to deploy the FF-CSTS in the 
ESLT and to provide the necessary CFDP agent software and associated 
“plumbing” to accommodate this insertion of functionality.  And then we 
will also need, on top of that, to define this new “CSTS Return CFDP PDU 
Service”, to splice this “reduced CFDP File Data PDU delivery function” 
into the CFDP agent, and also define how these new, specialized, “monitor” 
and “control” interfaces are to work. 
  
This still looks like several (at least three) new protocols or 
adaptations of services to accomplish something that “ought to be” simple. 
 But then, things are seldom as simple as we would like them to be. 
  
As a side question, was any sort of trade study done to evaluate the use 
of DTN to accomplish this instead?  That has the advantage, at least from 
my point of view, of being an approach that moves us into a space 
internetworking future, even as it brings its own complexities.  Was this 
even considered? 
  
Thanks, Peter 
  
  
From: "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>
Date: Monday, January 11, 2021 at 1:21 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Erik Barkley <erik.j.barkley at jpl.nasa.gov>, Gian Paolo Calzolari 
<Gian.Paolo.Calzolari at esa.int>, Gilles Moury <Gilles.Moury at cnes.fr>, Greg 
Kazz <greg.j.kazz at jpl.nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" 
<jonathan.j.wilmot at nasa.gov>, Klaus-Juergen Schulz 
<Klaus-Juergen.Schulz at esa.int>, Keith Scott <kscott at mitre.org>, Marc 
Sanchez Net <marc.sanchez.net at jpl.nasa.gov>, 
"Margherita.di.Giulio at esa.int" <Margherita.di.Giulio at esa.int>, Scott 
Burleigh <scott.c.burleigh at jpl.nasa.gov>, SEA-SA 
<sea-sa at mailman.ccsds.org>
Subject: [EXTERNAL] Re: Request for a special working meeting on some key 
Cross Support architecture document issues 
  
Dear Peter, 
At ESA we have looked at similar problems for a CFDP entity running in a 
ground station (ESLT) and a MOC (EUN) being 'in control' of SC and 
potentially some items (CFDP) in the ESLT. We have come up with some 
internal conclusions and suggestions, we would be more than happy to 
discuss them with you: 

- We propose a new CSTS Return CFDP PDU Service. This is currently an ESA 
draft of a CSTS Services returning CFDP PDUs from an ESLT to the EUN in a 
standardized way. It also offers a reduced CFDP File Data PDU delivery, 
which is required to analyze the CFDP protocol in realt time at the EUN 
for some reason, but the bandwidth on the spacelink is (much) higher than 
from the ESLT to the EUN. In the context below it may or may not be 
required, 
- to Monitor the CFDP entity in an ESLT, we foresee the CSTS Monitored 
Data Service with the Functional Resource Model providing a CFDP entity 
Functional resource, a CFDP entity has been part of the Functional 
Resource Model review (Tier 1). That monitoring can of course be extended 
to what is required in terms of 'out of band report' 
- To control the CFDP entity in an ESLT, we envisage a CSTS Service 
Control, being able to send control directives from e.g.an EUN to an ESLT. 
The available control directives are again provided by the Functional 
Resource Model 

Best regards, 
Holger 

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | H-293
+49 6151 90 2233 | http://www.esa.int/esoc 



From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>, 
"Holger Dreihahn/esoc/ESA" <Holger.Dreihahn at esa.int>, "Burleigh, Scott C 
(US 312B)" <scott.c.burleigh at jpl.nasa.gov>, "Keith Scott" 
<kscott at mitre.org>, "Sanchez Net, Marc (US 332H)" 
<marc.sanchez.net at jpl.nasa.gov>, "Gian Paolo Calzolari" 
<Gian.Paolo.Calzolari at esa.int>, "Gilles Moury" <Gilles.Moury at cnes.fr>, 
"Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov>, "Wilmot, Jonathan J. 
(GSFC-5820)" <jonathan.j.wilmot at nasa.gov> 
Cc:        "SEA-SA" <sea-sa at mailman.ccsds.org>, "Klaus-Juergen Schulz" 
<Klaus-Juergen.Schulz at esa.int>, "Margherita.di.Giulio at esa.int" 
<Margherita.di.Giulio at esa.int> 
Date:        07/01/2021 20:00 
Subject:        Request for a special working meeting on some key Cross 
Support architecture document issues 





Dear CCSDS colleagues, 
 
I want to start by wishing you all a very happy and prosperous New Year. I 
do this in spite of the recent horrifying news that a mob of hooligans, 
domestic terrorists, attacked the US Capitol yesterday.  Optimist that I 
am, I am sure we will put this behind us.  I hope I am not wrong in this. 
 
That diversion aside, I wish to enlist all of you in looking at a set of 
issues that have just some up in the process of tackling the updates to 
the Space Communication Cross Support (SCCS) Architecture documents (ARD / 
ADD), the SCCS-ARD, CCSDS 901.1-M-1.  You all know that as part of the 
updates to this document we have been asking for feedback on recently 
published standards (since 2015) and on new standards that are in work now 
and that are expected to be published in the next 3-5 years.  If you have 
not yet provided your inputs please do so as soon as you can. 
 
The following is a rather long description of what has turned out to be a 
somewhat complicated set of issues.  This email is an attempt to lay out 
the issues so that you can consider them ahead of time, but we are aware 
that an actual face-to-face (virtual) discussion, and likely some work in 
one or more WGs, will be called for to reach a useful conclusion. 
 
What I wish to focus on in this discussion is a set of issues specifically 
related to the following topics: 
A key assumption that has been made, based on the SISG Study from 2009, 
and reflected in the SCCS-ADD/ARD, is that any Earth User Node (EUN, 
nominally the MOC) that controls and operates a Space User Node (SUN, 
colloquially known a spacecraft) or a Space Relay Node (SRN) that offers 
DTN or other relay services, will want to be able to directly command that 
spacecraft and get at least engineering telemetry from that spacecraft. 
This EUN is said to “own” the spacelink and have control over it.  And the 
act of planning, scheduling, and configuring that space link is what 
allows all other traffic to then flow using the link. 
A further key assumption is that for any of the EUNs that operate a 
spacecraft that offers such relay or network services, or that use the 
forward and return file service, is that the Earth Space Link Terminal 
(ESLT, nominally a ground station and associated processing equipment 
including SM, SLE, and CSTS) will implement the Forward Frame CSTS 
(FF-CSTS) which is designed to integrate data flows from multiple Earth 
User Nodes and to interface to CFDP, DTN, frame merging, and frame 
creating production functions within the ESLT.  This is the fundamental 
architectural “production plumbing” that allows all of this stuff to work 
together.  There are a couple of slides from the SCCS ARD that illustrate 
this plumbing, as defined. 
Missions may use (and ESLTs may implement) a forward and return “file 
service”, that uses TGFT to transfer files from the EUN to the ESLT, along 
with a CFDP “agent” in the ESLT that does the actual file delivery 
transfer, using CFDP, over the space link to the Space User Node (SUN, 
otherwise known as the spacecraft). 
One of the recently recognized considerations that this particular 
deployment architecture creates a need for some sort of special, out of 
band, signaling of missing data reports on the return link to the EUN from 
the CFDP agent in the ESLT.  This is a sort of “control report” that the 
EUN can deal with to control re-transmission, which may include sending 
retransmission requests back to the CFDP agent in the ESLT or requests to 
abandon the session and accept a partial file. 
This also requires some as yet unrecognized protocol that will allow the 
CFDP agent in the ESLT to send these “control reports”. 
This scenario also requires some as yet unrecognized control protocol, 
which is needed for the EUN to somehow signal the ESLT just how it wants 
that file to be broken into PDUs in the first place, and how those PDUs 
are to be framed into some virtual channel and merged into the master 
frame stream within the ESLT.  As yet there is no protocol defined to do 
this. 
There must be some clear definition of how all of the features of this 
“File delivery protocol” are to be defined so that it can use the features 
of the TGFT, which is just a file transfer mechanism with none of this 
sort of control framework nor back and forth signaling.
 
This is some sort of “cross support protocol” that belongs in the CSS 
Area, whether it is in the CSTS WG or the SM WG.  That said, it may also 
require some sort of “control report” interface to be spliced into the 
CFDP protocol agent to allow the EUN to be signaled about intermediate 
CFDP protocol status, along with some sort of “control interface” that 
will allow the CFDP agent, in the ESLT, to be controlled from the EUN. And 
there also must be some means for the EUN to tell the CFDP agent in the 
ESLT just how to turn that file into CFDP PDUs, link layer PDUs, 
encapsulate them, and how to merge them into the uplink traffic flow. 
 
In discussing this we also delved into how best to represent the needed 
“production plumbing” in the ESLT.  The nominal CFDP deployment from the 
outset was understood to be an application layer CFDP Agent in the EUN and 
another peer application layer CFDP agent in the SUN.  This new service 
breaks that paradigm and adds what is starting to look like a significant 
bit of new CCSDS protocol plumbing in order to make it all work right with 
this asymmetrical protocol arrangement.  Of course, we could just throw up 
our hands and say “do it by management”, but that is not an interoperable 
approach by any normal meaning of the term. 
 
To be frank, realizing that we will now need to create this brand new set 
of specialized control and signaling protocols, for this one special case, 
probably ought to cause us to question whether it makes sense to define 
this new service at all, as opposed to just deploying the CFDP agent in 
the end nodes of the space link, as it was defined.  We will not address 
it further here, but it appears to be an option that must be considered as 
well. 
 
In talking about this in the SAWG meeting on 6 Jan 21 the following 
questions and observations came up. 
  
The returned “control report” from the CFDP agent in the ESLT to the EUN 
may need to have a whole new protocol defined, TBD. 
The returned “control report” from the CFDP agent in the ESLT to the EUN 
could potentially use an extended SLE R-OCF service, which already does 
something very similar for the link layer control field.  This would not 
need a whole new protocol, just an adaptation of an existing one. 
The returned “control report” and return “CFDP agent control” between the 
CFDP agent in the ESLT and the EUN could potentially use the new SC-CSTS, 
which is intended for “service control”.  This would not need a whole new 
protocol either, but any such “control report” and “control protocol” 
would need to be defined. 
The processing to be done on the file that is sent to the ESLT from the 
EUN must either be “defined by management”, i.e. handled by some out of 
band, unspecified means, or have a protocol defined that can deal with the 
specifics of what the ESLT must do to take the file, chop it up, create 
CFDP PDUs (with whichever of the many CFDP options have been selected by 
the mission in configuring CFDP), package it in SPP or EP, create frames 
of the correct type from those encapsulated PDUs, merge those frames into 
the correct virtual channels, and multiplex them into the frame stream to 
be encoded and radiated within the ESLT. 
Note that most of these kinds of operations, starting with “take the file, 
chop it up” and ending with “insert these new frames into the frame 
stream” are usually done in the EUN.  With this new service these 
operations must be done in the ESLT, and thus the ELST must be instructed 
in just what must be done, in detail. 
Upon further consideration, this part sounds a lot like what was defined, 
in the abstract, as part of the SISG First Hop / Last Hop service.  A 
couple of presentations on that, dating from 2010 and 2011, are included 
for your consideration.  See if what was defined here for sending a file 
to the “Last Hop” in a DTN chain, and for managing that process, looks a 
whole lot like what you think must be defined for this “forward / return 
file service”.  If not identical it is surely similar in nature. 
It is worth noting, as well, that the new CSS Functional Resource Model 
(FRM) defines a set of “production processing” building blocks that could, 
just as easily, be deployed in a relay spacecraft, or in describing the 
behavior inside an ESLT running FF-CSTS and a CFDP agent.  This FRM may 
offer a clean way to define these behaviors and to extend them as needed 
for this purpose.  This is to clearly define the processing that must 
occur within a system element as opposed to the service interfaces and 
protocols that appear at the boundaries of a system element. 
We also briefly discussed the SOIS Electronic Data Sheets (EDS) at the 
start of the meeting, and the relationships, as we understand them, 
between the EDS and the FRM.  This is obviously a subject that also 
requires a deeper dive, but it appears that the strength of the EDS lies 
in defining the interfaces of components in a way where these EDS 
definitions can be used to drive software development.  More on this as we 
dig into it.  The FRM defines the behavior of those components and how we 
expect to connect them.
 
As I think you can all see there is some real work to be done if we are to 
create a Forward / Return File Service spec that it truly interoperable 
and has all these special, and unusual, properties.  We do not think we 
can do this in the SEA SAWG, this is work that must be done in the other 
Areas that “own” the respective sets of standards.  At the same time we 
see some potential for leveraging work in different areas and integrating 
it to provide a more unified end-to-end approach, and that is our express 
goal as we try to help sort this out. 
 
I’ll post a Doodle Poll to see if we can find a mutually agreeable time. 
Meanwhile, I’d like to hear from any of you who have opinions, thoughts, 
considerations, or cautions that you wish to share. 
 
Best regards, Peter 
 
 
[attachment "SISG Last Hop delivery v5.2a 25May10.ppt" deleted by Holger 
Dreihahn/esoc/ESA] [attachment "SISG ADD NW Mgmt Last Hop figures v0.2 
17Oct11.ppt" deleted by Holger Dreihahn/esoc/ESA] [attachment "Fig 6-20 
Fwd File Svc ESLT & EUN.jpeg" deleted by Holger Dreihahn/esoc/ESA] 
[attachment "Fig 7-2 SSI fwd end-to-end.jpeg" deleted by Holger 
Dreihahn/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). 
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).



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/sea-sa/attachments/20210114/7f31f3e7/attachment-0001.htm>