<font size=2 face="sans-serif">Dear Peter,</font>
<br><font size=2 face="sans-serif">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:</font>
<br>
<br><font size=2 face="sans-serif">- 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,</font>
<br><font size=2 face="sans-serif">- 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'</font>
<br><font size=2 face="sans-serif">- 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</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br><font size=2 face="sans-serif">Holger </font>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | H-293<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">"Shames, Peter
M (US 312B)" <peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"Barkley, Erik
J (US 3970)" <erik.j.barkley@jpl.nasa.gov>, "Holger Dreihahn/esoc/ESA"
<Holger.Dreihahn@esa.int>, "Burleigh, Scott C (US 312B)"
<scott.c.burleigh@jpl.nasa.gov>, "Keith Scott" <kscott@mitre.org>,
"Sanchez Net, Marc (US 332H)" <marc.sanchez.net@jpl.nasa.gov>,
"Gian Paolo Calzolari" <Gian.Paolo.Calzolari@esa.int>,
"Gilles Moury" <Gilles.Moury@cnes.fr>, "Kazz, Greg
J (US 312B)" <greg.j.kazz@jpl.nasa.gov>, "Wilmot, Jonathan
J. (GSFC-5820)" <jonathan.j.wilmot@nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif">"SEA-SA"
<sea-sa@mailman.ccsds.org>, "Klaus-Juergen Schulz" <Klaus-Juergen.Schulz@esa.int>,
"Margherita.di.Giulio@esa.int" <Margherita.di.Giulio@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">07/01/2021 20:00</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Request for
a special working meeting on some key Cross Support architecture document
issues</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 face="Calibri">Dear CCSDS colleagues,</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">What I wish to focus on in this discussion
is a set of issues specifically related to the following topics:</font>
<ol>
<li value=1><font size=3 face="Calibri">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.</font>
<li value=2><font size=3 face="Calibri">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.</font>
<li value=3><font size=3 face="Calibri">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).</font>
<li value=4><font size=3 face="Calibri">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.</font>
<li value=5><font size=3 face="Calibri">This also requires some as yet
unrecognized protocol that will allow the CFDP agent in the ESLT to send
these “control reports”.</font>
<li value=6><font size=3 face="Calibri">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.</font>
<li value=7><font size=3 face="Calibri">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.</font></ol><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">In talking about this in the SAWG meeting
on 6 Jan 21 the following questions and observations came up.</font>
<br><font size=3 face="Calibri"> </font>
<ol>
<li value=1><font size=3 face="Calibri">The returned “control report”
from the CFDP agent in the ESLT to the EUN may need to have a whole new
protocol defined, TBD.</font>
<li value=2><font size=3 face="Calibri">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.</font>
<li value=3><font size=3 face="Calibri">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.</font>
<li value=4><font size=3 face="Calibri">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.</font>
<li value=5><font size=3 face="Calibri">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.
 </font>
<li value=6><font size=3 face="Calibri">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.</font>
<li value=7><font size=3 face="Calibri">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.</font>
<li value=8><font size=3 face="Calibri">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 <u>interfaces</u> 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 <u>behavior</u>
of those components and how we expect to connect them.</font></ol><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">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.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">Best regards, Peter</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"> [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]
</font>
<br>
<br> <PRE>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@esa.int).
</PRE>