<html 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)">
<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;}
/* 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:#0563C1;
text-decoration:underline;}
span.EmailStyle19
{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;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi John, at al,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for your diligence in keeping this ball rolling. I hope you had time over the holidays to do more than hack at this, but want you to know that your work is appreciated.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I looked over the materials yesterday and I have a few items of feedback. We’ll discuss this all tomorrow (that seems to be how the key centroid votes are going) but I wanted to give you an early view of the “rub points”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Pg 4: Sec 4 services approach, I think I agree, with some caveats TBA<o:p></o:p></p>
<p class="MsoNormal">Pg 4: Services are specifically the exposed and published interfaces of systems used for interoperability and cross support. They have interface binding signatures which are the stack of protocols that implement the interoperable interface.<o:p></o:p></p>
<p class="MsoNormal">Pg 4: Table 5-4 approach seems to be a good one, with some caveats TBA<o:p></o:p></p>
<p class="MsoNormal">Pg 6: New Table 6-4, I would split out the SLE/CSTS services from those CFDP file services, they are quite different kinds of beasts<o:p></o:p></p>
<p class="MsoNormal">Pg 6: Table 6-4, what is “ISP-1”? Is this the SLE over TCP/IP spec? Since we have no other bindings that is rather a sine-qua-non, and is essentially a part of the interface binding signature for all of those services SLE & CSTS.<o:p></o:p></p>
<p class="MsoNormal">Pg 8: New Table 6-6 is complicated, with a bunch of “if this, not that, never something else”, but it may be the best way to address the rather complicated SM/SC/MD/Nav/D-DOR set of interfaces we have constructed.
<o:p></o:p></p>
<p class="MsoNormal">Pg 11: New Table 6-7 is even more of a “hot mess” than new Table 6-6. Again, this is very complicated territory, and you have tried to bring reason to it. I would, however, do it differently in the following ways: move the CFDP stuff
to a separate table, as suggested in Table 6-4. Treat DVB and SCCC as being fundamentally different from TM & TC S&CC, especially since they a) stand alone, b include their own modulation, c) have a different physical synch layer.<o:p></o:p></p>
<p class="MsoNormal">Pg 14: The whole issue of whether fwd-file can exist in the absence of SLE or CSTS is going to have to be wrestled to the ground. Two reasons: a) I cannot imagine that any S/C MOS would accept an interface where they couldn’t directly
command, get telemetry, and get radiometric data; b) without all of the “production plumbing”, which really is not defined in the absence of SLE & CSTS there is no production to wire the CFDP file service into. More on this later.<o:p></o:p></p>
<p class="MsoNormal">Pg 16: and following: I get where you are coming from, but I think this creates at least as large a problem as does how I drew these diagrams in the first place. It may be, for instance, on pg 18, that FF-CSTS does not “include frame muxing”
in the production spec. Neither is this function defined anywhere else in these SLE & CSTS services, and hence we have a problem. Muxing is described in the link layer protocol books as flows that are accommodated within the protocol, and as functions that
the protocol “services” must provide at the protocol layer “SAP”. But for FF-CSTS we have PDUs (or CADUs) being sent from one set of (external to the ESLT) users and PDUs created in the ESLT being merged into the frame stream. This is how FF-CSTS has been
defined since it was conceived. If FF-CSTS does not define its services in this way then it is either wrong, or we need to define a new, ESLT internal, service that can be used as a building block to create these flows. I am sure that the FRM has the basic
abstract components, but can we point to where these are realized in actual service or protocol specs?<o:p></o:p></p>
<p class="MsoNormal">Pg 19: same issues as for pg 16. I do not see how we can just stick a “VC & MC Mux” function into a stack. It is really a feature defined in the data link protocol layer, but in this case it is happening in the ESLT and it must, by definition,
be merging a stream of PDUs or CADUs from the Earth User Node with the stream created within the ESLT itself.<o:p></o:p></p>
<p class="MsoNormal">Pg 22: There is the same issue as noted for Pg 16 & 19 here as well. That Mux function must be defined somewhere. And there is also the whole issue noted for Pg 14 as to whether these file transfer functions really can be shown separate
from the SLE and CSTS production plumbing”. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What I chose to do in the diagrams I drew was to hide all of the grimy “plumbing” details inside those pink ovals, like the SLE RCF and CSTS F-Frame “processing” ones on pg 23. This was intentional, since what I wanted to focus on in
Sec 6 was the protocol stacks. These pink “processing” ovals really include both the SLE and CSTS provisioning and the production. I still think that approach is a useful one, but am willing to be convinced otherwise as long as the other issues you and I
have raised are dealt with.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That said, it does occur to me that one way of putting this to bed, and tying it into the FRM, is to add a subsection of Chap 6 that addresses this topic head-on,
<b><i>and</i></b> provides an explicit tie-in to the new FRM spec. As I recall the FRM does have all of these piece-parts that can be “building-blocked” to describe what is inside any of these pink ovals. I think we can make the words in Sec 6 state what
occurs inside these “processing” functions and add a subsection that provides a specific example, or two, of how the FRM supports this in detail. Presumably you will have all of the grimy “provision/production plumbing” details in the new FRM MB, right?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Pg 25: I want to avoid any sort of circumlocutions like “ABA service user service”, I’d much prefer just “ABA Service User”. IMHO it is simpler and clearer. For ABAs only the ESLT is treated as a service provider and the EUN as a service
user. This relates back to the comment on Pg 4 “Services are specifically the exposed and published interfaces of systems used for interoperability and cross support.” There is probably a long philosophical discussion buried in here about why we do not treat
SUNs as “Service Users”, or even, in the case of some ad hoc, “relay service” ABA SUNs why we do not treat them as “Service Providers”.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There is clearly a stack of protocols exposed at the interface of an SUN that has to match the stack of protocols visible on the space interface of an ESLT. I suppose we could even call this an “interface binding signature”. But I do
not think that this is a “Service Interface” because of the nature of the way that we craft the actual command streams and telemetry data streams that run
<b><i>over</i></b> those protocol stacks. This would be the “moral equivalent” of an SLE service, or a CSTS service, but there is no such regular “service protocol” that is in use. Rather it is whatever mix of hardware commands, command packets and/or codes,
telemetry data in frames, or in packets, or in “files”, or “files of frames” that each mission chooses to transmit over the space link. “Interoperability”, even for ABA missions that do offer some sort of “relay service” is similarly catch as catch can.
I do not think we should treat these as “services”. However, when we do get to SSI configurations, where there are defined relay / store&forward protocols, and related services, I think it is completely appropriate to treat these as interoperable services.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I hope that this makes sense to everyone.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, Peter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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">SEA-SA <sea-sa-bounces@mailman.ccsds.org> on behalf of John Pietras <john.pietras@gst.com><br>
<b>Date: </b>Tuesday, December 29, 2020 at 3:57 PM<br>
<b>To: </b>SEA-SA <sea-sa@mailman.ccsds.org><br>
<b>Subject: </b>[EXTERNAL] [Sea-sa] Briefing materials for next Monday's SCCS-ARD telecon<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">SEA-SAWG colleagues ---<o:p></o:p></p>
<p class="MsoNormal">I have uploaded to the CWE a Powerpoint presentation containing the material that I proposed to present and discuss at next Monday’s SCCS-ARD telecon. It is in the SCCS-ARD Working Meeting Minutes folder that Peter established:<o:p></o:p></p>
<p class="MsoNormal"><a href="https://urldefense.us/v3/__https:/cwe.ccsds.org/sea/docs/SEA-SA/Draft*20Documents/SCCS-ARD-ADD*20Revisions*202020/SCCS-ARD*20Working*20Meeting*20Minutes/SCCS-ARD_Update-210104.pptx?d=w3f2f270f4da847eda40346a379de7d7f__;JSUlJSUl!!PvBDto6Hs4WbVuu7!b0D1_AwWtYrOKskVRJ9o381eUl9ND0lgvtRpLELRWu3fFFG9HzCIgAgOqstDo7B91pf1VAp7$">https://cwe.ccsds.org/sea/docs/SEA-SA/Draft%20Documents/SCCS-ARD-ADD%20Revisions%202020/SCCS-ARD%20Working%20Meeting%20Minutes/SCCS-ARD_Update-210104.pptx?d=w3f2f270f4da847eda40346a379de7d7f</a><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">The bulk of the presentation addresses the approach that we discussed in our December telecon whereby the specification of the relationships among the services and the protocols that support them would be more fully documented in section
6, in order to allow the specifications in sections 4 and 5 to be simplified. The presentation also carries over a topic that we didn’t have time to discuss in December, and adds a new issue regarding the absence of ABA Space User Node requirements in section
4.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Best wished for the new year!<o:p></o:p></p>
<p class="MsoNormal">John<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</body>
</html>