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

Wed Feb 10 11:30:00 UTC 2021

Dear Greg, 

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

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>
To:     "Kazz, Greg J (US 312B) via SLS-SLP" <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>

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 
 [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
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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210210/b8af4669/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 30723 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210210/b8af4669/attachment-0001.gif>