<font size=2 face="sans-serif">Dear Keith and Peter,</font>
<br><font size=2 face="sans-serif">I think for DTN and it's technical applicability,
we are all on the same page. The matter for us is that ESA's next generation
of satellites will implement CFDP Class 2 and we see no way to get CFDP
C1 over BP over LTP 'on-board'. As such I was presenting an architecture,
which is from a satellite point of view 'pure' CFDP Class 2, but the CFDP
Class 2 implementation on ground is distributed over several places, basically
to address a number of requirements and operational constraints as outlined
below. To make this on-ground CFDP Class 2 distribution inter operable,
and we believe we can use a external (commercial) ground station services
within that architecture, we have proposed, drafted and tested one (relatively
simple) additional service: The CSTS CFDP Return PDU Service. </font>
<br>
<br><font size=2 face="sans-serif">However, as Keith says Peter has a different
starting point (Fwd/Rtn File Service) and I was just presenting what we
have discussed in ESA for a CFDP Class 2 scenario because I saw similarities.
That should have served as input for the discussion of the meeting on the
20th, that's all.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br><font size=2 face="sans-serif">Holger</font>
<br>
<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">"Dr. Keith L Scott"
<kscott@mitre.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int>, "Shames, Peter M (US 312B)"
<peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"Barkley, Erik
J (US 3970)" <erik.j.barkley@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>,
"Klaus-Juergen Schulz" <Klaus-Juergen.Schulz@esa.int>,
"Sanchez Net, Marc (US 332H)" <marc.sanchez.net@jpl.nasa.gov>,
"Margherita.di.Giulio@esa.int" <Margherita.di.Giulio@esa.int>,
"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>,
"SEA-SA" <sea-sa@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">14/01/2021 15:35</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [EXTERNAL]
Re: 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">I think the issues Peter mentions in the
original email are all the result of taking a hard look at the ‘easy’
problem of writing a TGFT-to-CFDP gateway, and they’ll recur for <b><i>every
application</i></b> we want to run between the ESLT and SUN (e.g. messaging,
…)</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">I think an end-to-end CFDP/DTN solution
is much cleaner (fewer protocols, no application-specific gateways) and
could still meet the requirements Holger mentions:</font>
<ul>
<li><font size=3 face="Calibri">If you have to run CFDP class-2, run it
over DTN (it’ll be inefficient but it’ll work) As Scott mentioned,
CFDP class-1 over BP would be better.</font>
<li><font size=3 face="Calibri">If you have to control every bit that is
sent up to the spacecraft, route the DTN bundles (e.g. including those
that contain CFDP PDUs) via the EUT and write software THERE that allows
operators to inspect/pass/deny/modify them (this is code that doesn’t
exist yet but that I argue is much simpler than a TFGT-to-CFDP gateway)
and go ahead and build the CLTUs there if you like.</font>
<li><font size=3 face="Calibri">Bonus: works transparently (to CFDP) when
the transfer is split among several ESLTs</font></ul><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">I get that DTN isn’t deployed yet, but
the seems to be to develop new protocols / applications and to deploy THEM
– is that really easier than deploying DTN?</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">
V/r.</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri">
--keith</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Calibri"><b>From: </b>"Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int><b><br>
Date: </b>Wednesday, January 13, 2021 at 2:51 AM<b><br>
To: </b>"Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov><b><br>
Cc: </b>Eric Barkley <erik.j.barkley@jpl.nasa.gov>, Gian-Paolo Calzolari
<Gian.Paolo.Calzolari@esa.int>, Moury Gilles <Gilles.Moury@cnes.fr>,
Greg Kazz <greg.j.kazz@jpl.nasa.gov>, Jonathan Wilmot <jonathan.j.wilmot@nasa.gov>,
"Klaus-Juergen. Schulz" <Klaus-Juergen.Schulz@esa.int>,
Keith Scott <kscott@mitre.org>, "Sanchez Net, Marc (US 332H)"
<marc.sanchez.net@jpl.nasa.gov>, "Margherita.di.Giulio@esa.int"
<Margherita.di.Giulio@esa.int>, Scott Burleigh <scott.c.burleigh@jpl.nasa.gov>,
SEA-SA <sea-sa@mailman.ccsds.org><b><br>
Subject: </b>Re: [EXTERNAL] Re: Request for a special working meeting on
some key Cross Support architecture document issues</font>
<br><font size=3 face="Calibri"> </font>
<br><font size=3 face="Arial">Dear Peter,</font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
When I talk about CFDP below, I mean CFDP class 2. DTN would of course
be the technically sound solution to a lot of problems and we would not
need to invent new services. However, in practice the adoption of CFDP
class two was apparently what was possible for the next generation of satellites.
On top of that, flight control teams often insist on being in control of
everything going up to the spacecraft, so we invented the CSTS Return CFDP
PDU service to relay CFDP PDUs (NAK etc.) from the ESLT to the EUN, where
the CFDP PDUs are merged into the CLTUs anyway sent from the EUN to the
ESLT and finally the spacecraft. At that point SLE CLTU does the job, although
it's clear that CSTS Forward Frame is needed for high rate uplinks, or
would allow closure of the CFDP class 2 protocol loop in the ESLT.</font><font size=3 face="Calibri">
<br>
</font><font size=3 face="Arial"><br>
The feature of the reduced CFDP PDUs we envisage for a more complicated
scenario: Here CFDP class 2 shall be used to transfer files from the spacecraft
over several ESLTs to a central location on ground (payload processing).
No BP involved unfortunately.</font><font size=3 face="Calibri"> <br>
</font><font size=3 face="Arial"><br>
I hope that clarifies some aspects.</font><font size=3 face="Calibri">
<br>
</font><font size=3 face="Arial"><br>
Best regards,</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
Holger</font><font size=3 face="Calibri"> <br>
</font><font size=3 face="Arial"><br>
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=3 color=blue face="Arial"><u>http://www.esa.int/esoc</u></font></a><font size=3 face="Calibri">
<br>
<br>
<br>
</font><font size=3 color=#5f5f5f face="Arial"><br>
From: </font><font size=3 face="Arial">"Shames,
Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov></font><font size=3 face="Calibri">
</font><font size=3 color=#5f5f5f face="Arial"><br>
To: </font><font size=3 face="Arial">"Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int></font><font size=3 face="Calibri"> </font><font size=3 color=#5f5f5f face="Arial"><br>
Cc: </font><font size=3 face="Arial">"Barkley,
Erik J (US 3970)" <erik.j.barkley@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>, "Klaus-Juergen Schulz" <Klaus-Juergen.Schulz@esa.int>,
"Keith Scott" <kscott@mitre.org>, "Sanchez Net, Marc
(US 332H)" <marc.sanchez.net@jpl.nasa.gov>, "Margherita.di.Giulio@esa.int"
<Margherita.di.Giulio@esa.int>, "Burleigh, Scott C (US 312B)"
<scott.c.burleigh@jpl.nasa.gov>, "SEA-SA" <sea-sa@mailman.ccsds.org></font><font size=3 face="Calibri">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Date: </font><font size=3 face="Arial">11/01/2021
23:51</font><font size=3 face="Calibri"> </font><font size=3 color=#5f5f5f face="Arial"><br>
Subject: </font><font size=3 face="Arial">Re:
[EXTERNAL] Re: Request for a special working meeting on some key Cross
Support architecture document issues</font><font size=3 face="Calibri">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Calibri"><br>
<br>
</font><font size=3 face="Arial"><br>
Dear Holger,</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
Thanks for the reply re what you are contemplating. It helps to offer
an understanding of what you have been thinking about.</font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
If I read this correctly we will still need to deploy the FF-CSTS in the
ESLT and to provide the necessary CFDP agent software and associated “plumbing”
to accommodate this insertion of functionality. And then we will
also need, on top of that, to define this new “CSTS Return CFDP PDU Service”,
to splice this “reduced CFDP File Data PDU delivery function” into the
CFDP agent, and also define how these new, specialized, “monitor” and
“control” interfaces are to work.</font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
This still looks like several (at least three) new protocols or adaptations
of services to accomplish something that “ought to be” simple. But
then, things are seldom as simple as we would like them to be.</font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
As a side question, was any sort of trade study done to evaluate the use
of DTN to accomplish this instead? That has the advantage, at least
from my point of view, of being an approach that moves us into a space
internetworking future, even as it brings its own complexities. Was
this even considered?</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
Thanks, Peter</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><b><br>
From: </b>"Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int><b><br>
Date: </b>Monday, January 11, 2021 at 1:21 AM<b><br>
To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>
Cc: </b>Erik Barkley <erik.j.barkley@jpl.nasa.gov>, Gian Paolo Calzolari
<Gian.Paolo.Calzolari@esa.int>, Gilles Moury <Gilles.Moury@cnes.fr>,
Greg Kazz <greg.j.kazz@jpl.nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)"
<jonathan.j.wilmot@nasa.gov>, Klaus-Juergen Schulz <Klaus-Juergen.Schulz@esa.int>,
Keith Scott <kscott@mitre.org>, Marc Sanchez Net <marc.sanchez.net@jpl.nasa.gov>,
"Margherita.di.Giulio@esa.int" <Margherita.di.Giulio@esa.int>,
Scott Burleigh <scott.c.burleigh@jpl.nasa.gov>, SEA-SA <sea-sa@mailman.ccsds.org><b><br>
Subject: </b>[EXTERNAL] Re: Request for a special working meeting on some
key Cross Support architecture document issues</font><font size=3 face="Calibri">
</font><font size=3 face="Arial"><br>
</font><font size=3 face="Calibri"> </font><font size=3 face="Arial"><br>
Dear Peter, <br>
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:
<br>
<br>
- 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,
<br>
- 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' <br>
- 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
<br>
<br>
Best regards, <br>
Holger <br>
<br>
Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | H-293<br>
+49 6151 90 2233 | </font><a href="https://urldefense.us/v3/__http:/www.esa.int/esoc__;!!PvBDto6Hs4WbVuu7!cJsRPsli-tBkSSqasuAM5DVQCgkvU90ZKmySQ2ydkhPH3PQLZzMEN7DE5pUhhsIb-p34mzZV$"><font size=3 color=blue face="Arial"><u>http://www.esa.int/esoc</u></font></a><font size=3 face="Arial">
<br>
<br>
</font><font size=3 color=#5f5f5f face="Arial"><br>
<br>
From: </font><font size=3 face="Arial">"Shames,
Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov> </font><font size=3 color=#5f5f5f face="Arial"><br>
To: </font><font size=3 face="Arial">"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><font size=3 color=#5f5f5f face="Arial"><br>
Cc: </font><font size=3 face="Arial">"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><font size=3 color=#5f5f5f face="Arial"><br>
Date: </font><font size=3 face="Arial">07/01/2021
20:00 </font><font size=3 color=#5f5f5f face="Arial"><br>
Subject: </font><font size=3 face="Arial">Request
for a special working meeting on some key Cross Support architecture document
issues </font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Arial"><br>
<br>
<br>
<br>
Dear CCSDS colleagues, <br>
<br>
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. <br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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="Arial">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="Arial">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="Arial">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="Arial">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="Arial">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="Arial">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="Arial">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="Arial"> <br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
In talking about this in the SAWG meeting on 6 Jan 21 the following questions
and observations came up. <br>
</font><font size=3 face="Calibri"> </font>
<ol>
<li value=1><font size=3 face="Arial">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="Arial">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="Arial">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="Arial">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="Arial">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="Arial">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="Arial">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="Arial">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="Arial">
<br>
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. <br>
<br>
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. <br>
<br>
Best regards, Peter <br>
<br>
<br>
[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><font size=3 face="Courier New"><br>
This message is intended only for the recipient(s) named above. It may
contain proprietary information and/or</font><font size=3 face="Calibri">
</font><font size=3 face="Courier New"><br>
protected content. Any unauthorised disclosure, use, retention or dissemination
is prohibited. If you have received</font><font size=3 face="Calibri">
</font><font size=3 face="Courier New"><br>
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect</font><font size=3 face="Calibri">
</font><font size=3 face="Courier New"><br>
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo@esa.int).</font><font size=3 face="Calibri">
</font>
<br><font size=3 face="Courier New">This message is intended only for the
recipient(s) named above. It may contain proprietary information and/or</font>
<br><font size=3 face="Courier New">protected content. Any unauthorised
disclosure, use, retention or dissemination is prohibited. If you have
received</font>
<br><font size=3 face="Courier New">this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures
to protect</font>
<br><font size=3 face="Courier New">personal data, in case of data privacy
queries, please contact the ESA Data Protection Officer (dpo@esa.int).</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>