[Sls-slp] Re: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS

Tue Mar 19 19:08:07 UTC 2013

All,

Attached is my attempt to clarify the known interface points between the TC protocol and SDLS. Most of my redlines are confined to the following sections:

4.2.1.1.2
4.2.1.10
6.3
6.4

 I tried to clarify at what channel level (individual VC, MC, Physical Channel – meaning multiplexed Mcs) the TC user can interface with SDLS. To this end, I provided a diagram that attempts to show this relationship replacing Marjorie's in Section 6.3 and 6.4, which didn't define the interface but rather showed typically examples of where the interface might be. I also introduced text that would aide the TC user in choosing the appropriate interface point to SDLS within TC. You will see this new text also in sections 6.3 and 6.4.

Most controversially perhaps is the addition of an optional new flag, that SDLS should consider supporting, called "SDLS Error Flag" which enables a reporting mechanism of security errors from SDLS through the CLCW to COP-1. My concern is that without it, there is no mechanism to inform the COP-1 that the in-order, without duplicate or omission delivery guarenteed by the COP-1 may have been compromised due to actions taken by SDLS but unknown to the COP-1. I encourage the SDLS WG to consider it.

Finally to ensure that both the SDLS book and the SLP books are coherent, should there be some mention in the SDLS book about the virtual functions I.e., "ApplySecurity" and "ProcessSecurity" mentioned in TC (which will also be mentioned in AOS and TM as well). Or should we simply say in the SLP books, that this is a virtual function that represents the security services provided in SDLS?  It is another open issue.

This attached version of the TC book is now in the SLP WG CWE under: http://tinyurl.com/ck48ckr

Your comments are welcome!

Best regards,

Greg Kazz
Chairman SLP WG

From: <Kazz>, "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Date: Thursday, March 14, 2013 1:22 PM
To: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Cc: "sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>" <sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>>, "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Subject: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS

Bonjour Gilles,

Thank you for contribution.  Essentially you are saying that the green box in both Figures 6c and 6d should shrink so that it does not expand beyond either the Master Channel Multiplexing Function or the MC Demultiplexing Function. In other words, there is no interface point for SDLS with either the TC-SDLP 'All frames generation' or 'All Frames receiption' functions. This makes sense. However, Figures 6c and 6d are very nebulous in the sense that there is this "SDLS ApplySecurity Function" seemingly floating around in space that shows an anchor at the port of "Virtual Channel Multiplexing/Demultiplexing" only for example. The text says it could be in Virtual Channel Generation Function or in the Virtual Channel Multiplexing function. No text talks about the possibility in the MC Multiplexing function. Also the COP management Function is called out in 6c, but no such reciprocal function exists in 6d. I think we are still lacking a clear explanation of these figures in the text.

We still need a better way to convey the relationships between the protocols involved including the order of overall processing to the user  I.e.,  between SDLS, COP-1, TC-SDLP. I think some kind of high order diagram and text that shows the order of processing between them is needed.

We also need to modify the TC Sync & CC Green book so that we capture the rationale behind our decisions on the order of processing of SDLS, COP-1, TC-SDLP (much of which you have already captured in the meeting minutes of our last TIM, but some business is yet to be completed).

Comments anyone ?

Best regards,

Greg

From: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Date: Thursday, March 14, 2013 10:06 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "Greenberg, Edward (313B)" <edward.greenberg at jpl.nasa.gov<mailto:edward.greenberg at jpl.nasa.gov>>, "Biggerstaff, Craig (JSC-DD12)[LOCKHEED MARTIN CORP]" <craig.biggerstaff-1 at nasa.gov<mailto:craig.biggerstaff-1 at nasa.gov>>, "sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>" <sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>>, "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Subject: RE: Order of Processing COP-1 and SDLS

Dear Greg,

Please find attached the additions I propose to the TC-SDLP book to avoid users implementing the wrong order of processing between SDLS and "frame error detection" by TC-SDLP. In fact, the only forbidden configuration for interfacing SDLS function with TC-SDLP functions is interfacing SDLS with "All Frame Generation" at the sending end and "All Frame Reception" at the receiving end. This guarantee that, at the receiving end, transmission errors are detected and impacted frames discarded first , before SDLS processes the frames, which satisfies our security requirement that transmission errors should be unambiguously separated from security errors.

I have therefore introduced an additional text in sections 6.3.1 and 6.4.1 to forbid this configuration (see attached redlined file). I think it covers the point. All comments are welcome.

Best regards,

Gilles

Gilles MOURY
CNES Toulouse
De : Kazz, Greg J (313B) [mailto:greg.j.kazz at jpl.nasa.gov]
Envoyé : lundi 11 mars 2013 23:02
À : Moury Gilles
Cc : Greenberg, Edward (313B); Biggerstaff, Craig (JSC-DD12)[LOCKHEED MARTIN CORP]
Objet : Order of Processing COP-1 and SDLS

Gilles,

Correct me if I am wrong, but I did not see a response from you regarding this action item below:
We do not have text in the TC SLP section 6 document which deals with this issue yet.

- best regards,

Greg
SDLS0213/01

G. Moury

Propose a solution to explicitly specify the order of processing at the receiving end between TC-COP and SDLS (if not already present in section 6 of TC-SLP)

 March 8, 2013

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20130319/d775eb9c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/applefile
Size: 455 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20130319/d775eb9c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 232x0b2pinkMAdeLLDec08+gpc+gjk+GM+gk2.doc
Type: application/msword
Size: 1389056 bytes
Desc: 232x0b2pinkMAdeLLDec08+gpc+gjk+GM+gk2.doc
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20130319/d775eb9c/attachment.doc>