[Sls-slp] PIDs concerning AOS & TC SDLP Pink Sheets

Wed Feb 10 15:09:22 UTC 2021

Dear Greg,
Regarding PID1 :

-          The incompatibility of VCF and MCF services with Insert service is specified in 2.2.4 and in the new requirement 3.2.6. Justification for this restriction is rather straightforward since MCF and VCF services  users provide complete Transfer Frames preventing periodic transmission of insert SDUs at frame rate. Note 2 of 3.2.6 already points to that justification.
Regarding PID 2 :

-          CNES does not use the term “port” in TC.. Removing this undefined term in the recommendation is desirable.

Best regards,
Gilles

Gilles MOURY
CNES Toulouse
De : SLS-SLP <sls-slp-bounces at mailman.ccsds.org> De la part de Marco.Rovatti at esa.int
Envoyé : mercredi 10 février 2021 12:30
À : Kazz, Greg J(US 312B) <greg.j.kazz at jpl.nasa.gov>
Cc : Kazz, Greg J (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>
Objet : Re: [Sls-slp] PIDs concerning AOS & TC SDLP Pink Sheets

Dear Greg,

Regarding Proposed PID 1:
The restriction is also stated in para 2.2.4

[cid:image001.gif at 01D6FFC3.8FA3CA70]

I think your explanation is correct. The Insert Zone Service was thought to carry small chunks of fixed length user data in each Transfer Frame transmitted on the Physical Channel in order to provide a low latency, "high priority",  synchronous service.
In the presence of Master Channel Service or Virtual Channel Service, this goal cannot be achieved because the sequence of Insert Zone SDUs  would eventually present gaps which are incompatible with the intended purpose of the service.
However the above is true if we assume that the users of MCF or VCF Services do not include a blank place holder in their TFs to accommodate an Insert Zone SDU.
In principle the above restriction might be removed if the user of MCF or VCF Servicea are constrained to provide a Transfer Frame format compliant with the presence of the insert zone.

Open for discussion.

Regarding Proposed PID 2

I concur with the explanation you provided. Port is used as a synonym of SAP. No ESA on-board implementation is broken by the removal of the term from the standard. I expect that also Ground implementation are not affected but maybe Gippo knows better.

Best regards
Marco

From:        "Kazz, Greg J\(US 312B\) via SLS-SLP" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
To:        "Kazz, Greg J (US 312B) via SLS-SLP" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Date:        10/02/2021 00:29
Subject:        [Sls-slp] PIDs concerning AOS & TC SDLP Pink Sheets
Sent by:        "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>>
________________________________

Dear SLP WG,

I was informed by Peter Shames, SEA Area Director, that he is considering generating two PIDs (Area Director Level) one for the attached AOS (732.0) and one for the TC (232.0) SDLP pink sheets.

My purpose of this email is to see if we (SLP WG) can come up with adequate changes to the text in question or provide adequate rationale for these specific pink sheet changes for example in the NOTE section of the documents.

Proposed PID 1: AOS Section 3.2.6 AOS Transfer Frame – why exclude the Insert Zone under the condition ?

FROM: 3.2.6. “ The following restriction apply to AOS Transfer Frames: if at least a Virtual Channel Frame or a Master Channel Frame service exists, all AOS Transfer Frames on the Physical Channel shall not include the Transfer Frame Insert Zone.”

TO: ?

The issue the PID brings up, is “what is the rationale for this restriction ?” Why can’t the physical channel contain an Insert Zone under this condition ? Provide the rationale in the document, in order to avoid confusing the user.

I believe the rationale has to do with the fact, that if a service user subscribes to either the VCF or the MCF service, then that user provides either complete Master Channel Frames or complete Virtual Channel Frames to the service provider. However, in those cases, there is an ambiguity concerning the use of the Insert Zone service by that user. The protocol only allows for one use of the Insert Zone service on the Physical Channel. Therefore to avoid any ambiguity, under this condition, there cannot be an Insert Zone.

If I am incorrect, please let me know.

So in order to address the PID, we could either modify 3.2.6 or provide clarification in the NOTE below it.

Your suggestions are welcome.

Proposed PID 2: TC SDLP Section 2.2.1 (and reoccurring) – removal of the term, “ports”

Issue: Why was the term, “ports” removed throughout the document ? By removing it from the document, does it break any implementations?

I noticed that the term “port” is not defined in both the 2003 as well as the current version of 232.0. I believe the SLP WG removed the term, “port(s)” because it was undefined and was not connected to the TC SDLP. In other words, “port(s)” was just a notional term, but never part of the actual TC SDLP. The only question remaining in the PID is “does it break any existing agency implementation, if that term is removed from the protocol” ?

I would like the SLP WG to weigh in on that question. I am not aware of any implementation issues from the NASA side.

Please try and respond back to me by the end of this week i.e., no later than Feb. 12.

Best regards,

Greg Kazz

Principal Engineer

Technical Group Supervisor,

PSSE/EEISE/PPSE (312B)

Jet Propulsion Laboratory

4800 Oak Grove Dr., M/S 301-490

Pasadena, CA 91109

1+(818)393 6529(voice)

1+(818)393 6871(fax)

email: greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>

 [attachment "732x0p30_CESG_Approval.pdf" deleted by Marco Rovatti/estec/ESA] [attachment "232x0b3_CESG_Approval.pdf" deleted by Marco Rovatti/estec/ESA]

_______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org<mailto:SLS-SLP at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp

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<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210210/6b714105/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 30723 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210210/6b714105/attachment-0001.gif>