[Sea-sa] DRAFT SCCS-ARD Revision Meeting Notes, 1 Feb 2021

[Shames, Peter M (US 312B)]

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



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