[Sea-sa] ESLT vs. ground tracking asset // was: DRAFT SCCS-ARD Revision Meeting Notes, 1 Feb 2021

Thu Feb 4 14:13:05 UTC 2021

Dear Peter,
        can you please clarify what is the relationship between the ESLT 
and the ground tracking asset mentioned by IOAG Catalogs?

In the CCSDS document the definition for the Earth Space Link Terminal 
says:
Earth Space Link Terminal (ESLT): The CSSE that provides space 
communication
services between the Earth User Node and the Space User Node. It includes 
the ground
station control and management systems. The ESLT has space link protocol 
interfaces and
supports terrestrial SLE and CSTS interfaces. The ESLT also has a service 
management
interface that is controlled by the UE that is responsible for managing 
the space link.

In IOAG Catalogs the ground tracking asset follows this definition:
Ground Tracking Assets may be Ground Stations, Ground Data System or a 
combination of both.

I think it is essential to state something about their coincidence and/or 
difference.
Is ESLT as a synonym for ground station? or is ESLT a a synonym for ground 
tracking asset?

Surely it makes a big point for what you call the <infamous IOAG “CFDP 
file delivery service”, and the even more ephemeral “IOAG Packet file 
delivery service”>.

Thanks

Gippo

From:   "Shames, Peter M\(US 312B\) via SEA-SA" <sea-sa at mailman.ccsds.org>
To:     "SEA-SA" <sea-sa at mailman.ccsds.org>
Date:   02-02-21 19:20
Subject:        [Sea-sa] DRAFT SCCS-ARD Revision Meeting Notes, 1 Feb 2021
Sent by:        "SEA-SA" <sea-sa-bounces at mailman.ccsds.org>

SCCS-ARD Revision Meeting Notes, 1 Feb 2021

Attendees: Peter Shames, John Pietras, Ramon Krosley, Costin Radulescu, 
Ricard Abello, Holger Dreihahn

Reviewed the latest “Issues” file that John Pietras presented including 
the intended fixes for several identified issues.
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: 
Sec 4: agreed to add R-OCF to the other SLE services, for completeness. 
Agreed to add a few sentences to further clarify the means intended with 
[Future] standards and also (recommended) notations
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.
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.
Agreed to change references from RF & Mod to Physical Channel, so as to 
accommodate both RF and Optical.
Sec 6: agreed to use separate diagrams for the various protocol stacks, to 
simplify references 
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.
Agreed to use those complicated tables, and example diagrams, to document 
all of the viable and supported configurations.
Agreed to edit those tables to more accurately reflect D-DOR, the D-DOR 
architecture, and DOR tones.
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.
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.
During the meeting we also discussed a couple of related topics, as 
follows: 
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.
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.
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 manage 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.
Several other topics remain from the earlier meetings: 
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. 
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.
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.

The files for review, and any added / background materials, will be placed 
in the CWE at: 
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

Action Items:

=> 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.
=> John and Peter to review a couple of “sticky” issues and bring that 
proposal back to the rest of the WG.
=> 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.

=> Peter has set up sub-folders for background, draft docs, and working 
meeting minutes
=> Request for the team to familiarize with these background materials

 _______________________________________________
SEA-SA mailing list
SEA-SA at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa

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 at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210204/c7216d8e/attachment-0001.htm>