[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
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
Options:
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
discussed.
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
interpretation.
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
FRM.
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
resources
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
Discussion
Thanks, Peter
Hello,
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
https://jpl.webex.com/jpl/j.php?MTID=mda4b7e12e1b6f08131813d6abe9cbeba
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
https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa__;!!PvBDto6Hs4WbVuu7!em2PSzY-3YgmNhBZ8GMbajfe4GnHfKMIzo8_su4UM0G_XfgUbH_cn2aT8vyuZnDEboLdxLum$
[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