[Sea-sa] DRAFT Meeting Minutes, was Re: [EXTERNAL] Special Working Meeting: SCCS-ARD discussion - fwd/ret file service

Holger.Dreihahn at esa.int Holger.Dreihahn at esa.int
Mon Feb 1 08:42:29 UTC 2021

Hello Peter,
I bit late but some comments. I think for my Slide 3 we did not convey the 
intended message, please have a look.

Best regards,

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>, "Gian 
Paolo Calzolari" <Gian.Paolo.Calzolari at esa.int>, "Kazz, Greg J (US 312B)" 
<greg.j.kazz at jpl.nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" 
<jonathan.j.wilmot at nasa.gov>, "Keith Scott" <kscott at mitre.org>, "Burleigh, 
Scott C (US 312B)" <scott.c.burleigh at jpl.nasa.gov>, "Colin Haddow" 
<Colin.Haddow at esa.int>, "Holger.Dreihahn at esa.int" 
<Holger.Dreihahn at esa.int>
Cc:     "SEA-SA" <sea-sa at mailman.ccsds.org>
Date:   21/01/2021 21:24
Subject:        Re: [Sea-sa] DRAFT Meeting Minutes, was Re: [EXTERNAL] 
Special Working Meeting: SCCS-ARD discussion - fwd/ret file service

Dear CCSDS ”Special topic” Colleagues,
Today we held a special Working Meeting to discuss some issues that came 
up in the context of the SCCS-ARD, specifically the forward / return file 
service and how we can understand (and document) both what was requested 
of CCSDS by the IOAG and what has currently been proposed.    What follows 
are the DRAFT set of minutes for that meeting.  Your feedback, edits, and 
corrections are solicited.  By CoB, Friday, 22 Jan 21 please.
Attendees: Keith Scott, Costin Radulescu, Colin Haddow, Ramon Krosley, 
Greg Kazz, Jonathan Wilmot, Holger Dreihahn, Gian Paolo Calzolari, John 
Pietras, Yonghui Huang
The discussion was wide-ranging and covered the following list of possible 
1.      CFDP deployed end-to-end, as intended in the CFDP standard, where 
the CFDP entity is in the MOC and the MOC communicates with the ESLT using 
standard SLE interfaces.  The S/C implements CFDP Class 1 or 2.  This is 
an existing, documented, standardized, CCSDS deployment.
2.      The “original” IOAG proposal for a forward/return file service 
that involved transferring files from the User (EUN, MOC) to the ESLT ( 
ground station / comm complex) and having the ESLT send them via a CFDP 
entity in the ESLT to the S/C (SUN).  The general agreement is that there 
are many aspects of this that are vague and ill-specified.  The S/C 
implements CFDP Class 1 or 2.  See Colin’s diagram.  The intent in CCSDS 
has been to use TGFT for the file transport between the user MOC and the 
ESLT.  There is not yet a spec for the TGFT meta-data nor for the ESLT 
processing that is required.
3.      There is also an IOAG fwd/ret “Packet” service that was not really 
4.      A variant of “standard” CFDP, option 1, as proposed by ESA only 
for downlink optimization, that deploys CFDP in the MOC (EUN), and 
potentially in a separate MOC “control node”, that uses standard SLE 
interfaces for transport of command and telemetry frames, but that also 
adds a new CFDP buffering and management feature in the ESLT that examines 
arriving frames, looks for the CFDP PDUs in the selected virtual channels, 
identified missing PDUs, send notices of the missing data to the “CFDP 
Control node” which generates retransmission requests, and send the full 
CFDP PDU set, more slowly, to the full CFDP node in the MOC.  The S/C 
implements CFDP Class 1 or 2.  See Holger’s diagram.
I think that is not what we intended to describe. For the Purpose of 
donwlink only the ESLT has a CFDP entity reconstructing the files. The MOC 
just 'relays' the CFDP PDUs sent from the to  ESLT. See updated sled 3.
5.      A variant of the “ESA downlink optimizer”, option 4, that also 
supports downlink returns from low Earth S/C using multiple ESLTs and 
aggregates and synchronizes all of the data in the “full CFDP node” in the 
MOC.  There appears to be even another variant of this for the use case 
where the file data is sent not to the S/C MOC but to a separate 
instrument MOC.  The S/C implements CFDP Class 1 or 2.  See Holger’s 
diagram, with mods. Only CFDP C2.
6.      The DTN case, using CFDP Class 1 or Class 2 over DTN to provide 
all of the end-to-end reliability, routing, store & forward, and data 
delivery processing. The S/C implements CFDP Class 1 or 2 over DTN.  The 
ESLT implements DTN (with the FF-CSTS and frame merging options) and the 
MOC implement CFDP Class 1 or 2 over DTN.  This is an existing, 
documented, standardized, CCSDS deployment.
There were some items that everyone present could agree upon:
1.      Options 1 and 6 are what is currently documented and standardized.
2.      Everyone agreed that the desired end-point for CCSDS 
standardization, and for mission deployment is DTN and CFDP (or other 
protocols) running over that.
3.      Everyone agreed that for DTN deployments there will still need to 
be what was called “essential command, telemetry, and radiometric” 
communications, that these would continue to use SLE & CSTS for cross 
support, and that the new, not yet standardized, Last Hop and First Hop 
services are an essential part of these deployments.
4.      Everyone agreed that option 2, the IOAG proposal is accurately 
reflected in Colin’s original diagram.
5.      Everyone agreed that the option 2 diagram leaves a lot of room for 
6.      Everyone agreed that we should return to the IOAG and ask for the 
needed clarification (or provide that and ask if they concur).
Other observations where there was general agreement, but possibly not 
full concurrence (TBD).
1.      It has been noted that many missions (MOC) still want to control, 
at a micro level, everything that is sent on the command link to their 
spacecraft.  This means that option 1 can be acceptable, but that option 2 
often gets “push-back”.  And this is one of the strong motivations for 
options 4 & 5.
2.      There is general agreement that there are many aspects of option 2 
that are vague and ill-specified.  It seems clear that the fwd/ret file 
service, the meta-data, and the ESLT processing functions must be more 
clearly specified.
3.      There is general agreement that some sort of more explicit concept 
diagrams, such as were provided for the IOAG SISG first hop/last hop 
service, are needed to really document, even conceptually, what is 
required for any of these new services.
4.      There is a broad understanding that for a class of low Earth 
missions, with short passes, and limited terrestrial bandwidth relative to 
high rate downlinks, that ACK/NAK traffic should be prioritized relative 
to bulk data.  This, and mission control of the uplink (observation 1) 
leads to the motivations for options 4 & 5.
5.      There is a strong NASA concern that having CCSDS adopt and 
standardize any of these more exotic “CFDP variants” or “file services” 
may have the effect of de-legitimizing DTN in the eyes of potential users 
and of further slowing adoption of DTN. 
6.      None of these options, except DTN, provides a networking service, 
all are “hacks” shouldn't we change that word? to provide variations on 
ABA file delivery.
7.      NOTE: It occurs to  me that, in addition to protocol stacks, one 
way to approach any of this functional specification is to attempt to  use 
a Functional Resource Model (FRM) style approach to document which 
functions are executed and where they are deployed.  This should also help 
flush out any new, required, functions that are not yet specified in the 
Other general observations for further discussion:
1.      ESA has prototyped an “option 4 (&5)” approach for low Earth orbit 
missions with high rate downlinks.
2.      The DSN and ESA have an operational “option 4” approach that is 
documented and in use for some missions.
3.      Some missions are operating in “option 1” configurations now, with 
reliable CFDP for downlink and now some uplink.
4.      The ESA approach, and the DSN approach for that matter, could each 
be documented as Orange Books.  These still involve a lot of the CCSDS 
machinery and may not be the best strategic choice for CCSDS to adopt.
5.      Even the IOAG requested Option 2 is questionable, for the same 
reasons.  Developing this new protocol takes resources and there may not 
actually be users for it given Observation 1 & 2.
6.      The IOAG is not really the source of requirements for CCSDS.  It 
is one of the stakeholders, which also include broader agency 
requirements, space missions, infrastructure providers, space  data user 
organizations, and CCSDS internally generated requirements.  The IOAG is 
stated to be “to be a very important source of multiagency cross-support 
requirements”, but it is not the only one.
7.      We do not know which missions want any of these options.
Future work:
1.      Provide revised versions of these potential approaches for review
2.      Review them within CCSDS and then with the IOAG (TBD)
3.      Reach some agreement within CCSDS on what strategic choices we 
wish to make and which of these approaches, if any, should get CCSDS 
Once I have your feedback items I’ll incorporate them and send out a final 
set of minutes to the rest of the invitees and the full CESG.
Thanks, Peter

From: SEA-SA <sea-sa-bounces at mailman.ccsds.org> on behalf of SEA-SA 
<sea-sa at mailman.ccsds.org>
Reply-To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Date: Tuesday, January 12, 2021 at 5:33 PM
To: 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] [Sea-sa] Special Working Meeting: SCCS-ARD discussion 
- fwd/ret file service
This special working meeting is to explore 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. 
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). 
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. 
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. There is also the related question of whether 
this rather narrow standard is a good use of CCSDS resources instead of 
adopting CFDP over DTN, which has broader applicability and already would 
provide the same functionality, and much more. 
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. 
Proposed agenda: 
CSS Position on the service 
ESLT architecture 
CFDP agent integration in the ESLT 
CFDP signaling changes 
Split data delivery approach 
Fwd / ret signaling approach 
ESLT control approach for configuring and managing creation / processing 
of CFDP, encap, frame creation, encode/decode in the ELST 
SIS Position on the service 
ESLT architecture 
DTN agent integration in the ESLT 
Split data delivery approach 
Fwd / ret signaling approach (if needed) 
ESLT control approach for configuring and managing creation / processing 
of DTN bundles, encap, frame creation, encode/decode in the ELST 
CFDP end-to-end flow 
Thanks, Peter 

Peter Shames invites you to join this WebEx meeting. 


SCCS-ARD discussion - fwd/ret file service 
Wednesday, January 20, 2021 
7:00 am | (UTC-08:00) Pacific Time (US & Canada) | 2 hrs 

Meeting number (access code): 199 651 5303 

Meeting password: Nm5mpcrZ2r4 



Join meeting 


More ways to join: 
Join from the meeting link 


Join by phone 
+1-510-210-8882 USA Toll 
+44-203-457-5798 U.K. Toll 
Global call-in numbers 



Local: 818-35(4-4044) 
Toll Free: 844-JPL-WEBX (844-575-9329) 

Can't join the meeting? 


IMPORTANT NOTICE: Please note that this Webex service allows audio and 
other information sent during the session to be recorded, which may be 
discoverable in a legal matter. By joining this session, you automatically 
consent to such recordings. If you do not consent to being recorded, 
discuss your concerns with the host or do not join the session. 
_______________________________________________ SEA-SA mailing list 
SEA-SA at mailman.ccsds.org 
[attachment "Dreihahn 922x4r1-white 20Jan21-SEA.pptx" deleted by Holger 
Dreihahn/esoc/ESA] [attachment "Haddow IOAG File Services 
20Jan21-SEA.pptx" 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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210201/c856962b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Dreihahn 922x4r1-white 20Jan21-SEA-HD.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 98191 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210201/c856962b/attachment-0001.pptx>

More information about the SEA-SA mailing list