<span style=" font-size:10pt;font-family:sans-serif">Dear Peter,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
can you please clarify what is the relationship between
the ESLT and the ground tracking asset mentioned by IOAG Catalogs?</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">In the CCSDS document
the definition for the Earth Space Link Terminal says:</span>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>Earth Space
Link Terminal (ESLT): The CSSE that provides space communication</i></span>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>services between
the Earth User Node and the Space User Node. It includes the ground</i></span>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>station control
and management systems. The ESLT has space link protocol interfaces and</i></span>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>supports terrestrial
SLE and CSTS interfaces. The ESLT also has a service management</i></span>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>interface that
is controlled by the UE that is responsible for managing the space link.</i></span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">In IOAG Catalogs
the ground tracking asset follows this definition:</span>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>Ground Tracking
Assets may be Ground Stations, Ground Data System or a combination of both.</i></span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I think it is
essential to state something about their coincidence and/or difference.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Is ESLT as a synonym
for ground station? or is ESLT a a synonym for ground tracking asset?</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Surely it makes
a big point for what you call the </span><span style=" font-size:11pt;font-family:Calibri"><infamous
IOAG “CFDP file delivery service”, and the even more ephemeral “IOAG
Packet file delivery service”</span><span style=" font-size:10pt;font-family:sans-serif">>.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Thanks</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Gippo</span>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Shames,
Peter M\(US 312B\) via SEA-SA" <sea-sa@mailman.ccsds.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"SEA-SA"
<sea-sa@mailman.ccsds.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">02-02-21
19:20</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">[Sea-sa]
DRAFT SCCS-ARD Revision Meeting Notes, 1 Feb 2021</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"SEA-SA"
<sea-sa-bounces@mailman.ccsds.org></span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>SCCS-ARD
Revision Meeting Notes, 1 Feb 2021</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><u>Attendees:
Peter Shames, John Pietras, Ramon Krosley, Costin Radulescu, Ricard Abello,
Holger Dreihahn</u></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<ul>
<li><span style=" font-size:11pt;font-family:Calibri">Reviewed the latest
“Issues” file that John Pietras presented including the intended fixes
for several identified issues.</span>
<li><span style=" font-size:11pt;font-family:Calibri">Specific issues were
identified for three sections of the document. These are covered
in the file and are just named here for reference, along with an decisions
made during discussion: </span>
<ul>
<li><span style=" font-size:11pt;font-family:Calibri">Sec 4: agreed to
add R-OCF to the other SLE services, for completeness. </span>
<ul>
<li><span style=" font-size:11pt;font-family:Calibri">Agreed to add a few
sentences to further clarify the means intended with [Future] standards
and also (recommended) notations</span>
<li><span style=" font-size:11pt;font-family:Calibri">Agreed to clarify
that ABA is intended to convey deployments that essentially use data link
layer frames as the top layer supported protocol, in the ESLT and end-to-end.
Further clarify that other protocols, CFDP, voice /video, and even
DTN Bundles MAY be carried end-to-end, but that the ESLT remains ignorant
of this “upper layer” traffic.</span>
<li><span style=" font-size:11pt;font-family:Calibri">Discussed that the
now infamous IOAG “CFDP file delivery service”, and the even more ephemeral
“IOAG Packet file delivery service” depart from this baseline and require
use of FF-CSTS (not SLE F-CLTU) and also other, upper layer, processing
to be provisioned in the ESLT. This is a distinct departure from
“traditional ABA ESLT” deployments.</span>
<li><span style=" font-size:11pt;font-family:Calibri">Agreed to change
references from RF & Mod to Physical Channel, so as to accommodate
both RF and Optical.</span></ul>
<li><span style=" font-size:11pt;font-family:Calibri">Sec 6: agreed to
use separate diagrams for the various protocol stacks, to simplify references
</span>
<ul>
<li><span style=" font-size:11pt;font-family:Calibri">Agreed to change
the form of the RQ stated in Sec 6 to focus on the visible top layer protocol
that is supported by the end-to-end ABA entities. This will be files,
packets, or frames, as well as ancillary data like ranging and D-DOR.</span>
<li><span style=" font-size:11pt;font-family:Calibri">Agreed to use those
complicated tables, and example diagrams, to document all of the viable
and supported configurations.</span>
<li><span style=" font-size:11pt;font-family:Calibri">Agreed to edit those
tables to more accurately reflect D-DOR, the D-DOR architecture, and DOR
tones.</span>
<li><span style=" font-size:11pt;font-family:Calibri">Agreed to check with
the D-DOR WG about their use of TGFT. It appears that a) they do
not use it, b) they use another, existing, high speed bulk transfer protocol,
and c) TGFT may not even support their bulk transfer needs anyhow since
it appears to depend on single stream, rather than parallel, transfers
over HTTPS and TLS.</span></ul>
<li><span style=" font-size:11pt;font-family:Calibri">Adopted other changes
to Sec 6 protocol tables as discussed. This includes handling of
SCCC and DVB coding and modulation, since they are distinct from the “mainline”
CCSDS coding, synch, and modulation standards. Peter provided a marked-up
set of proposed issues / updates.</span></ul>
<li><span style=" font-size:11pt;font-family:Calibri">During the meeting
we also discussed a couple of related topics, as follows: </span>
<ul>
<li><span style=" font-size:11pt;font-family:Calibri">There was discussion,
and agreement to not incorporate the “adapted CFDP File Delivery Service”,
which puts the CFDP agent into the ESLT, and also augments that with a
new kind of “lost segment signaling” and “retransmission request signaling”
between the CFDP agent in the ESLT and the Earth User Node (EUN).
This approach, which is non standard, will probably remain as a useful,
but agency local, adaptation.</span>
<li><span style=" font-size:11pt;font-family:Calibri">This subject is still
up to the CSS, and other areas involved, to try and reach some consensus
about just just what is proposed, or planned, for both the “IOAG CFDP
File Delivery Service” and this adaptation. Separate discussions
are underway. The “IOAG Packet Service” is even more vague and
it is not clear that any such service will be developed by CCSDS.</span>
<li><span style=" font-size:11pt;font-family:Calibri">The redundant sounding
appellation “service management service”, and the association of MD-CSTS
and SC-CSTS with Service Management document formats, and future interfaces,
was briefly discussed. The IOAG has associated these, and there
is a technical argument that can be made that these are all related, since
the SM sets the configurations and plans and schedules the contacts, and
MD and SC are used to monitor and control data transfer services during
the contact. MD-CSTS and SC-CSTS are clearly “service interfaces”
in the true sense of the definition. It will also be the case, once
there is a “service interface protocol binding” for SM that they will
be, in some sense, “service interfaces”. That said, I still find
that calling these “service management services” sounds wordy and redundant.
I would prefer that we keep the “service” appellation for those
interfaces that actually transport data of various types, separate from
those that <b><i>manage</i></b> service elements. This distinction
also shows up in RASDS, sec 3.4, “characteristics of objects” and is
shown in fig 3-2 as “management interfaces”. I think it is a useful
distinction to maintain, since the “data plane” and the “control plane”
are often distinguished in systems architectures.</span></ul>
<li><span style=" font-size:11pt;font-family:Calibri">Several other topics
remain from the earlier meetings: </span>
<ul>
<li><span style=" font-size:11pt;font-family:Calibri">Recognize that work
must be done to sort out the relationships between the CSS Functional Resource
Model (FRM), which was characterized as a database of knowledge about component
functions that get assembled to provide services, and the SOIS Electronic
Data Sheet (EDS), which was characterized as a way to document hardware
and software component interfaces so as to facilitate development of software
for those interfaces. </span>
<li><span style=" font-size:11pt;font-family:Calibri">Recognize that work
must be done to disambiguate the different ‘flavors” of “service”:
as in CSS services, arbitrary “application services” like packet transfer
without formal application layer protocols, protocol layer Service Access
Points (SAP), SM&C “Services”, service interface binding signatures,
and the related protocol stacks that implement service transfers. Focus
is to be on services, protocols, and interfaces and not on implementations.</span>
<li><span style=" font-size:11pt;font-family:Calibri">Discussed the effect
of the relatively new Q-SCID specs, from CCSDS 320.0-M-7, and the new USLP
protocol with its 16-bit SCID, on the existing SLE and CSTS protocols.
This is apparently being addressed within the CSS area.</span></ul></ul><span style=" font-size:11pt;font-family:Calibri"> </span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">The
files for review, and any added / background materials, will be placed
in the CWE at: </span><a href="https://urldefense.us/v3/__https:/cwe.ccsds.org/sea/docs/Forms/AllItems.aspx?RootFolder=*2Fsea*2Fdocs*2FSEA*2DSA*2FDraft*20Documents*2FSCCS*2DARD*2DADD*20Revisions*202020&View=*7BA709F322*2D0E67*2D45C7*2D932D*2DCB78C55CE268*7D&&InitialTabId=Ribbon*2EDocument&VisibilityContext=WSSTabPersistence*20__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!dkq2FeTLx9sqJswtaTiN_Nv7x6sENZfbDvsYuqOYjkc9OVxL4cehx4WH3MeU4GQYNshqouU5$"><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>https://cwe.ccsds.org/sea/docs/Forms/AllItems.aspx?RootFolder=%2Fsea%2Fdocs%2FSEA%2DSA%2FDraft%20Documents%2FSCCS%2DARD%2DADD%20Revisions%202020&View=%7BA709F322%2D0E67%2D45C7%2D932D%2DCB78C55CE268%7D&&InitialTabId=Ribbon%2EDocument&VisibilityContext=WSSTabPersistence</u></span></a></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><u>Action
Items:</u></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">=>
Next telecon, 1 MAR 2021: Review the updated approach for Sec 4 and Sec
6, to be produced by John Pietras, incorporating the agreed changes.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">=>
John and Peter to review a couple of “sticky” issues and bring that proposal
back to the rest of the WG.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">=>
Peter Shames to continue with separate working session, including CSS,
SLS, SIS and SEA, to look into the issues around the proposed CFDFP File
Delivery service , as discussed above, and the DTN alternative.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">=>
Peter has set up sub-folders for background, draft docs, and working meeting
minutes</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">=>
Request for the team to familiarize with these background materials</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span><tt><span style=" font-size:10pt">_______________________________________________<br>
SEA-SA mailing list<br>
SEA-SA@mailman.ccsds.org<br>
</span></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa"><tt><span style=" font-size:10pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<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>