From greg.j.kazz at jpl.nasa.gov Tue Apr 2 16:57:56 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 2 Apr 2013 16:57:56 +0000 Subject: [Sls-slp] Lessons Lernt Annex provided for Prox-1 GB Message-ID: Dear SLP WG, I have just received British Space's Lessons Lernt to be placed into an Annex into the Prox-1 Green Book. I've loaded two files to the SLP CWE (URL below), so that you can review the text and come prepared to discuss it at our SLP meeting in Bordeaux on Tuesday, April 16. Any comments before hand are also welcome. http://tinyurl.com/ajw9k3e Filenames have date creations of April 2. Best regards, Greg ------------------------------------------------------ Greg Kazz EEISE Group Supervisor Systems Engineering Section (Section 313) Jet Propulsion Laboratory 4800 Oak Grove Drive, Pasadena CA 91109 MS 301-490 (818) 393-6529 (office) ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Wed Apr 3 23:02:49 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Wed, 3 Apr 2013 23:02:49 +0000 Subject: [Sls-slp] Location of latest versions of TM, AOS, TC books due to SDLS requirements Message-ID: Dear SLP WG, Please find the lastest draft versions of TM, AOS, TC Space Data Link protocols on the CWE under: http://tinyurl.com/ck48ckr These contain all the comments to date plus the revised SDLS diagrams I spoke about in my last email. I have now inserted these diagrams into all AOS, TM, as well as TC. For disucssion on Tuesday April 16 at the meetings in Bordeaux. See you soon, Greg ------------------------------------------------------ Greg Kazz EEISE Group Supervisor Systems Engineering Section (Section 313) Jet Propulsion Laboratory 4800 Oak Grove Drive, Pasadena CA 91109 MS 301-490 (818) 393-6529 (office) ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marjorie at delandelong.com Thu Apr 11 08:57:10 2013 From: marjorie at delandelong.com (Marjorie de Lande Long) Date: Thu, 11 Apr 2013 10:57:10 +0200 Subject: [Sls-slp] [Sls-sea-dls] Order of Processing between TC-SDLP, COP-1 and SDLS In-Reply-To: References: Message-ID: <1365670630.1560.102.camel@machine-r> Dear Greg, Gian Paolo, Daniel, Ignacio and myself have been discussing the ESA position on a few things for the SDLS interface and its relationship to TC and COP-1. This is about two issues in your email exchange with Gilles: - ESA is against including a one bit SDLS Error Flag into the CLCW. - A specific SDLS OCF Type 2 report looks like a better option. ESA sees this as an option for future work: definition of format and rules for SDLS OCF Type 2 report is not simple and can only be done within the discussion of the SDLS Extended Procedures Because I will not be at the CCSDS meeting in Bordeaux, I am laying out my argument here on the subject of the proposed SDLS Error Flag to replace the Reserved Spare bit in the CLCW. There are four main sections (sorry this is so long!): - Section 1 considers a system where the SDLS handling is below COP-1, so that the SDLS handling is after FOP-1 at the sending end and before FARM-1 at the receiving end. - Section 2 considers a system where the SDLS handling is above COP-1, so that the SDLS handling is before FOP-1 at the sending end and after FARM-1 at the receiving end. - Section 3 considers the limitations of an SDLS Error Flag in the CLCW. - Section 4 has some general points. *** Also, this discussion assumes that a frame that fails SDLS verification is discarded. *** 1) For a system where the SDLS processing is after FOP-1 at the sending end and before FARM-1 at the receiving end 1.1 COP-1 delivery assumptions In this system, an SDLS verification failure does not compromise the COP-1 delivery assumptions: - At the receiving end, the SDLS failure is detected (and the frame is discarded) before the frame reaches FARM-1. - From the point of view of COP-1, this is similar to a frame that is lost because of a bad CRC or BCH: the FARM does not see the failed frame, so it does not acknowledge it. - The FOP will not receive an acknowledgement for the frame, so it will retransmit it (e.g. because of the timer). 1.2 COP-1 retransmission If FOP-1 retransmits the frame, then: - most likely, the frame will be rejected by SDLS again, so again the frame does not reach FARM-1 - if the original SDLS failure was caused by undetected transmission errors (not so likely), then the retransmitted frame could solve the problem. 1.3 Setting the SDLS Error Flag in the CLCW 1.3.1 If the faulty frame is discarded when the SDLS error is detected: - The frame does not reach FARM-1, so FARM-1 will not do any actions for the frame. - So there would need to be some new interface from the TC SDLP to the CLCW handling, but outside the FARM. - There is already an interface outside the FARM, for the Bit Lock, etc., but can this really be recommended? 1.3.2 If the faulty frame is not discarded when the SDLS error is detected: - The frame is passed to FARM-1 with an indication that it is faulty. - This would require new FARM-1 behaviour. - The new behaviour would not be limited to just setting the Flag in the CLCW. - So, there would be changes to FARM State Tables, etc., with all that implies ... 1.4 The failure needs to be reported - see 3.5 and 3.6 below. 2) For a system where the SDLS processing is before FOP-1 at the sending end and after FARM-1 at the receiving end 2.1 In this system, a frame can be lost because of an SDLS failure after the frame has been acknowledged and delivered by FARM-1. This is similar to an error being detected when reassembling a packet from multiple frames. 2.2 It is happening above COP-1, so, strictly speaking, the COP-1 delivery assumptions are not compromised. - The COP-1 delivery guarantee applies only as far as the output from the FARM: if a frame suffers an error after that, then that is not COP-1's problem. (It is a problem and it needs to be reported but it is not COP-1's problem.) - An example of one of these errors is mentioned in 2.1: there are existing systems that handle this error. 2.3 The SDLS failure is detected above the FARM, as the frame is being passed upwards. So it does not look so convenient to try to pass information downwards (e.g. into the FARM) so that the SDLS Error Flag can be set in the CLCW. 2.4 The failure needs to be reported - see 3.5 and 3.6 below. 3. Limitations of an SDLS Error Flag (For either position of the SDLS processing w.r.t. COP-1) 3.1 Is the purpose of the SDLS Error Flag simply to inform the sending end, or is some automatic behaviour (other than reporting) expected from FOP-1? - Firstly, this would affect the FOP-1 State Tables. - Secondly, what should FOP-1 do? There are so many different scenarios for SDLS use w.r.t. to SAs, VCs and MAPs that it would be difficult to say how FOP-1 should react. - Because of this and the other complications (e.g. what really caused SDLS to reject the frame), any decisions about how to handle the running A-Service in this circumstance have to be made at a higher level (management software and/or human operator). 3.2 The SDLS Error Flag is a single bit. It indicates "that the last received Transfer frame provided to the SDLS ProcessSecurity function was rejected", but it has very limited capability to say which frame or Security Association was affected. The sequence number in the CLCW only shows which frame was last accepted for the VC, on the A-Service. 3.3 - For a VC where the MAPs do not all have the same SA, or where some MAPs do not use SDLS, the sequence number in the CLCW is not much help to find which SA is affected. - For an SA which covers multiple VCs, the SA can be deduced, but the position of the error cannot. - If some SDLS frames are sent on the B-Service, the A-Service sequence number in the CLCW is not helpful. 3.4 The timing of the arrival of the CLCW is also not so helpful. There is a variable delay between the time when it is decided to set the SDLS Error Flag and the time the next CLCW is transmitted for the VC. By the time the flag arrives back at the sending end, there could be further difficulties in deciding which frame it refers to, and, in some circumstances, the error could already have cleared itself. 3.5 Clearly, the SDLS Error Flag is no substitute for an error reporting mechanism by the SDLS protocol entity at the receiving end, via its own management procedures, to inform the sending end of the SDLS failure. This reporting and the SDLS management procedures are SDLS-dependent and they are independent of the TC SDLP protocol. 3.6 At present, a TC SDLP protocol entity usually has its own implementation dependent reporting mechanisms for reporting on progress and on detected errors (such as detecting a frame with a bad CRC). These mechanisms are not specified in 232.0-B. Similarly, an implementation can make its own decisions on how it reports a frame that is rejected by SDLS. 4) General comments 4.1 An SDLS frame rejection can have many causes. It needs handling by management (at least management software, and often by people). 4.2 I don't think it is a good idea to use a COP-1 PDU to report a problem in a different protocol: - There is no one-to-one relationship between a COP-1 instance (which is a VC) and an SDLS instance (which is an SA). - The one-to-many relationship between a VC and an SA can go in either direction (multiple SAs in one VC or multiple VCs covered by one SA). 4.3 This SDLS Error Flag can only be used for TC. - SDLS errors also need reporting on AOS and TM links. - When SDLS is used for AOS on the uplink, then the SDLS errors will need to be communicated to the ground, but AOS does not use CLCWs. 4.4 Adding the SDLS Error Flag to the CLCW is not trivial. - If there is a rule for setting the flag at some time, then there also need to be some rules for interpreting it and resetting it etc. - Given its limited usefulness, is it likely to be worth the effort in amending other standards, getting acceptance and so on? I wish you all a successful meeting in Bordeaux! Best regards, Marjorie Marjorie de Lande Long I B + M A de Lande Long Software + Consultancy marjorie at delandelong.com On Fri, 2013-03-29 at 18:05 +0000, Kazz, Greg J (313B) wrote: > Bonjour Gilles, > > > Thanks for your reply. It seems we will need to discuss what is the > best mechanism for SDLS to provide real-time or near real-time > reporting to the control center. My suggestion was to use a spare bit > in the currently defined Version 1 of the OCF, namily the CLCW to > indicate the presence of a security error. Foremost in my mind is to > inform the control center as soon as possible of this problem, so that > they can take immediate action – most likely to stop sending any more > commands, until the problem can be analyzed. The analysis job is most > likely to be done in non-real-time by other personnel. So > identification of the problem can be sent in telemetry in the OCF > (whether or not CCSDS needs to define yet another OCF version > specifically to SDLS seems unnecessary to me, but as you point out, it > is an option). In addition, the analyst may want the spacecraft to > transmit some or all of the spurious data that it received to the > ground, so analysis can be done on the attack – this data would be > telemetered in packets, in order to understand what was received by > the spacecraft vs what was expected. Regardless of what kind of OCF is > sent, it will be in the clear. Do we want it to be in the clear ? Then > the "bad guys" will know we have detected them. > > > I understand the distinction between transmission and security types > of errors. However, once a security error is detected by SDLS, COP-1 > will not be informed of the detected error and will continue to > process frames as if nothing was wrong. The COP-1 will think it has > delivered an in-order, without duplicates nor gaps stream of transfer > frames but in reality it did not, due to the frame rejection by SDLS. > Isn't the behaviour we desire for the COP-1 to shut down in this > instance, to minimize futher contamination until the problem can be > cleared? > > > Best regards, > > > Greg > > > > > > > From: Moury Gilles > Date: Thursday, March 28, 2013 4:48 AM > To: "Kazz, Greg J (313B)" > Cc: "sls-sea-dls at mailman.ccsds.org" , > "sls-slp at mailman.ccsds.org" > Subject: RE: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, > COP-1 and SDLS > > > > Dear Greg and all, > > > > I concur with the clarifications that you have introduced in section > 6.3 and 6.4. Your proposed figures 6-c and 6-d are less ambiguous than > the preceding ones and they clearly rule out the possibility of > interfacing SDLS function with "All Frames Generation/Reception" > function. The text modifications you propose in coherence with those > new figures are OK. > > > > For the modifications introduced in 4.2.1.1.2 and 4.2.1.10 which aim > at defining an optional "SDLS Error Flag" to be transmitted in the > CLCW, I do not concur since we concluded at our Feb telecon on > SDLS-COP interaction that we should keep SDLS and COP decoupled. The > rationale being : > > > > - COP is dealing with transmission errors exclusively, so COP-FARM and > COP-FOP should only be informed of detected transmission errors > > > > - SDLS detects and passivate security errors (discarding impacted > frames). SDLS informs associated SLP protocol of security errors, SLP > protocol should in turn inform SLP user. In all cases, security > errors management will require analysis and action by human operators. > Therefore, I do not see what an automated procedure like the COP could > do with this SDLS error flag that you would like to introduce in the > CLCW. Security errors reporting will be defined as part of the SDLS > extended procedures which include an SDLS Monitoring & Control > service. A real-time SDLS reporting status word will be defined. It > could be transmitted either in line in the frame as a newly defined > OCF for TM/AOS, or as a normal TM packet to be carried in the data > field of TM/AOS transfer frames. What do you think of the possibility > to define a specific type of OCF for SDLS real-time reporting ? > > > > > > For your last point : "ApplySecurity" and "ProcessSecurity" functions > are mentionned in SDLS book. So the coherency is insured. We could > still add in SLP books that "ApplySecurity" and "ProcessSecurity" > functions are virtual functions that provide security services of > SDLS. > > > > Best regards, > > > > Gilles > > > > Gilles MOURY > CNES Toulouse > From edward.greenberg at jpl.nasa.gov Thu Apr 11 17:22:39 2013 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (313B)) Date: Thu, 11 Apr 2013 17:22:39 +0000 Subject: [Sls-slp] [Sls-sea-dls] Order of Processing between TC-SDLP, COP-1 and SDLS In-Reply-To: <1365670630.1560.102.camel@machine-r> Message-ID: Thanks for your input. I am still concerned with your item 2 as copied: - -- - - - - - - - - - - - - - - - - - On 4/11/13 1:57 AM, "Marjorie de Lande Long" wrote: >2) For a system where the SDLS processing is before FOP-1 at the sending >end and after FARM-1 at the receiving end > >2.1 In this system, a frame can be lost because of an SDLS failure >after the frame has been acknowledged and delivered by FARM-1. This is >similar to an error being detected when reassembling a packet from >multiple frames. >2.2 It is happening above COP-1, so, strictly speaking, the COP-1 >delivery assumptions are not compromised. >- The COP-1 delivery guarantee applies only as far as the output from >the FARM: if a frame suffers an error after that, then that is not >COP-1's problem. (It is a problem and it needs to be reported but it is >not COP-1's problem.) >- An example of one of these errors is mentioned in 2.1: there are >existing systems that handle this error. > >2.3 The SDLS failure is detected above the FARM, as the frame is being >passed upwards. So it does not look so convenient to try to pass >information downwards (e.g. into the FARM) so that the SDLS Error Flag >can be set in the CLCW. > >2.4 The failure needs to be reported - see 3.5 and 3.6 below. - - - -- - - - - - - - - - - - - First of all the implementation of the flag is simple. A wire from the SDLS process that is set to a 1 when a frame is rejected and reset to a 0 when a frame is accepted is all that is needed. This wire is sampled and becomes the flag when the CLCW is composed. Defining and then using a new CLCW to carry the information about the details of an SDLS failure seems simplistic and according to the frame processing rules would be in clear. Identifying why an SDLS failure incurred when no errors where caught needs more than a 32 bit diagnosis. I would suspect that a packet of information would be more appropriate. Even if encryption was not used for the frame the packet's content could be encrypted. The rationale for the flag in the CLCW was to let the COP know that an error occurred and its continued presents would inform the COP that continuation of COP activities was useless. From greg.j.kazz at jpl.nasa.gov Thu Apr 11 20:59:42 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Thu, 11 Apr 2013 20:59:42 +0000 Subject: [Sls-slp] [Sls-sea-dls] Order of Processing between TC-SDLP, COP-1 and SDLS In-Reply-To: References: <1365670630.1560.102.camel@machine-r>, Message-ID: <3DD03242-D283-4520-A309-137A078F597D@jpl.nasa.gov> Ed, Yes, why should the COP continue once the entire system knows there has been an error. Also easy to implement. Sent from my iPhone On Apr 11, 2013, at 7:22 PM, "Greenberg, Edward (313B)" wrote: > Thanks for your input. I am still concerned with your item 2 as copied: > - -- - - - - - - - - - - - - - - - - - > On 4/11/13 1:57 AM, "Marjorie de Lande Long" > wrote: > >> 2) For a system where the SDLS processing is before FOP-1 at the sending >> end and after FARM-1 at the receiving end >> >> 2.1 In this system, a frame can be lost because of an SDLS failure >> after the frame has been acknowledged and delivered by FARM-1. This is >> similar to an error being detected when reassembling a packet from >> multiple frames. >> 2.2 It is happening above COP-1, so, strictly speaking, the COP-1 >> delivery assumptions are not compromised. >> - The COP-1 delivery guarantee applies only as far as the output from >> the FARM: if a frame suffers an error after that, then that is not >> COP-1's problem. (It is a problem and it needs to be reported but it is >> not COP-1's problem.) >> - An example of one of these errors is mentioned in 2.1: there are >> existing systems that handle this error. >> >> 2.3 The SDLS failure is detected above the FARM, as the frame is being >> passed upwards. So it does not look so convenient to try to pass >> information downwards (e.g. into the FARM) so that the SDLS Error Flag >> can be set in the CLCW. >> >> 2.4 The failure needs to be reported - see 3.5 and 3.6 below. > - - - -- - - - - - - - - - - - - > > First of all the implementation of the flag is simple. A wire from the > SDLS process that is set to a 1 when a frame is rejected and reset to a 0 > when a frame is accepted is all that is needed. This wire is sampled and > becomes the flag when the CLCW is composed. > > Defining and then using a new CLCW to carry the information about the > details of an SDLS failure seems simplistic and according to the frame > processing rules would be in clear. Identifying why an SDLS failure > incurred when no errors where caught needs more than a 32 bit diagnosis. > I would suspect that a packet of information would be more appropriate. > Even if encryption was not used for the frame the packet's content could > be encrypted. > > The rationale for the flag in the CLCW was to let the COP know that an > error occurred and its continued presents would inform the COP that > continuation of COP activities was useless. > From marjorie at delandelong.com Fri Apr 12 07:48:08 2013 From: marjorie at delandelong.com (Marjorie de Lande Long) Date: Fri, 12 Apr 2013 09:48:08 +0200 Subject: [Sls-slp] [Sls-sea-dls] Order of Processing between TC-SDLP, COP-1 and SDLS In-Reply-To: <1365690116.2562.246.camel@machine-r> References: <1365690116.2562.246.camel@machine-r> Message-ID: <1365752888.1527.41.camel@machine-r> Dear Greg, *** Here is the email I sent yesterday (11.April), now with a few *** clarifications of the technical discussion about the CLCW *** flag. The changes are in 1.2, 4.1 and 4.4, marked with %%%. (These are points that were missing from the original and are not in response to comments received in the meanwhile.) Gian Paolo, Daniel, Ignacio and myself have been discussing the ESA position on a few things for the SDLS interface and its relationship to TC and COP-1. This is about two issues in your email exchange with Gilles: - ESA is against including a one bit SDLS Error Flag into the CLCW. - A specific SDLS OCF Type 2 report looks like a better option. ESA sees this as an option for future work: definition of format and rules for SDLS OCF Type 2 report is not simple and can only be done within the discussion of the SDLS Extended Procedures Because I will not be at the CCSDS meeting in Bordeaux, I am laying out my argument here on the subject of the proposed SDLS Error Flag to replace the Reserved Spare bit in the CLCW. There are four main sections (sorry this is so long!): - Section 1 considers a system where the SDLS handling is below COP-1, so that the SDLS handling is after FOP-1 at the sending end and before FARM-1 at the receiving end. - Section 2 considers a system where the SDLS handling is above COP-1, so that the SDLS handling is before FOP-1 at the sending end and after FARM-1 at the receiving end. - Section 3 considers the limitations of an SDLS Error Flag in the CLCW. - Section 4 has some general points. *** Also, this discussion assumes that a frame that fails SDLS verification is discarded. *** 1) For a system where the SDLS processing is after FOP-1 at the sending end and before FARM-1 at the receiving end 1.1 COP-1 delivery assumptions In this system, an SDLS verification failure does not compromise the COP-1 delivery assumptions: - At the receiving end, the SDLS failure is detected (and the frame is discarded) before the frame reaches FARM-1. - From the point of view of COP-1, this is similar to a frame that is lost because of a bad CRC or BCH: the FARM does not see the failed frame, so it does not acknowledge it. - The FOP will not receive an acknowledgement for the frame, so it will retransmit it (e.g. because of the timer). 1.2 COP-1 retransmission If FOP-1 retransmits the frame, then: %%% - In case of SDLS error (due to e.g. intruder or security misalignment between sending and receiving ends) it is likely that the retransmitted frame will not change and it will be discarded again. %%% - If the original SDLS failure was caused by undetected transmission errors (not so likely), then a retransmission can send a frame with fewer errors for BCH and/or CRC and it could solve the problem. %%% - If the failed frame did not come from FOP-1, then, of course, FOP-1 cannot retransmit it. 1.3 Setting the SDLS Error Flag in the CLCW 1.3.1 If the faulty frame is discarded when the SDLS error is detected: - The frame does not reach FARM-1, so FARM-1 will not do any actions for the frame. - So there would need to be some new interface from the TC SDLP to the CLCW handling, but outside the FARM. - There is already an interface outside the FARM, for the Bit Lock, etc., but can this really be recommended? 1.3.2 If the faulty frame is not discarded when the SDLS error is detected: - The frame is passed to FARM-1 with an indication that it is faulty. - This would require new FARM-1 behaviour. - The new behaviour would not be limited to just setting the Flag in the CLCW. - So, there would be changes to FARM State Tables, etc., with all that implies ... 1.4 The failure needs to be reported - see 3.5 and 3.6 below. 2) For a system where the SDLS processing is before FOP-1 at the sending end and after FARM-1 at the receiving end 2.1 In this system, a frame can be lost because of an SDLS failure after the frame has been acknowledged and delivered by FARM-1. This is similar to an error being detected when reassembling a packet from multiple frames. 2.2 It is happening above COP-1, so, strictly speaking, the COP-1 delivery assumptions are not compromised. - The COP-1 delivery guarantee applies only as far as the output from the FARM: if a frame suffers an error after that, then that is not COP-1's problem. (It is a problem and it needs to be reported but it is not COP-1's problem.) - An example of one of these errors is mentioned in 2.1: there are existing systems that handle this error. 2.3 The SDLS failure is detected above the FARM, as the frame is being passed upwards. So it does not look so convenient to try to pass information downwards (e.g. into the FARM) so that the SDLS Error Flag can be set in the CLCW. 2.4 The failure needs to be reported - see 3.5 and 3.6 below. 3. Limitations of an SDLS Error Flag (For either position of the SDLS processing w.r.t. COP-1) 3.1 Is the purpose of the SDLS Error Flag simply to inform the sending end, or is some automatic behaviour (other than reporting) expected from FOP-1? - Firstly, this would affect the FOP-1 State Tables. - Secondly, what should FOP-1 do? There are so many different scenarios for SDLS use w.r.t. to SAs, VCs and MAPs that it would be difficult to say how FOP-1 should react. - Because of this and the other complications (e.g. what really caused SDLS to reject the frame), any decisions about how to handle the running A-Service in this circumstance have to be made at a higher level (management software and/or human operator). 3.2 The SDLS Error Flag is a single bit. It indicates "that the last received Transfer frame provided to the SDLS ProcessSecurity function was rejected", but it has very limited capability to say which frame or Security Association was affected. The sequence number in the CLCW only shows which frame was last accepted for the VC, on the A-Service. 3.3 - For a VC where the MAPs do not all have the same SA, or where some MAPs do not use SDLS, the sequence number in the CLCW is not much help to find which SA is affected. - For an SA which covers multiple VCs, the SA can be deduced, but the position of the error cannot. - If some SDLS frames are sent on the B-Service, the A-Service sequence number in the CLCW is not helpful. 3.4 The timing of the arrival of the CLCW is also not so helpful. There is a variable delay between the time when it is decided to set the SDLS Error Flag and the time the next CLCW is transmitted for the VC. By the time the flag arrives back at the sending end, there could be further difficulties in deciding which frame it refers to, and, in some circumstances, the error could already have cleared itself. 3.5 Clearly, the SDLS Error Flag is no substitute for an error reporting mechanism by the SDLS protocol entity at the receiving end, via its own management procedures, to inform the sending end of the SDLS failure. This reporting and the SDLS management procedures are SDLS-dependent and they are independent of the TC SDLP protocol. 3.6 At present, a TC SDLP protocol entity usually has its own implementation dependent reporting mechanisms for reporting on progress and on detected errors (such as detecting a frame with a bad CRC). These mechanisms are not specified in 232.0-B. Similarly, an implementation can make its own decisions on how it reports a frame that is rejected by SDLS. 4) General comments %%% 4.1 An SDLS frame rejection can have many causes (e.g. intruder, SA misalignment between sending and receiving ends, key management issue, undetected error). It needs handling by management (at least management software, and often by people). 4.2 I don't think it is a good idea to use a COP-1 PDU to report a problem in a different protocol: - There is no one-to-one relationship between a COP-1 instance (which is a VC) and an SDLS instance (which is an SA). - The one-to-many relationship between a VC and an SA can go in either direction (multiple SAs in one VC or multiple VCs covered by one SA). 4.3 This SDLS Error Flag can only be used for TC. - SDLS errors also need reporting on AOS and TM links. - When SDLS is used for AOS on the uplink, then the SDLS errors will need to be communicated to the ground, but AOS does not use CLCWs. 4.4 Adding the SDLS Error Flag to the CLCW is not trivial. %%%- There would be a rule for setting the flag at some time. But there would be other questions to be answered: When would the flag be reset? What is the effect on FOP state tables? %%%- The timing would also need to be considered. What is the minimum time interval before resetting the flag? Because of the sampling interval for the CLCWs on a VC, the flag should not be reset too soon, otherwise it might be reset before a CLCW has been sent. - Given its limited usefulness, is it likely to be worth the effort in amending other standards, getting acceptance and so on? I wish you all a successful meeting in Bordeaux! Best regards, Marjorie Marjorie de Lande Long I B + M A de Lande Long Software + Consultancy marjorie at delandelong.com On Fri, 2013-03-29 at 18:05 +0000, Kazz, Greg J (313B) wrote: > Bonjour Gilles, > > > Thanks for your reply. It seems we will need to discuss what is the > best mechanism for SDLS to provide real-time or near real-time > reporting to the control center. My suggestion was to use a spare bit > in the currently defined Version 1 of the OCF, namily the CLCW to > indicate the presence of a security error. Foremost in my mind is to > inform the control center as soon as possible of this problem, so that > they can take immediate action – most likely to stop sending any more > commands, until the problem can be analyzed. The analysis job is most > likely to be done in non-real-time by other personnel. So > identification of the problem can be sent in telemetry in the OCF > (whether or not CCSDS needs to define yet another OCF version > specifically to SDLS seems unnecessary to me, but as you point out, it > is an option). In addition, the analyst may want the spacecraft to > transmit some or all of the spurious data that it received to the > ground, so analysis can be done on the attack – this data would be > telemetered in packets, in order to understand what was received by > the spacecraft vs what was expected. Regardless of what kind of OCF is > sent, it will be in the clear. Do we want it to be in the clear ? Then > the "bad guys" will know we have detected them. > > > I understand the distinction between transmission and security types > of errors. However, once a security error is detected by SDLS, COP-1 > will not be informed of the detected error and will continue to > process frames as if nothing was wrong. The COP-1 will think it has > delivered an in-order, without duplicates nor gaps stream of transfer > frames but in reality it did not, due to the frame rejection by SDLS. > Isn't the behaviour we desire for the COP-1 to shut down in this > instance, to minimize futher contamination until the problem can be > cleared? > > > Best regards, > > > Greg > > > > > > > From: Moury Gilles > Date: Thursday, March 28, 2013 4:48 AM > To: "Kazz, Greg J (313B)" > Cc: "sls-sea-dls at mailman.ccsds.org" , > "sls-slp at mailman.ccsds.org" > Subject: RE: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, > COP-1 and SDLS > > > > Dear Greg and all, > > > > I concur with the clarifications that you have introduced in section > 6.3 and 6.4. Your proposed figures 6-c and 6-d are less ambiguous than > the preceding ones and they clearly rule out the possibility of > interfacing SDLS function with "All Frames Generation/Reception" > function. The text modifications you propose in coherence with those > new figures are OK. > > > > For the modifications introduced in 4.2.1.1.2 and 4.2.1.10 which aim > at defining an optional "SDLS Error Flag" to be transmitted in the > CLCW, I do not concur since we concluded at our Feb telecon on > SDLS-COP interaction that we should keep SDLS and COP decoupled. The > rationale being : > > > > - COP is dealing with transmission errors exclusively, so COP-FARM and > COP-FOP should only be informed of detected transmission errors > > > > - SDLS detects and passivate security errors (discarding impacted > frames). SDLS informs associated SLP protocol of security errors, SLP > protocol should in turn inform SLP user. In all cases, security > errors management will require analysis and action by human operators. > Therefore, I do not see what an automated procedure like the COP could > do with this SDLS error flag that you would like to introduce in the > CLCW. Security errors reporting will be defined as part of the SDLS > extended procedures which include an SDLS Monitoring & Control > service. A real-time SDLS reporting status word will be defined. It > could be transmitted either in line in the frame as a newly defined > OCF for TM/AOS, or as a normal TM packet to be carried in the data > field of TM/AOS transfer frames. What do you think of the possibility > to define a specific type of OCF for SDLS real-time reporting ? > > > > > > For your last point : "ApplySecurity" and "ProcessSecurity" functions > are mentionned in SDLS book. So the coherency is insured. We could > still add in SLP books that "ApplySecurity" and "ProcessSecurity" > functions are virtual functions that provide security services of > SDLS. > > > > Best regards, > > > > Gilles > > > > Gilles MOURY > CNES Toulouse > _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp From MCOSBY at qinetiq.com Wed Apr 17 16:16:01 2013 From: MCOSBY at qinetiq.com (Cosby Matthew) Date: Wed, 17 Apr 2013 17:16:01 +0100 Subject: [Sls-slp] SLP Slide Message-ID: All, Please find attached the SLP slide presented this morning. Matt. Matthew Cosby Chief Engineer, QinetiQ Space UK Tel: 01252 396313 email: mcosby at QinetiQ.com www.QinetiQ.com QinetiQ - Delivering customer-focused solutions Please consider the environment before printing this email. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. QinetiQ may monitor email traffic data and also the content of email for the purposes of security. QinetiQ Limited (Registered in England & Wales: Company Number: 3796233) Registered office: Cody Technology Park, Ively Road, Farnborough, Hampshire, GU14 0LX http://www.qinetiq.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SLP Recommendations for SDLS.ppt Type: application/vnd.ms-powerpoint Size: 215552 bytes Desc: SLP Recommendations for SDLS.ppt URL: From greg.j.kazz at jpl.nasa.gov Tue Apr 23 21:45:46 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 23 Apr 2013 21:45:46 +0000 Subject: [Sls-slp] Updated Prox-1 Data Link Layer PICS Proforma Message-ID: Dear SLP, As a result of our SLP meeting in Bordeaux, I have updated the PICS Proforma for the Data Link layer of Proximity-1. Please review the new table with the date of April 23. I have also include the table with the file name Feb. 12 which was the one I used to take the notes during the meeting for your comparison. I would like to send this table on to our area director by the end of April, so your comments before then are well appreciated. These files will also be loaded to the SLP CWE under the Bordeaux directory. Thanks! Greg ------------------------------------------------------ Greg Kazz EEISE Group Supervisor Systems Engineering Section (Section 313) Jet Propulsion Laboratory 4800 Oak Grove Drive, Pasadena CA 91109 MS 301-490 (818) 393-6529 (office) ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Prox-1_PICS_Proforma_APR_23_2013_ab.xls Type: application/x-msexcel Size: 76800 bytes Desc: Prox-1_PICS_Proforma_APR_23_2013_ab.xls URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Prox-1_PICS_Proforma_Feb_12_2013_ab.xls Type: application/x-msexcel Size: 90112 bytes Desc: Prox-1_PICS_Proforma_Feb_12_2013_ab.xls URL: From huangwei at bittt.cn Thu Apr 25 12:48:48 2013 From: huangwei at bittt.cn (HuangWei) Date: Thu, 25 Apr 2013 20:48:48 +0800 (CST) Subject: [Sls-slp] Reference information for RTP Message-ID: <48a4838c.7da9.13e413d2c1b.Coremail.huangwei@bittt.cn> Dear Mr. Greg Kazz The refence information for RTP is as following: Henning Schulzrinne，Stephen L. Casner,Ron Frederick,Van Jacobson. RTP: A Transport Protocol for Real-Time Applications.RFC3550，July 2003 I had written an email to you. Unfortunately, it's bounced back. I hope you can see this information. Kind regards Huangwei -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Thu Apr 25 22:56:00 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Thu, 25 Apr 2013 22:56:00 +0000 Subject: [Sls-slp] Draft SLP meeting minutes - Bordeaux FR Spring 2013 Message-ID: Dear SLP, Attached please find the draft copy of the SLP WG meeting minutes from our Spring 2013 meeting held in Bordeaux, FR. Once I have the complete list of attendees from the Secretariat, I will add it to these minutes. In the mean time, please feel free to send me your comments on the minutes. I would like to conclude all comments by May 10 and issue a final set of minutes shortly thereafter. Best regards, Greg ------------------------------------------------------ Greg Kazz EEISE Group Supervisor Systems Engineering Section (Section 313) Jet Propulsion Laboratory 4800 Oak Grove Drive, Pasadena CA 91109 MS 301-490 (818) 393-6529 (office) ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SLS-SLP_Spring_2013_Minutes_Bordeaux.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 700536 bytes Desc: SLS-SLP_Spring_2013_Minutes_Bordeaux.docx URL: From greg.j.kazz at jpl.nasa.gov Tue Apr 30 23:49:35 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 30 Apr 2013 23:49:35 +0000 Subject: [Sls-slp] Proposed new TC Sections 6.3 and 6.4 containing the SDLS option Message-ID: Dear SLP and SDLP WGs, Attached please find my draft response to the SLP action item from the SDLS WG meeting regarding updating the TC Space Data Link Protocol in Sections 6.3 Sending End Procedures with SDLS option and 6.4 Receiving End Procedures with SDLS option. (The TM and AOS sections will follow once we have reached consensus on TC.) I believe I have followed the collective wisdom of the two group's inputs in this update. I eliminated the SDLS error flag, added the order of processing diagram, and supplied the descriptive text for it. I made one deviation from the results of our meeting, which was to eliminate the previous 6c and 6d diagrams. I think this diagram along with the text now unambiguously specifies the interface between TC (including the COP) and SDLS. Therefore, I don't think we need to repeat the old 6c nor 6d diagrams. But I leave it up to you to correct me if I am wrong. Best regards, Greg ------------------------------------------------------ Greg Kazz EEISE Group Supervisor Systems Engineering Section (Section 313) Jet Propulsion Laboratory 4800 Oak Grove Drive, Pasadena CA 91109 MS 301-490 (818) 393-6529 (office) ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TC_Space_Data_Link_Protocol_April30_2013.doc Type: application/msword Size: 1282048 bytes Desc: TC_Space_Data_Link_Protocol_April30_2013.doc URL: