[Sea-sa] [EXTERNAL] ESLT vs. ground tracking asset // was: DRAFT SCCS-ARD Revision Meeting Notes, 1 Feb 2021
Shames, Peter M (US 312B)
peter.m.shames at jpl.nasa.gov
Thu Feb 4 22:30:03 UTC 2021
Hi Gippo,
I think that the definition of ESLT, that you quoted from the CCSDS SCCS-ARD, is already quite clear. In addition to the definition you provided I draw your attention to the “building block” definition in sec 3.2.2, in CCSDS 901.1-M-1 Page 3-2
a) ESLTs (e.g., ABA and SSI ground stations)
· – shall provide a communications link between terrestrial elements and space elements,
· – shall provide interface to Radio Frequency (RF) space link,
· – shall provide services to one (or possibly more) Earth User Nodes,
· – shall provide full services for link layer processing and frame merging,
· – shall provide secure access control mechanisms,
· – shall route data between terrestrial elements and space (SSI),
· – shall provide full services for Network Layer processing and routing (SSI),
· – may support last-hop emergency and non-SSI delivery services (SSI),
· – shall provide a service management interface for processing requests, and for service configuration and reporting;
We purposely avoided using “ground station”, or “ground terminal”, or “network control center” because we did not wish to cause confusion with existing usage and deployments. Yes, we recognize that by introducing a new, unfamiliar term, that we introduced another possible source of confusion. We also understand that there are systems where the space access segments of the ELST are in one location and the terrestrial service delivery and service management segments are in another. The way we have defined this we are immune from any of these particular real system deployment choices.
We have no requirement to adopt any of the language nor notions that the IOAG uses. I think you are aware that there are many instances where what the IOAG chose to call some function or services does not align with current CCSSDS use, and vice-versa. That said, I think that you would have to agree that what we mean by ESLT is what the IOAG means by a “Ground Tracking Asset that is a combination of a Ground Station and a Ground Data System”. Or at least that part of a Ground Data System that is responsible for managing, controlling, and configuring the Ground Station and delivering data to the user. In NASA the Ground Data System is most often associated with a Mission and not with the “ground tracking network”, where the ESLT is clearly intended to be associated with the ground tracking network and not with the mission.
These definitions can be tricky to define in an unambiguous way.
Regards, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Thursday, February 4, 2021 at 6:13 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: SEA-SA <sea-sa at mailman.ccsds.org>
Subject: [EXTERNAL] ESLT vs. ground tracking asset // was: [Sea-sa] DRAFT SCCS-ARD Revision Meeting Notes, 1 Feb 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<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$>
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<https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa__;!!PvBDto6Hs4WbVuu7!cH8JDNPWvHZt8VeZyqSVbSHiOr5eFPeTd6p0WAnJNbMrqsK7HmUE63dtUmALG-SkRcRRdKh0$>
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/7a9fe3e8/attachment-0001.htm>
More information about the SEA-SA
mailing list