<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:89084809;
mso-list-template-ids:-254257300;}
@list l1
{mso-list-id:524246903;
mso-list-template-ids:989614306;}
@list l2
{mso-list-id:910432655;
mso-list-type:hybrid;
mso-list-template-ids:-1733767962 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level1 lfo2
{mso-level-start-at:2;}
@list l0:level1 lfo3
{mso-level-start-at:3;}
@list l0:level1 lfo4
{mso-level-start-at:4;}
@list l0:level1 lfo5
{mso-level-start-at:5;}
@list l0:level1 lfo6
{mso-level-start-at:6;}
@list l0:level1 lfo7
{mso-level-start-at:7;}
@list l1:level1 lfo9
{mso-level-start-at:2;}
@list l1:level1 lfo10
{mso-level-start-at:3;}
@list l1:level1 lfo11
{mso-level-start-at:4;}
@list l1:level1 lfo12
{mso-level-start-at:5;}
@list l1:level1 lfo13
{mso-level-start-at:6;}
@list l1:level1 lfo14
{mso-level-start-at:7;}
@list l1:level1 lfo15
{mso-level-start-at:8;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi Holger,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for that clarification. I did assume that you meant CFDP Class 2, reliable mode, delivery. I suspect we all did because otherwise there would not be a need to provide feedback and control between the EUN and the ESLT running CFDP.
Class 1 CFDP is more or less a “fire and forget” approach, you either get it or you don’t. (Or you invent some non-standard way to do retransmissions... we have examples of this too.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It seems that we are finally starting to deploy CFDP Class 2 into operations. That is, in itself, really good news since we have all been using a variety of “cooked up” file delivery alternatives for many years now. Given that CFDP was
first published in 2002 I believe we would all have to say “about time!!!”. I’m not pointing fingers here, JPL is as guilty as any space center of being behind the curve. We (JPL) are only now designing in use of full CFDP Class 2 on a flagship mission.
That mission, which I worked on directly, is using CFDP in the EUN and just using F-CLTU and R-AF to the ESLTs (primarily DSN with ESTRACK as backup).
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Here too the mission team wants to control the retransmissions, but that is mostly envisioned as being able to cancel incomplete transactions that are no longer a priorty. Normal retransmissions are envisioned as operating in a more automated
mode just to reduce the load on operators. That said, different missions have different requirements, and that is why we have so many options.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In your note you say:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">“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”</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As I pointed out in my note, when we looked at this in detail it appears that there are really three new service protocols that are needed, plus some other new functions:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo16">The forward and return File Delivery Service to send complete files to / from the ESLT by the EUN<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo16">A new
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">CSTS Return CFDP PDU service to send CFDP PDUs (ACK/NAK) from the ESLT to the EUN</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo16"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">A new CSTS Forward CFDP PDU service to send “flight control team approved” ACK/NAK traffic back to the ESLT from the
EUN</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo16">Plus a new CFDP PDU encap, frame creation, and frame merge function in the ESLT<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo16">Relative to that past phrase, please do not forget that the SLE F-CLTU is a service that only permits one user source, so it has no hooks for this sort of frame merging (FF-CSTS,
by design, does include this feature). There is no “F-CLTU” feature that “does the job” in the standard implementation as specified.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The even more complicated “<span style="font-size:10.0pt;font-family:"Arial",sans-serif">transfer files from the spacecraft over several ESLTs to a central location on ground (payload processing)” only adds to the complexity. Of course,
something like CFDP Class 3 or 4 could have been used, but these options have been deprecated in the latest update, in favor of using CFDP over DTN. So that would be yet another new protocol, but apparently that is not something you wish to standardize.
Or is it?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">It must be stated that I am trying to look at this from the point of view of what we need to document for CCSDS as recommendations to all agencies. From the outset the intent
in CCSDS, and in the SCCS, has been to try and provide guidance to all agencies who wish to implement and deploy systems that use some large parts of the suite of CCSDS standards. CCSDS has traditionally developed standards with a lot of options that missions,
and agencies, can tailor. I will note that we have a lot of “you can do this, but you can’t do that” built into some of our offerings. Describing this was a challenge 10 years ago, it is even more so now.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">From a mission, or an agency, point of view creating some specialized services and deployments may make a lot of sense. All three of the NASA networks have their own variations
on how they provision and offer SLE and CFDP. This will surely be the case with DTN as well as this is rolled out. I am sure that other agencies will have their own variants on deployment approaches. The challenge for us in CCSDS is to come up with approaches
that can be deployed for cross support and interoperability, AND that will be widely adopted.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Please note that I’m not saying “do not do this”, that is a mission and agency choice. But after looking at the complexity of what seems to be needed to make this particular
“corner case” work, several of us are left wondering if this is something that should be an internationally recommended standard, or if it is really a local optimization for a certain class of mission and operations approach. Viewed through this lens it looks
like this is going to need a whole lot of “plumbing” to deal with this one optimization.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">I think that a question CCSDS must ask is “Should we expend effort to create and document this optimization instead of a more global solution that will carry us further into
the future?”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">I’m just posing the question. It is ultimately up to the WGs, Areas, and agencies to decide priorities.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Thanks, Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">"Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int><br>
<b>Date: </b>Tuesday, January 12, 2021 at 11:49 PM<br>
<b>To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><br>
<b>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><br>
<b>Subject: </b>Re: [EXTERNAL] Re: Request for a special working meeting on some key Cross Support architecture document issues<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Dear Peter,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">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.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">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.</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I hope that clarifies some aspects.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Best regards,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Holger</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | H-293<br>
+49 6151 90 2233 | </span><a href="https://urldefense.us/v3/__http:/www.esa.int/esoc__;!!PvBDto6Hs4WbVuu7!coZrEEbCsSdvyqzNeTpiSUJJJ_fab8I2atkUrPCr7Ny3RsX3J0SWGw3DJ9e2jGC2zdnjBjzx$"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">http://www.esa.int/esoc</span></a>
<br>
<br>
<br>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">"Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc: </span><span style="font-size:7.5pt;font-family:"Arial",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>, "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></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">11/01/2021 23:51</span>
<br>
<span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"Arial",sans-serif">Re: [EXTERNAL] Re: Request for a special working meeting on some key Cross Support architecture document
issues</span> <o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal"><br>
<br>
<br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">Dear Holger,</span>
<br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">Thanks for the reply re what you are contemplating. It helps to offer an understanding of what you have been thinking about.</span>
<br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.</span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.</span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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?</span>
<br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">Thanks, Peter</span>
<br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span> <br>
<b><span style="font-size:12.0pt;font-family:"Arial",sans-serif">From: </span></b><span style="font-size:12.0pt;font-family:"Arial",sans-serif">"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</span>
<br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"> </span> <br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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 | </span><a href="https://urldefense.us/v3/__http:/www.esa.int/esoc__;!!PvBDto6Hs4WbVuu7!cJsRPsli-tBkSSqasuAM5DVQCgkvU90ZKmySQ2ydkhPH3PQLZzMEN7DE5pUhhsIb-p34mzZV$"><span style="font-size:12.0pt;font-family:"Arial",sans-serif">http://www.esa.int/esoc</span></a><span style="font-size:12.0pt;font-family:"Arial",sans-serif">
<br>
<br>
<br>
<span style="color:#5F5F5F"><br>
From: </span>"Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov> <span style="color:#5F5F5F">
<br>
To: </span>"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>
<span style="color:#5F5F5F"><br>
Cc: </span>"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>
<span style="color:#5F5F5F"><br>
Date: </span>07/01/2021 20:00 <span style="color:#5F5F5F"><br>
Subject: </span>Request for a special working meeting on some key Cross Support architecture document issues
</span><o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal"><br>
<span style="font-size:12.0pt;font-family:"Arial",sans-serif"><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:
</span><o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.
</span><o:p></o:p></li></ol>
<ol start="2" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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. </span><o:p></o:p></li></ol>
<ol start="3" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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).
</span><o:p></o:p></li></ol>
<ol start="4" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo4">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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. </span><o:p></o:p></li></ol>
<ol start="5" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo5">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">This also requires some as yet unrecognized protocol that will allow the CFDP agent in the ESLT to send these “control reports”.
</span><o:p></o:p></li></ol>
<ol start="6" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo6">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.
</span><o:p></o:p></li></ol>
<ol start="7" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo7">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.</span><o:p></o:p></li></ol>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif">
<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>
</span> <o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo8">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">The returned “control report” from the CFDP agent in the ESLT to the EUN may need to have a whole new protocol defined, TBD.
</span><o:p></o:p></li></ol>
<ol start="2" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo9">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.
</span><o:p></o:p></li></ol>
<ol start="3" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo10">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.
</span><o:p></o:p></li></ol>
<ol start="4" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo11">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.
</span><o:p></o:p></li></ol>
<ol start="5" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo12">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.
</span><o:p></o:p></li></ol>
<ol start="6" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo13">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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. </span><o:p></o:p></li></ol>
<ol start="7" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo14">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.
</span><o:p></o:p></li></ol>
<ol start="8" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo15">
<span style="font-size:12.0pt;font-family:"Arial",sans-serif">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.</span><o:p></o:p></li></ol>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;font-family:"Arial",sans-serif">
<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]
</span><br>
<span style="font-size:12.0pt;font-family:"Courier New"">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or</span>
<br>
<span style="font-size:12.0pt;font-family:"Courier New"">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received</span>
<br>
<span style="font-size:12.0pt;font-family:"Courier New"">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect</span>
<br>
<span style="font-size:12.0pt;font-family:"Courier New"">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).</span>
<o:p></o:p></p>
<pre>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<o:p></o:p></pre>
<pre>protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<o:p></o:p></pre>
<pre>this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<o:p></o:p></pre>
<pre>personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).<o:p></o:p></pre>
</div>
</body>
</html>