From greg.j.kazz at jpl.nasa.gov Fri Mar 1 21:29:06 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 1 Mar 2013 21:29:06 +0000 Subject: [Sls-slp] Overview of Space Communications Protocols GB - 130.0-G-2 Message-ID: G.P., Once I opened up this "pandora's box", I quickly discovered that their will be much more than the one or two simple edits required (update due to SDLS)… Since the book was published in 2007… I am going over the book now and I will send my comments to the SLP WG for futher review and comment. Regards, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Fri Mar 1 22:20:18 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 1 Mar 2013 22:20:18 +0000 Subject: [Sls-slp] =?windows-1252?q?What_about___SPACE_DATA_LINK_PROTOCOL?= =?windows-1252?q?S=8BSUMMARY_OF_CONCEPT_AND_RATIONALE_=3F_CCSDS_130=2E2-G?= =?windows-1252?q?-2?= Message-ID: G.P. Unfortunately, we have already released this SLS GB (CCSDS 130.2-G-2) in Nov. 2012; this update was done specifically for the data link layer protocols due to the number of retransmissions parameter update for COP-1. However, CCSDS 130.2-G-2 will also need to be updated for the SDLS and general maintenance issues since 2007. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Moury at cnes.fr Tue Mar 5 10:32:11 2013 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Tue, 5 Mar 2013 10:32:11 +0000 Subject: [Sls-slp] SDLS-SLP fev21 telecon MoM (final version) Message-ID: <442F062EBF46F247A96B8A50EF3EB6F415376673@TW-MBX-P04.cnesnet.ad.cnes.fr> Dear CCSDS SDLS & SLP WGs members, Please find attached the final version of the MoM of our feb 21st telecon. This final version takes into account comments received. Best regards, Gilles Moury ========================================================= Gilles MOURY CNES Toulouse Expert senior "Plateforme Satellite" ECSS Technical Authority chairman Sous-Direction "Techniques Véhicule, Architecture & Intégration" DCT/TV-RA - Bpi 1416 18, avenue Edouard Belin F-31401 TOULOUSE Cedex 9 http://www.cnes.fr tel : +33 (0)5 61 27 3790 fax : +33 (0)5 61 27 4099 sec : +33 (0)5 61 27 3882 mob : +33 (0)6 83 56 0485 ========================================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDLS WG MoM - telecon Fev 2013 v2.doc Type: application/msword Size: 104448 bytes Desc: SDLS WG MoM - telecon Fev 2013 v2.doc URL: From greg.j.kazz at jpl.nasa.gov Wed Mar 6 00:11:26 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Wed, 6 Mar 2013 00:11:26 +0000 Subject: [Sls-slp] Updates to CCSDS 130.0-G-2 Overview of Space Comm Protocols Message-ID: Dear SLP WG and Massimo, Based upon our SLP charter, we have a work project associated with the update of CCSDS 130.0-G-2, Overview of Space Communications Protocols. This green book was last issued in 2007 and is clearly out of date in several ways. I have edited it using the Word revision feature and my edits are in red. Basically, I "caught the book up to date" with the current state of the CCSDS protocols including the emerging SDLS. Please take a look in the CWE at the URL below and download it and add your comments as you see necessary. We will review the result at the Spring SLP meeting in Bordeaux. http://tinyurl.com/akwvpyg For Massimo and C&S WG: There are sections in this GB e.g., 3.2.4 and other sections that talk about channel coding. I made an attempt to update it, but I would appreciate your comments as well as your WG's words of wisdom here. For example, I am uncertain about if and when the CCSDS DVBS-2 standard will be released. Best regards, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Wed Mar 6 19:33:17 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Wed, 6 Mar 2013 19:33:17 +0000 Subject: [Sls-slp] Input paper deadline for SLS-SLP WG meetings in Bordeaux, FR Message-ID: Dear SLP, Please email me your intent to provide inputs and or an input white paper regarding any SLP WG related topics by or before March 15. The due date for all white papers will be April 5. Best regards, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Fri Mar 8 00:30:23 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 8 Mar 2013 00:30:23 +0000 Subject: [Sls-slp] March 7 update to draft "Overview of Space Communications GB" Message-ID: Dear SLP, Please find a few more updates based upon replies to Gian Paolo's comments on the CWE under: http://tinyurl.com/akwvpyg Further discussion on the open items will take place in Bordeaux. Best regards, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Mar 12 16:47:42 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 12 Mar 2013 16:47:42 +0000 Subject: [Sls-slp] 3 new RIDs against AOS/TM Space Data LInks Message-ID: Dear SLP, Attached please find one file containing the following RIDs against either TM or AOS Space Data Link Protocol or both, depending on the issue. 1. John Pietrus requesting that MC_OCF service be added to AOS. 2. Gian Paolo requesting that the document reference to the packet processing function in AOS be corrected. 3. Gian Paolo/Marjorie D. requesting a correction to both AOS & TM regarding the FHP and Frame Length fields. Please review this attachment (soon to be place on the CWE under SLP) and send me your comments. We will disposition these rids at the Bordeaux meeting. Best regards, Greg Chairman CCSDS SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AOS SDLP RID-MC_OCF+Reference+FHP.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 43113 bytes Desc: AOS SDLP RID-MC_OCF+Reference+FHP.docx URL: From greg.j.kazz at jpl.nasa.gov Wed Mar 13 19:06:04 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Wed, 13 Mar 2013 19:06:04 +0000 Subject: [Sls-slp] FW: [Ccsds-all] Registration is Open for the CCSDS Spring 2013 Meeting in Bordeaux In-Reply-To: Message-ID: Dear SLP and NGU members: Please register for the Spring 2013 CCSDS meetings in Bordeaux, FR below. Best regards, Greg Chairman CCSDS SLP and NGU WGs From: "ccsds-all at mailman.ccsds.org" > Reply-To: "secretariat at mailman.ccsds.org" >, "ccsds-all at mailman.ccsds.org" > Date: Wednesday, March 13, 2013 11:15 AM To: "ccsds-all at mailman.ccsds.org" > Subject: [Ccsds-all] Registration is Open for the CCSDS Spring 2013 Meeting in Bordeaux SPRING 2013 TECHNICAL PLENARY MEETING As announced earlier, the next CCSDS technical meetings will be held from 15-18 April 2013 in Bordeaux, France. The host for these meetings is the French Space Agency (CNES) and they have secured meeting space at the Aerocampus Aquitaine in Latresne, just outside of the Bordeaux city center. For details and to register, visit http://public.ccsds.org/meetings/2013Spring/default.aspx. Maps, hotels and other info are available at the website. Aerocampus Aquitaine has very few sleeping rooms for those who wish to stay on-site, in walking distance, instead of in local towns, requiring transportation. Photos of on-site accommodations are on the CCSDS website, and the cost is only 48 Euros per night, including breakfast. These will be offered on a first come, first serve basis. However, please consider that some attendees will need to be on-site because of inability to use rental cars or difficulty with public transportation. If you are very comfortable using such transportation, please consider staying elsewhere so that priority can be given to attendees who need to be within walking distance. When these few rooms are all occupied, that notice will be posted on the CCSDS website. There are many other hotels in nearby Latresne or Bordeaux, and some recommendations are on the CCSDS website link above. As always, registration to attend is required, but there are no fees. Registration will close on Monday, 8 April 2013, one week before the start of the technical meetings. There is a new feature for the Registration System and the Collaborative Work Environment (CWE) this time. You will need to fill out some information to register your “profile”, and this will be retained to make it easier for you to register in the future. Because Visa letters were distributed at the last meeting for the upcoming meeting, all attendees that require any should already have your Visa letters. If you do not, contact the Secretariat immediately so they can be provided. Also, as always, dress for the Technical Plenary meeting is Business Casual. FALL 2013 TECHNICAL PLENARY MEETING The Fall 2013 Technical Plenary meeting will be hosted by NASA and held at NASA’s Ames Research Center (ARC) in Mountain View, California (near San Francisco). The meeting will be held during the week of October 28, 2013. More info will be distributed as it becomes available. At the Spring meeting in Bordeaux, we will be distributing the Visa letters that will be needed for the Fall meeting at ARC. If you received one for the Spring meeting, we will generate that for the Fall meeting and bring it automatically. If you did not receive one for the Spring meeting and you need one to attend the Fall meeting, please tell the Secretariat (Secretariat at mailman.ccsds.org) so that we can bring one to you in Bordeaux or mail it to you. We are working hard to ensure that you do not have Visa problems because of receiving the Visa Letter of Invitation too late. Nick Tongson For the Secretariat of the Consultative Committee for Space Data Systems (CCSDS) American Institute of Aeronautics & Astronautics (AIAA) 1801 Alexander Bell Drive Suite 500 Reston, VA 20191 USA www.aiaaa.org Tel: +1-703-264-7515 Fax: +1-703-264-7551 [cid:3311312110_11257245] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3117 bytes Desc: image001.jpg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00002.txt URL: From Gilles.Moury at cnes.fr Thu Mar 14 17:06:51 2013 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Thu, 14 Mar 2013 17:06:51 +0000 Subject: [Sls-slp] RE: Order of Processing COP-1 and SDLS In-Reply-To: References: Message-ID: <442F062EBF46F247A96B8A50EF3EB6F415381421@TW-MBX-P04.cnesnet.ad.cnes.fr> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 232x0b2pinkMAdeLLDec08+gpc+gjk+GM.doc Type: application/msword Size: 1242624 bytes Desc: 232x0b2pinkMAdeLLDec08+gpc+gjk+GM.doc URL: From greg.j.kazz at jpl.nasa.gov Thu Mar 14 17:20:06 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Thu, 14 Mar 2013 17:20:06 +0000 Subject: [Sls-slp] FW: [SLS] CCSDS ?Code of Conduct? In-Reply-To: <17374_1363251100_51418F9C_17374_18107_1_OF66A0FFDF.F8279E8B-ONC1257B2E.00304CC1-C1257B2E.0030ADF9@esa.int> Message-ID: Dear SLP and NGU, Please read the attachment regarding the CCSDS "Code of Coduct" for our CCSDS meetings and interactions. Best regards, Greg From: "Gian.Paolo.Calzolari at esa.int" > Date: Thursday, March 14, 2013 1:51 AM To: SLS - Space Link Services Area > Subject: [SLS] CCSDS ?Code of Conduct? Dear All, despite they will discover it when registering, you may want to remember to your WG members that "CCSDS has adopted the ISO “Code of Conduct” for the conduct of the working group and team efforts within CCSDS. Additionally, CCSDS has added a few statements beyond the ISO Code of Conduct that historical experience has shown are needed to ensure fair and professional treatment of our colleagues in our teams. " Everybody is asket to read the code of conduct, and indicate acceptance. The code is attached here. Regards Gian Paolo This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CCSDS_Code_of_Conduct.pdf Type: application/octet-stream Size: 173388 bytes Desc: CCSDS_Code_of_Conduct.pdf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From greg.j.kazz at jpl.nasa.gov Thu Mar 14 20:22:04 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Thu, 14 Mar 2013 20:22:04 +0000 Subject: [Sls-slp] Re: Order of Processing between TC-SDLP, COP-1 and SDLS In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F415381421@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: 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 > Date: Thursday, March 14, 2013 10:06 AM To: "Kazz, Greg J (313B)" > Cc: "Greenberg, Edward (313B)" >, "Biggerstaff, Craig (JSC-DD12)[LOCKHEED MARTIN CORP]" >, "sls-sea-dls at mailman.ccsds.org" >, "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: From greg.j.kazz at jpl.nasa.gov Fri Mar 15 18:38:37 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 15 Mar 2013 18:38:37 +0000 Subject: [Sls-slp] Proposed SLS-SLP WG Spring 2013 Bordeaux Agenda Message-ID: Dear SLP members, Attached please find the proposed SLP WG agenda for the Spring 2013 CCSDS meetings in Bordeaux. Please let me know if you have any other agenda items or comments on this agenda. We are planning to meet on Tuesday, April 16, all day. Best regards, Greg Chairman CCSDS SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SLP_Bordeaux_Spring_2013.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 71512 bytes Desc: SLP_Bordeaux_Spring_2013.docx URL: From greg.j.kazz at jpl.nasa.gov Tue Mar 19 19:08:07 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 19 Mar 2013 19:08:07 +0000 Subject: [Sls-slp] Re: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS In-Reply-To: Message-ID: 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, Greg J (313B)" > Date: Thursday, March 14, 2013 1:22 PM To: Moury Gilles > Cc: "sls-sea-dls at mailman.ccsds.org" >, "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 > Date: Thursday, March 14, 2013 10:06 AM To: "Kazz, Greg J (313B)" > Cc: "Greenberg, Edward (313B)" >, "Biggerstaff, Craig (JSC-DD12)[LOCKHEED MARTIN CORP]" >, "sls-sea-dls at mailman.ccsds.org" >, "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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/applefile Size: 455 bytes Desc: not available URL: -------------- 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: From greg.j.kazz at jpl.nasa.gov Mon Mar 25 19:15:08 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Mon, 25 Mar 2013 19:15:08 +0000 Subject: [Sls-slp] Re: Improving CCSDS 130.0-G and Proximity-1 Services In-Reply-To: <1363941600.1986.7.camel@machine-r> Message-ID: Dear Marjorie and G.P., I recommend we adjust the NOTE under Section 3.2.3 in CCSDS 130.0-G to say: (identified between ** ** below) NOTE ­ The Proximity-1 Space Link Protocol is not included in this table because no formal service definition is given in the current Recommended Standards (references [18], [19]and [20]). ** In spite of not having a formal service definition, Proximity-1 can deliver the same SDUs delivered by the Packet Service, Encapsulation Service and the TC VCA Service. ** My concern is the classic mixing of "apples and oranges together". Yes, they are both fruit but they are not the same. So in TM, AOS, TC we have well defined and understood services. In Prox-1 we do not have defined services and we call them services. Better not to confuse the user in this Green book by putting all of these so called services together in this table. Better, I believe to acknowledge that Prox-1 is very similar to TC in terms of the SDUs it can transfer but better to see the details in the Prox-1 DLL book. To be discussed further in Bordeaux. Best regards, Greg On 3/22/13 1:40 AM, "Marjorie de Lande Long" wrote: >Dear Gian Paolo, > >I fully agree with what you say. The note could be mitigated as you >suggest. Or perhaps the Prox-1 services could be added to Table 3-2, and >the note could be changed to say that they have been included, even >though they do not have the same kind of formal definitions as the >services of TM, TC and AOS? > >Best regards, >Marjorie > > >On Tue, 2013-03-19 at 15:59 +0100, Gian.Paolo.Calzolari at esa.int wrote: >> Dear Marjorie, >> Dear Greg, >> CCSDS 130.0-G-2 (and the version under editing) states: >> Table 3-2 shows a summary of the services provided by the TM/TC/AOS >> Space Data Link Protocols categorized by the types of data transferred >> by the services. For complete definition of these services, refer to >> references [5], [6], and [7]. >> NOTE ­ The Proximity-1 Space Link Protocol is not included in this >> table because no service definition is given in the current >> Recommended Standards (references [18], [19] and [20]). >> >> From a certain point of view is true that Proximity-1 does not include >> a but at the same time looking at the >> following table 3-2 and considering that (see Proximity 1 DLL section >> 2.1.1) the Proximity-1 Data Link Layer delivers received service data >> units to the usersI wondered whether could (at least) mitigate that >> remark stating e.g. that Proximity 1 in spite of not having a formal >> service definition can deliver the same SDU's delivered by Packet >> Service, Encapsulation Service and TC VCA Service (i.e. in the order >> Space Packets, Encapsulation Packets and Variable length private data >> = Frame Data fields). >> >> Of course this should be somehow corroborated by some related/relevant >> text in Proximity-1 Data Link Layer Book even if this would not a >> formal service definition. >> I just note that in CCSDS 211.0-P-4.1 (i.e. the pink book that has >> undergone Agency Review) we find the following statements: >> * On the send side, it accepts user data consisting of Service >> Data Units (SDUs) and associated routing information. On the >> receive side it delivers SDUs to the users via frame >> designated Port IDs. (2.1.3.6 Input/Output Sublayer) >> * 2.1.4.2 Service Data Units /SDUs carry user data from >> applications in the sending node to applications in the >> receiving node. A frame with SDU data in its data field is >> called a user frame (U-frame). The data field of a U-frame can >> contain an integer number of unsegmented packets, a single >> packet segment, or a collection of user-provided octets. >> * 2.1.7 PROTOCOL DESCRIPTION /The Proximity-1 protocol is >> described in terms of: a) the services provided to the users >> (transfer of SDUs); b) the ................ >> * Proximity-1 provides users with data transfer services known >> as Space Data Link Proximity-1 services. When a user, such as >> the spacecraft vehicle controller, supplies an SDU for >> transfer, the user (2.2.1 COMMON FEATURES OF SERVICES) >> * The Proximity-1 protocol provides data transfer services and >> timing services. There are two data transfer services: the >> first accepts and delivers packets, while the second accepts >> and delivers user-defined data. (2.2.2.1 General) >> * 2.2.2.2 CCSDS Packet Delivery Service >> * 2.2.2.3 User Defined Data Delivery Service >> >> If the statement above are not sufficient to justify modifying the >> NOTE in 130.0-G, which simple additions/modifications could we >> identify? >> >> Your comments are much more than welcome! >> >> Ciao >> >> Gian Paolo >> >> >> PS I see that 2.2.2.2 opposite to 2.2.2.3 never mentions the term SDU. >> I think that a text addition in such a sense would be good. >> >> This message and any attachments are intended for the use of the >>addressee or addressees only. The unauthorised disclosure, use, >>dissemination or copying (either in whole or in part) of its content is >>not permitted. If you received this message in error, please notify the >>sender and delete it from your system. Emails can be altered and their >>integrity cannot be guaranteed by the sender. >> >> Please consider the environment before printing this email. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: default.xml Type: application/xml Size: 3222 bytes Desc: default.xml URL: From Gilles.Moury at cnes.fr Thu Mar 28 11:48:42 2013 From: Gilles.Moury at cnes.fr (Moury Gilles) Date: Thu, 28 Mar 2013 11:48:42 +0000 Subject: [Sls-slp] RE: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS In-Reply-To: References: Message-ID: <442F062EBF46F247A96B8A50EF3EB6F415383A83@TW-MBX-P04.cnesnet.ad.cnes.fr> 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 De : Kazz, Greg J (313B) [mailto:greg.j.kazz at jpl.nasa.gov] Envoyé : mardi 19 mars 2013 20:08 À : Moury Gilles Cc : sls-sea-dls at mailman.ccsds.org; sls-slp at mailman.ccsds.org Objet : Re: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS 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, Greg J (313B)" > Date: Thursday, March 14, 2013 1:22 PM To: Moury Gilles > Cc: "sls-sea-dls at mailman.ccsds.org" >, "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 > Date: Thursday, March 14, 2013 10:06 AM To: "Kazz, Greg J (313B)" > Cc: "Greenberg, Edward (313B)" >, "Biggerstaff, Craig (JSC-DD12)[LOCKHEED MARTIN CORP]" >, "sls-sea-dls at mailman.ccsds.org" >, "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: From greg.j.kazz at jpl.nasa.gov Fri Mar 29 18:05:48 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 29 Mar 2013 18:05:48 +0000 Subject: [Sls-slp] Re: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS In-Reply-To: <442F062EBF46F247A96B8A50EF3EB6F415383A83@TW-MBX-P04.cnesnet.ad.cnes.fr> Message-ID: 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 De : Kazz, Greg J (313B) [mailto:greg.j.kazz at jpl.nasa.gov] Envoyé : mardi 19 mars 2013 20:08 À : Moury Gilles Cc : sls-sea-dls at mailman.ccsds.org; sls-slp at mailman.ccsds.org Objet : Re: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS 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, Greg J (313B)" > Date: Thursday, March 14, 2013 1:22 PM To: Moury Gilles > Cc: "sls-sea-dls at mailman.ccsds.org" >, "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 > Date: Thursday, March 14, 2013 10:06 AM To: "Kazz, Greg J (313B)" > Cc: "Greenberg, Edward (313B)" >, "Biggerstaff, Craig (JSC-DD12)[LOCKHEED MARTIN CORP]" >, "sls-sea-dls at mailman.ccsds.org" >, "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: From greg.j.kazz at jpl.nasa.gov Fri Mar 29 21:14:48 2013 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Fri, 29 Mar 2013 21:14:48 +0000 Subject: [Sls-slp] Figures 6-c and 6-d involving SDLS i/f in TC, TM, and AOS Message-ID: Dear SLP, I have crafted a slightly different diagram for inclusion into the SDSL chapter into each SLP protocol book for Figures 6-c and 6-d. I prefer this one because it maintains all of the structure and lines of the previous diagrams from which they are based upon but still conveys the focus on the interface between SDLS functions and SLP functions. So far, I have only done this for the TC protocol as an example. For discussion at the SLP meeting in Bordeaux. 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_SDLS_SLP_Chap6_diagram.pdf Type: application/pdf Size: 146498 bytes Desc: TC_SDLS_SLP_Chap6_diagram.pdf URL: