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

Thu Jan 21 00:43:38 UTC 2021

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.
  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.
  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 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” 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 has 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<https://jpl.webex.com/jpl/j.php?MTID=mda4b7e12e1b6f08131813d6abe9cbeba>

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<https://jpl.webex.com/jpl/globalcallin.php?MTID=m91ef44b98d71197e079bc4e234fbe055>

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$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210121/b4c8bc29/attachment-0001.htm>