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

Thu Jan 7 18:59:51 UTC 2021

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:

  1.  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.
  2.  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.
  3.  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).
  4.  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.
  5.  This also requires some as yet unrecognized protocol that will allow the CFDP agent in the ESLT to send these “control reports”.
  6.  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.
  7.  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.

  1.  The returned “control report” from the CFDP agent in the ESLT to the EUN may need to have a whole new protocol defined, TBD.
  2.  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.
  3.  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.
  4.  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.
  5.  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.
  6.  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.
  7.  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.
  8.  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210107/9ae340bc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SISG Last Hop delivery v5.2a 25May10.ppt
Type: application/vnd.ms-powerpoint
Size: 1204736 bytes
Desc: SISG Last Hop delivery v5.2a 25May10.ppt
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210107/9ae340bc/attachment-0002.ppt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SISG ADD NW Mgmt Last Hop figures v0.2 17Oct11.ppt
Type: application/vnd.ms-powerpoint
Size: 403456 bytes
Desc: SISG ADD NW Mgmt Last Hop figures v0.2 17Oct11.ppt
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210107/9ae340bc/attachment-0003.ppt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fig 6-20 Fwd File Svc ESLT & EUN.jpeg
Type: image/jpeg
Size: 145640 bytes
Desc: Fig 6-20 Fwd File Svc ESLT & EUN.jpeg
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210107/9ae340bc/attachment-0002.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fig 7-2 SSI fwd end-to-end.jpeg
Type: image/jpeg
Size: 243561 bytes
Desc: Fig 7-2 SSI fwd end-to-end.jpeg
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210107/9ae340bc/attachment-0003.jpeg>