From greg.j.kazz at jpl.nasa.gov Tue Mar 3 00:23:21 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 2 Mar 2009 16:23:21 -0800 Subject: [Sls-slp] JAXA RID against OID Frame Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F458E3BA015@ALTPHYEMBEVSP10.RES.AD.JPL> G.P. I think JAXA has a valid concern in the attached RID concerning the use of the term, OID, only idle data. I thought the purpose of using OID frame was to use the same terminology across all CCSDS space data link documents. But as pointed out in the rid, when we have an "Idle packet" it isn't called an OID packet, but rather and idle packet. So I am not sure that the term OID frame is consistent enough. Not that I am advocating the use of the term, OID packet at all. What do you think? JAXA rid below. thanks, Greg REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: JAXA-RPA830-01 SUBMITTING ORGANIZATION (Agency, Center): JAXA ------------------------------------------------------------------ REVIEWER'S NAME: Shigeyuki Furushima CODE: Mitsubishi Electric Corporation E-MAIL ADDRESS: jaxa.ccsds at jaxa.jp TELEPHONE: 29-868-2587 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 732.0-P-2.1 Pink Sheets, Issue 2.1 DOCUMENT NAME: AOS Space Data Link Protocol DATE ISSUED: December 2008 PAGE NUMBER: PARAGRAPH NUMBER: RID SHORT TITLE: The cange from "Idle Frame" to "OID Frame" (1) ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) It's not necessary to change "Idele frame" to "OID Frame" . The basis of suggestion is given below. 1. There is no change of definition in the recomendation. Changing word without changing definition will give rise to the confusion. 2. The purpose of this pink sheet is to clearfy the meaning of "idle." However, "Idle Packet" is not changed to "OID Packet." (See Page C-3, Table C-1) ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gian.Paolo.Calzolari at esa.int Tue Mar 3 09:25:56 2009 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Tue, 3 Mar 2009 10:25:56 +0100 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F458E3BA015@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: Greg, In Packet Telemetry the term "idle frame" was deprecated because it is posible that frame is not completely idle (opposite to the idle packet). An idle frame can in fact contain a valid CLCW or a valid secondary header. In such a sense: 1) discarding an idle frame may imply loosing valid data while 2) discarding an idle packet has no drawback. In CCSDS 732.0-B-2 I can read: -------------------------------------------- 4.1.2.3.2 The Virtual Channel Identifier shall be used to identify the Virtual Channel. NOTES ........... 3 A Transfer Frame on the ?Idle? Virtual Channel may not contain any valid user data within its Transfer Frame Data Field, but it must contain the Insert Zone if the Insert Service is supported. -------------------------------------------- 4.1.4.1.5 In the case where at release time ..................... NOTES 1 Transfer Frames containing Idle Data in their Data Fields are sent to maintain synchronization at the receiver and also to transmit data in the Transfer Frame Insert Zone when there is no Data Field to send. -------------------------------------------- Looking at Figure 4-1: AOS Transfer Frame Structural Components we see that an AOS frame may contain both an Insert Zone (equivalent to the Secondary header, I understand) and an Operational Control Field. Therefore the same reasoning of Packet TM do apply: An "idle frame" can contain (also) valid data (but not in the Data Field) while an Idle Packet does not contain any valid data -------------------------------------------- Marjorie is preparing a coordinate ESA position with respect to all those RIDs. Best regards Gian Paolo (*) Clearly for the CLCW - since the same CLCW is likely to be inserted in several frames - this would not happen if you have just one OID frame, but it could happen in a situation (that cannot be excluded a priori) where several OID frames are sent in sequence. In addition for the Secondary Header even a single frame could contain important data. "Kazz, Greg J" Sent by: sls-slp-bounces at mailman.ccsds.org 03-03-2009 01:23 To "Gian.Paolo.Calzolari at esa.int" cc "Greenberg, Edward" , "sls-slp at mailman.ccsds.org" , "Jean-Luc.Gerner at esa.int" , Takahiro Yamada , "gilles.moury at cnes.fr" Subject [Sls-slp] JAXA RID against OID Frame G.P. I think JAXA has a valid concern in the attached RID concerning the use of the term, OID, only idle data. I thought the purpose of using OID frame was to use the same terminology across all CCSDS space data link documents. But as pointed out in the rid, when we have an ?Idle packet? it isn?t called an OID packet, but rather and idle packet. So I am not sure that the term OID frame is consistent enough. Not that I am advocating the use of the term, OID packet at all. What do you think? JAXA rid below. thanks, Greg REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: JAXA-RPA830-01 SUBMITTING ORGANIZATION (Agency, Center): JAXA ------------------------------------------------------------------ REVIEWER'S NAME: Shigeyuki Furushima CODE: Mitsubishi Electric Corporation E-MAIL ADDRESS: jaxa.ccsds at jaxa.jp TELEPHONE: 29-868-2587 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 732.0-P-2.1 Pink Sheets, Issue 2.1 DOCUMENT NAME: AOS Space Data Link Protocol DATE ISSUED: December 2008 PAGE NUMBER: PARAGRAPH NUMBER: RID SHORT TITLE: The cange from "Idle Frame" to "OID Frame" (1) ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) It's not necessary to change "Idele frame" to "OID Frame" . The basis of suggestion is given below. 1. There is no change of definition in the recomendation. Changing word without changing definition will give rise to the confusion. 2. The purpose of this pink sheet is to clearfy the meaning of "idle." However, "Idle Packet" is not changed to "OID Packet." (See Page C-3, Table C-1) ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Mar 3 17:21:35 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Tue, 3 Mar 2009 09:21:35 -0800 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: References: <02D130BD9C29BB4AAD59B77342F7E25F458E3BA015@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F4599639769@ALTPHYEMBEVSP10.RES.AD.JPL> G.P., But a Space Packet can contain a Secondary Header, which could contain useful data as well. So in that sense, OID Packet also makes sense. In other words, discarding an "Idle Packet" can have a drawback or unintended consequence. CCSDS needs to use consistent terminology across the board and I think that is what this JAXA rid is pointing out. I am looking forward to Marjorie's responses to those rids as well. thanks, Greg ________________________________ From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Sent: Tuesday, March 03, 2009 1:26 AM To: Kazz, Greg J Cc: Greenberg, Edward; gilles.moury at cnes.fr; Jean-Luc.Gerner at esa.int; sls-slp at mailman.ccsds.org; sls-slp-bounces at mailman.ccsds.org; Takahiro Yamada Subject: Re: [Sls-slp] JAXA RID against OID Frame Greg, In Packet Telemetry the term "idle frame" was deprecated because it is posible that frame is not completely idle (opposite to the idle packet). An idle frame can in fact contain a valid CLCW or a valid secondary header. In such a sense: 1) discarding an idle frame may imply loosing valid data while 2) discarding an idle packet has no drawback. In CCSDS 732.0-B-2 I can read: -------------------------------------------- 4.1.2.3.2 The Virtual Channel Identifier shall be used to identify the Virtual Channel. NOTES ........... 3 A Transfer Frame on the 'Idle' Virtual Channel may not contain any valid user data within its Transfer Frame Data Field, but it must contain the Insert Zone if the Insert Service is supported. -------------------------------------------- 4.1.4.1.5 In the case where at release time ..................... NOTES 1 Transfer Frames containing Idle Data in their Data Fields are sent to maintain synchronization at the receiver and also to transmit data in the Transfer Frame Insert Zone when there is no Data Field to send. -------------------------------------------- Looking at Figure 4-1: AOS Transfer Frame Structural Components we see that an AOS frame may contain both an Insert Zone (equivalent to the Secondary header, I understand) and an Operational Control Field. Therefore the same reasoning of Packet TM do apply: An "idle frame" can contain (also) valid data (but not in the Data Field) while an Idle Packet does not contain any valid data -------------------------------------------- Marjorie is preparing a coordinate ESA position with respect to all those RIDs. Best regards Gian Paolo (*) Clearly for the CLCW - since the same CLCW is likely to be inserted in several frames - this would not happen if you have just one OID frame, but it could happen in a situation (that cannot be excluded a priori) where several OID frames are sent in sequence. In addition for the Secondary Header even a single frame could contain important data. "Kazz, Greg J" Sent by: sls-slp-bounces at mailman.ccsds.org 03-03-2009 01:23 To "Gian.Paolo.Calzolari at esa.int" cc "Greenberg, Edward" , "sls-slp at mailman.ccsds.org" , "Jean-Luc.Gerner at esa.int" , Takahiro Yamada , "gilles.moury at cnes.fr" Subject [Sls-slp] JAXA RID against OID Frame G.P. I think JAXA has a valid concern in the attached RID concerning the use of the term, OID, only idle data. I thought the purpose of using OID frame was to use the same terminology across all CCSDS space data link documents. But as pointed out in the rid, when we have an "Idle packet" it isn't called an OID packet, but rather and idle packet. So I am not sure that the term OID frame is consistent enough. Not that I am advocating the use of the term, OID packet at all. What do you think? JAXA rid below. thanks, Greg REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: JAXA-RPA830-01 SUBMITTING ORGANIZATION (Agency, Center): JAXA ------------------------------------------------------------------ REVIEWER'S NAME: Shigeyuki Furushima CODE: Mitsubishi Electric Corporation E-MAIL ADDRESS: jaxa.ccsds at jaxa.jp TELEPHONE: 29-868-2587 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 732.0-P-2.1 Pink Sheets, Issue 2.1 DOCUMENT NAME: AOS Space Data Link Protocol DATE ISSUED: December 2008 PAGE NUMBER: PARAGRAPH NUMBER: RID SHORT TITLE: The cange from "Idle Frame" to "OID Frame" (1) ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) It's not necessary to change "Idele frame" to "OID Frame" . The basis of suggestion is given below. 1. There is no change of definition in the recomendation. Changing word without changing definition will give rise to the confusion. 2. The purpose of this pink sheet is to clearfy the meaning of "idle." However, "Idle Packet" is not changed to "OID Packet." (See Page C-3, Table C-1) ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gian.Paolo.Calzolari at esa.int Tue Mar 3 18:20:49 2009 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Tue, 3 Mar 2009 19:20:49 +0100 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F4599639769@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: "Kazz, Greg J" wrote on 03-03-2009 18:21:35: > G.P., > > But a Space Packet can contain a Secondary Header, which could > contain useful data as well. So in that sense, OID Packet also makes > sense. In other words, discarding an ?Idle Packet? can have a > drawback or unintended consequence. CCSDS needs to use consistent > terminology across the board and I think that is what this JAXA rid > is pointing out. I am looking forward to Marjorie?s responses to > those rids as well. > > thanks, > > Greg > Greg, The Frame has a structure linked to the Virtual Channel and all frames on a VC have the secondary header (if this is used) independently they are OID or not. Conversely the Space Packet has a structure linked to the APID and a mission implementing a Packet Secondary Header on Idle Packets would just be crazy. :-) In addition, I think that, being the idle APID fixed, there is no chance for having a Secondary header in an Idle Packet [this is TBC]. Comments/confirmations are welcome. Ciao Gian Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From MCOSBY at qinetiq.com Wed Mar 4 09:59:21 2009 From: MCOSBY at qinetiq.com (Cosby Matthew) Date: Wed, 4 Mar 2009 09:59:21 -0000 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: References: <02D130BD9C29BB4AAD59B77342F7E25F4599639769@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: Greg, I agree with Gian Paolo. When our TM systems detect an Idle Packet (APID set to 0x7FF) it discards it. >From the TM Spec. 4.3.2.5 Extracted Packets shall be delivered to the users on the basis of the PVN in their header. Incomplete Packets are not required to be delivered in cross support situations. NOTE . Idle Packets are discarded. Data Fields that contain only Idle Data are also discarded. This states that the Idle Packet is discarded and implies that there is no user data within the packet. There probability isn't any where in the standard stating that you can't put a secondary header in the Idle Packet, but this is implied as this packet is thrown out. So quoting Gian Paolo it would be crazy to put any useful data into the idle packet. Regards, Matt. Matthew Cosby QinetiQ Bldg X107 Rm G003 Cody Technology Park Ively Road, Farnborough Hants, GU14 0LX Tel: 01252 396313 Email: mcosby at QinetiQ.com Fax: 01252 392969 Web: www.QinetiQ.com QinetiQ - The Global Defence and Security Experts P Please consider the environment before printing this email. ________________________________ From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Gian.Paolo.Calzolari at esa.int Sent: 03 March 2009 18:21 To: Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. (GSFC-583.0); Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr; Greenberg,Edward Subject: RE: [Sls-slp] JAXA RID against OID Frame "Kazz, Greg J" wrote on 03-03-2009 18:21:35: > G.P., > > But a Space Packet can contain a Secondary Header, which could > contain useful data as well. So in that sense, OID Packet also makes > sense. In other words, discarding an "Idle Packet" can have a > drawback or unintended consequence. CCSDS needs to use consistent > terminology across the board and I think that is what this JAXA rid > is pointing out. I am looking forward to Marjorie's responses to > those rids as well. > > thanks, > > Greg > Greg, The Frame has a structure linked to the Virtual Channel and all frames on a VC have the secondary header (if this is used) independently they are OID or not. Conversely the Space Packet has a structure linked to the APID and a mission implementing a Packet Secondary Header on Idle Packets would just be crazy. :-) In addition, I think that, being the idle APID fixed, there is no chance for having a Secondary header in an Idle Packet [this is TBC]. Comments/confirmations are welcome. Ciao Gian Paolo The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Wed Mar 4 11:02:54 2009 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward) Date: Wed, 4 Mar 2009 03:02:54 -0800 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: <200903040959.n249xPoQ020349@mail.jpl.nasa.gov> Message-ID: I agree with Matt and Gian Paolo. If you want to send a packet with a meaningful secondary header and no useful information thengive it an APID with that interpretation, not one that says it only contains idle data. Have a wonderful time discussing this trivia. On 3/4/09 1:59 AM, "Cosby Matthew" wrote: Greg, I agree with Gian Paolo. When our TM systems detect an Idle Packet (APID set to 0x7FF) it discards it. >From the TM Spec. 4.3.2.5 Extracted Packets shall be delivered to the users on the basis of the PVN in their header. Incomplete Packets are not required to be delivered in cross support situations. NOTE . Idle Packets are discarded. Data Fields that contain only Idle Data are also discarded. This states that the Idle Packet is discarded and implies that there is no user data within the packet. There probability isn't any where in the standard stating that you can't put a secondary header in the Idle Packet, but this is implied as this packet is thrown out. So quoting Gian Paolo it would be crazy to put any useful data into the idle packet. Regards, Matt. Matthew Cosby QinetiQ Bldg X107 Rm G003 Cody Technology Park Ively Road, Farnborough Hants, GU14 0LX Tel: 01252 396313 Email: mcosby at QinetiQ.com Fax: 01252 392969 Web: www.QinetiQ.com QinetiQ - The Global Defence and Security Experts P Please consider the environment before printing this email. ________________________________ From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Gian.Paolo.Calzolari at esa.int Sent: 03 March 2009 18:21 To: Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. (GSFC-583.0); Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr; Greenberg,Edward Subject: RE: [Sls-slp] JAXA RID against OID Frame "Kazz, Greg J" wrote on 03-03-2009 18:21:35: > G.P., > > But a Space Packet can contain a Secondary Header, which could > contain useful data as well. So in that sense, OID Packet also makes > sense. In other words, discarding an "Idle Packet" can have a > drawback or unintended consequence. CCSDS needs to use consistent > terminology across the board and I think that is what this JAXA rid > is pointing out. I am looking forward to Marjorie's responses to > those rids as well. > > thanks, > > Greg > Greg, The Frame has a structure linked to the Virtual Channel and all frames on a VC have the secondary header (if this is used) independently they are OID or not. Conversely the Space Packet has a structure linked to the APID and a mission implementing a Packet Secondary Header on Idle Packets would just be crazy. :-) In addition, I think that, being the idle APID fixed, there is no chance for having a Secondary header in an Idle Packet [this is TBC]. Comments/confirmations are welcome. Ciao Gian Paolo The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Wed Mar 4 16:26:05 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Wed, 4 Mar 2009 08:26:05 -0800 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: References: <200903040959.n249xPoQ020349@mail.jpl.nasa.gov> Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45996398EF@ALTPHYEMBEVSP10.RES.AD.JPL> You are all thinking very logically. But flight projects often cut corners and find all sorts of unusual and esoteric ways of utilizing the standards. Consensus on this matter seems to be, yes it is possible, but the limit of the probability of doing so approaches zero. Greg ________________________________ From: Greenberg, Edward Sent: Wednesday, March 04, 2009 3:03 AM To: Matt Cosby; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr Subject: Re: [Sls-slp] JAXA RID against OID Frame I agree with Matt and Gian Paolo. If you want to send a packet with a meaningful secondary header and no useful information thengive it an APID with that interpretation, not one that says it only contains idle data. Have a wonderful time discussing this trivia. On 3/4/09 1:59 AM, "Cosby Matthew" wrote: Greg, I agree with Gian Paolo. When our TM systems detect an Idle Packet (APID set to 0x7FF) it discards it. >From the TM Spec. 4.3.2.5 Extracted Packets shall be delivered to the users on the basis of the PVN in their header. Incomplete Packets are not required to be delivered in cross support situations. NOTE . Idle Packets are discarded. Data Fields that contain only Idle Data are also discarded. This states that the Idle Packet is discarded and implies that there is no user data within the packet. There probability isn't any where in the standard stating that you can't put a secondary header in the Idle Packet, but this is implied as this packet is thrown out. So quoting Gian Paolo it would be crazy to put any useful data into the idle packet. Regards, Matt. Matthew Cosby QinetiQ Bldg X107 Rm G003 Cody Technology Park Ively Road, Farnborough Hants, GU14 0LX Tel: 01252 396313 Email: mcosby at QinetiQ.com Fax: 01252 392969 Web: www.QinetiQ.com QinetiQ - The Global Defence and Security Experts P Please consider the environment before printing this email. ________________________________ From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Gian.Paolo.Calzolari at esa.int Sent: 03 March 2009 18:21 To: Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. (GSFC-583.0); Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr; Greenberg,Edward Subject: RE: [Sls-slp] JAXA RID against OID Frame "Kazz, Greg J" wrote on 03-03-2009 18:21:35: > G.P., > > But a Space Packet can contain a Secondary Header, which could > contain useful data as well. So in that sense, OID Packet also makes > sense. In other words, discarding an "Idle Packet" can have a > drawback or unintended consequence. CCSDS needs to use consistent > terminology across the board and I think that is what this JAXA rid > is pointing out. I am looking forward to Marjorie's responses to > those rids as well. > > thanks, > > Greg > Greg, The Frame has a structure linked to the Virtual Channel and all frames on a VC have the secondary header (if this is used) independently they are OID or not. Conversely the Space Packet has a structure linked to the APID and a mission implementing a Packet Secondary Header on Idle Packets would just be crazy. :-) In addition, I think that, being the idle APID fixed, there is no chance for having a Secondary header in an Idle Packet [this is TBC]. Comments/confirmations are welcome. Ciao Gian Paolo The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gian.Paolo.Calzolari at esa.int Wed Mar 4 16:39:37 2009 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 4 Mar 2009 17:39:37 +0100 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45996398EF@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: sls-slp-bounces at mailman.ccsds.org wrote on 04-03-2009 17:26:05: > You are all thinking very logically. But flight projects often cut > corners and find all sorts of unusual and esoteric ways of utilizing > the standards. OK Greg, this is true. However in the book we shall put the prescribed behavior and not bless the esoteric one. > Consensus on this matter seems to be, yes it is > possible, but the limit of the probability of doing so approaches zero. > > Greg > Ciao Gian Paolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Thu Mar 5 00:17:42 2009 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward) Date: Wed, 4 Mar 2009 16:17:42 -0800 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45996398EF@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: NO, Projects should not be allowed to get fill/idle/OID packets. OID frames on the other hand can contain insert data if managed for the physical channel (TM or AOS) On 3/4/09 8:26 AM, "Kazz, Greg J" wrote: You are all thinking very logically. But flight projects often cut corners and find all sorts of unusual and esoteric ways of utilizing the standards. Consensus on this matter seems to be, yes it is possible, but the limit of the probability of doing so approaches zero. Greg ________________________________ From: Greenberg, Edward Sent: Wednesday, March 04, 2009 3:03 AM To: Matt Cosby; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr Subject: Re: [Sls-slp] JAXA RID against OID Frame I agree with Matt and Gian Paolo. If you want to send a packet with a meaningful secondary header and no useful information thengive it an APID with that interpretation, not one that says it only contains idle data. Have a wonderful time discussing this trivia. On 3/4/09 1:59 AM, "Cosby Matthew" wrote: Greg, I agree with Gian Paolo. When our TM systems detect an Idle Packet (APID set to 0x7FF) it discards it. >From the TM Spec. 4.3.2.5 Extracted Packets shall be delivered to the users on the basis of the PVN in their header. Incomplete Packets are not required to be delivered in cross support situations. NOTE . Idle Packets are discarded. Data Fields that contain only Idle Data are also discarded. This states that the Idle Packet is discarded and implies that there is no user data within the packet. There probability isn't any where in the standard stating that you can't put a secondary header in the Idle Packet, but this is implied as this packet is thrown out. So quoting Gian Paolo it would be crazy to put any useful data into the idle packet. Regards, Matt. Matthew Cosby QinetiQ Bldg X107 Rm G003 Cody Technology Park Ively Road, Farnborough Hants, GU14 0LX Tel: 01252 396313 Email: mcosby at QinetiQ.com Fax: 01252 392969 Web: www.QinetiQ.com QinetiQ - The Global Defence and Security Experts P Please consider the environment before printing this email. ________________________________ From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Gian.Paolo.Calzolari at esa.int Sent: 03 March 2009 18:21 To: Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. (GSFC-583.0); Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr; Greenberg,Edward Subject: RE: [Sls-slp] JAXA RID against OID Frame "Kazz, Greg J" wrote on 03-03-2009 18:21:35: > G.P., > > But a Space Packet can contain a Secondary Header, which could > contain useful data as well. So in that sense, OID Packet also makes > sense. In other words, discarding an "Idle Packet" can have a > drawback or unintended consequence. CCSDS needs to use consistent > terminology across the board and I think that is what this JAXA rid > is pointing out. I am looking forward to Marjorie's responses to > those rids as well. > > thanks, > > Greg > Greg, The Frame has a structure linked to the Virtual Channel and all frames on a VC have the secondary header (if this is used) independently they are OID or not. Conversely the Space Packet has a structure linked to the APID and a mission implementing a Packet Secondary Header on Idle Packets would just be crazy. :-) In addition, I think that, being the idle APID fixed, there is no chance for having a Secondary header in an Idle Packet [this is TBC]. Comments/confirmations are welcome. Ciao Gian Paolo The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Thu Mar 5 00:34:13 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Wed, 4 Mar 2009 16:34:13 -0800 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: References: <02D130BD9C29BB4AAD59B77342F7E25F45996398EF@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F4599639A3C@ALTPHYEMBEVSP10.RES.AD.JPL> Ed, You are saying the service provider (DSN, SN, GN, ESA, etc) would not provide OID packets to the user. I agree. I was only saying that the way the standard is written today, it is possible for a project to think that they could put data into a packet secondary header of an OID packet and think it is a valid thing to do. Greg ________________________________ From: Greenberg, Edward Sent: Wednesday, March 04, 2009 4:18 PM To: Kazz, Greg J; Matt Cosby; Gian.Paolo.Calzolari at esa.int Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr Subject: Re: [Sls-slp] JAXA RID against OID Frame NO, Projects should not be allowed to get fill/idle/OID packets. OID frames on the other hand can contain insert data if managed for the physical channel (TM or AOS) On 3/4/09 8:26 AM, "Kazz, Greg J" wrote: You are all thinking very logically. But flight projects often cut corners and find all sorts of unusual and esoteric ways of utilizing the standards. Consensus on this matter seems to be, yes it is possible, but the limit of the probability of doing so approaches zero. Greg ________________________________ From: Greenberg, Edward Sent: Wednesday, March 04, 2009 3:03 AM To: Matt Cosby; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr Subject: Re: [Sls-slp] JAXA RID against OID Frame I agree with Matt and Gian Paolo. If you want to send a packet with a meaningful secondary header and no useful information thengive it an APID with that interpretation, not one that says it only contains idle data. Have a wonderful time discussing this trivia. On 3/4/09 1:59 AM, "Cosby Matthew" wrote: Greg, I agree with Gian Paolo. When our TM systems detect an Idle Packet (APID set to 0x7FF) it discards it. >From the TM Spec. 4.3.2.5 Extracted Packets shall be delivered to the users on the basis of the PVN in their header. Incomplete Packets are not required to be delivered in cross support situations. NOTE . Idle Packets are discarded. Data Fields that contain only Idle Data are also discarded. This states that the Idle Packet is discarded and implies that there is no user data within the packet. There probability isn't any where in the standard stating that you can't put a secondary header in the Idle Packet, but this is implied as this packet is thrown out. So quoting Gian Paolo it would be crazy to put any useful data into the idle packet. Regards, Matt. Matthew Cosby QinetiQ Bldg X107 Rm G003 Cody Technology Park Ively Road, Farnborough Hants, GU14 0LX Tel: 01252 396313 Email: mcosby at QinetiQ.com Fax: 01252 392969 Web: www.QinetiQ.com QinetiQ - The Global Defence and Security Experts P Please consider the environment before printing this email. ________________________________ From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Gian.Paolo.Calzolari at esa.int Sent: 03 March 2009 18:21 To: Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. (GSFC-583.0); Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr; Greenberg,Edward Subject: RE: [Sls-slp] JAXA RID against OID Frame "Kazz, Greg J" wrote on 03-03-2009 18:21:35: > G.P., > > But a Space Packet can contain a Secondary Header, which could > contain useful data as well. So in that sense, OID Packet also makes > sense. In other words, discarding an "Idle Packet" can have a > drawback or unintended consequence. CCSDS needs to use consistent > terminology across the board and I think that is what this JAXA rid > is pointing out. I am looking forward to Marjorie's responses to > those rids as well. > > thanks, > > Greg > Greg, The Frame has a structure linked to the Virtual Channel and all frames on a VC have the secondary header (if this is used) independently they are OID or not. Conversely the Space Packet has a structure linked to the APID and a mission implementing a Packet Secondary Header on Idle Packets would just be crazy. :-) In addition, I think that, being the idle APID fixed, there is no chance for having a Secondary header in an Idle Packet [this is TBC]. Comments/confirmations are welcome. Ciao Gian Paolo The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Thu Mar 5 02:48:55 2009 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward) Date: Wed, 4 Mar 2009 18:48:55 -0800 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F4599639A3C@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: So if you can read the spec and think that a project can do that then write it into the spec that you can't do that. On 3/4/09 4:34 PM, "Kazz, Greg J" wrote: Ed, You are saying the service provider (DSN, SN, GN, ESA, etc) would not provide OID packets to the user. I agree. I was only saying that the way the standard is written today, it is possible for a project to think that they could put data into a packet secondary header of an OID packet and think it is a valid thing to do. Greg ________________________________ From: Greenberg, Edward Sent: Wednesday, March 04, 2009 4:18 PM To: Kazz, Greg J; Matt Cosby; Gian.Paolo.Calzolari at esa.int Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr Subject: Re: [Sls-slp] JAXA RID against OID Frame NO, Projects should not be allowed to get fill/idle/OID packets. OID frames on the other hand can contain insert data if managed for the physical channel (TM or AOS) On 3/4/09 8:26 AM, "Kazz, Greg J" wrote: You are all thinking very logically. But flight projects often cut corners and find all sorts of unusual and esoteric ways of utilizing the standards. Consensus on this matter seems to be, yes it is possible, but the limit of the probability of doing so approaches zero. Greg ________________________________ From: Greenberg, Edward Sent: Wednesday, March 04, 2009 3:03 AM To: Matt Cosby; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr Subject: Re: [Sls-slp] JAXA RID against OID Frame I agree with Matt and Gian Paolo. If you want to send a packet with a meaningful secondary header and no useful information thengive it an APID with that interpretation, not one that says it only contains idle data. Have a wonderful time discussing this trivia. On 3/4/09 1:59 AM, "Cosby Matthew" wrote: Greg, I agree with Gian Paolo. When our TM systems detect an Idle Packet (APID set to 0x7FF) it discards it. >From the TM Spec. 4.3.2.5 Extracted Packets shall be delivered to the users on the basis of the PVN in their header. Incomplete Packets are not required to be delivered in cross support situations. NOTE . Idle Packets are discarded. Data Fields that contain only Idle Data are also discarded. This states that the Idle Packet is discarded and implies that there is no user data within the packet. There probability isn't any where in the standard stating that you can't put a secondary header in the Idle Packet, but this is implied as this packet is thrown out. So quoting Gian Paolo it would be crazy to put any useful data into the idle packet. Regards, Matt. Matthew Cosby QinetiQ Bldg X107 Rm G003 Cody Technology Park Ively Road, Farnborough Hants, GU14 0LX Tel: 01252 396313 Email: mcosby at QinetiQ.com Fax: 01252 392969 Web: www.QinetiQ.com QinetiQ - The Global Defence and Security Experts P Please consider the environment before printing this email. ________________________________ From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Gian.Paolo.Calzolari at esa.int Sent: 03 March 2009 18:21 To: Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. (GSFC-583.0); Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr; Greenberg,Edward Subject: RE: [Sls-slp] JAXA RID against OID Frame "Kazz, Greg J" wrote on 03-03-2009 18:21:35: > G.P., > > But a Space Packet can contain a Secondary Header, which could > contain useful data as well. So in that sense, OID Packet also makes > sense. In other words, discarding an "Idle Packet" can have a > drawback or unintended consequence. CCSDS needs to use consistent > terminology across the board and I think that is what this JAXA rid > is pointing out. I am looking forward to Marjorie's responses to > those rids as well. > > thanks, > > Greg > Greg, The Frame has a structure linked to the Virtual Channel and all frames on a VC have the secondary header (if this is used) independently they are OID or not. Conversely the Space Packet has a structure linked to the APID and a mission implementing a Packet Secondary Header on Idle Packets would just be crazy. :-) In addition, I think that, being the idle APID fixed, there is no chance for having a Secondary header in an Idle Packet [this is TBC]. Comments/confirmations are welcome. Ciao Gian Paolo The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From marjorie at delandelong.com Thu Mar 5 08:54:04 2009 From: marjorie at delandelong.com (Marjorie de Lande Long) Date: Thu, 05 Mar 2009 09:54:04 +0100 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F4599639A3C@ALTPHYEMBEVSP10.RES.AD.JPL> References: <02D130BD9C29BB4AAD59B77342F7E25F45996398EF@ALTPHYEMBEVSP10.RES.AD.JPL> <02D130BD9C29BB4AAD59B77342F7E25F4599639A3C@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: <1236243244.5642.14.camel@dhcppc2> Greg and everyone, > the way the standard is written today, it is possible for a project to > think that they could put data into a packet secondary header of an > OID packet and think it is a valid thing to do. An Idle Packet for the Space Packet Protocol really is Idle. It is not permitted to have a Packet Secondary Header. The standard (133.0-B-1, September 2003) is clear on this point. Section 4.1.2.3.3.4 says "The Secondary Header Flag shall be set to '0' for Idle Packets." and a Note in 4.1.3.2.1.4 says "The Packet Secondary Header is not allowed for Idle Packets." This requirement was inherited from the old Blue Books (now Silver). For example, 102.0-B-5 ("Packet Telemetry") says in section 3.1.2.2.d "The Packet Secondary Header Flag shall be set to "0" for Idle Packets." Best regards, Marjorie On Wed, 2009-03-04 at 16:34 -0800, Kazz, Greg J wrote: > Ed, > > > > You are saying the service provider (DSN, SN, GN, ESA, etc) would not > provide OID packets to the user. I agree. I was only saying that the > way the standard is written today, it is possible for a project to > think that they could put data into a packet secondary header of an > OID packet and think it is a valid thing to do. > > > > Greg > > > > > ______________________________________________________________________ > From: Greenberg, Edward > Sent: Wednesday, March 04, 2009 4:18 PM > To: Kazz, Greg J; Matt Cosby; Gian.Paolo.Calzolari at esa.int > Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; > Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; > gilles.moury at cnes.fr > Subject: Re: [Sls-slp] JAXA RID against OID Frame > > > > > NO, Projects should not be allowed to get fill/idle/OID packets. > OID frames on the other hand can contain insert data if managed > for the physical channel (TM or AOS) > > > On 3/4/09 8:26 AM, "Kazz, Greg J" wrote: > > You are all thinking very logically. But flight projects often cut > corners and find all sorts of unusual and esoteric ways of utilizing > the standards. Consensus on this matter seems to be, yes it is > possible, but the limit of the probability of doing so approaches > zero. > > Greg > > > > ______________________________________________________________________ > From: Greenberg, Edward > Sent: Wednesday, March 04, 2009 3:03 AM > To: Matt Cosby; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J > Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; > Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; > gilles.moury at cnes.fr > Subject: Re: [Sls-slp] JAXA RID against OID Frame > > I agree with Matt and Gian Paolo. If you want to send a packet with a > meaningful secondary header and no useful information thengive it an > APID with that interpretation, not one that says it only contains idle > data. Have a wonderful time discussing this trivia. > > > On 3/4/09 1:59 AM, "Cosby Matthew" wrote: > Greg, > > I agree with Gian Paolo. > > When our TM systems detect an Idle Packet (APID set to 0x7FF) it > discards it. > > >From the TM Spec. > 4.3.2.5 Extracted Packets shall be delivered to the users on the basis > of the PVN in their header. Incomplete Packets are not required to be > delivered in cross support situations. > > NOTE . Idle Packets are discarded. Data Fields that contain only Idle > Data are also discarded. > > This states that the Idle Packet is discarded and implies that there > is no user data within the packet. There probability isn’t any where > in the standard stating that you can’t put a secondary header in the > Idle Packet, but this is implied as this packet is thrown out. So > quoting Gian Paolo it would be crazy to put any useful data into the > idle packet. > > Regards, > > Matt. > > Matthew Cosby > > QinetiQ > Bldg X107 Rm G003 > Cody Technology Park > Ively Road, Farnborough > Hants, GU14 0LX > > Tel: 01252 396313 > Email: mcosby at QinetiQ.com > Fax: 01252 392969 > Web: www.QinetiQ.com <http://www.qinetiq.com> > QinetiQ - The Global Defence and Security Experts > > P Please consider the environment before printing this email. > > > ______________________________________________________________________ > From: sls-slp-bounces at mailman.ccsds.org > [mailto:sls-slp-bounces at mailman.ccsds.org] > <mailto:sls-slp-bounces at mailman.ccsds.org%5d> On Behalf Of > Gian.Paolo.Calzolari at esa.int > Sent: 03 March 2009 18:21 > To: Kazz, Greg J > Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. > (GSFC-583.0); Jean-Luc.Gerner at esa.int; > sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr; > Greenberg,Edward > Subject: RE: [Sls-slp] JAXA RID against OID Frame > > > > "Kazz, Greg J" wrote on 03-03-2009 > 18:21:35: > > > G.P., > > > > But a Space Packet can contain a Secondary Header, which could > > contain useful data as well. So in that sense, OID Packet also makes > > sense. In other words, discarding an “Idle Packet” can have a > > drawback or unintended consequence. CCSDS needs to use consistent > > terminology across the board and I think that is what this JAXA rid > > is pointing out. I am looking forward to Marjorie’s responses to > > those rids as well. > > > > thanks, > > > > Greg > > > > Greg, > The Frame has a structure linked to the Virtual Channel and all > frames on a VC have the secondary header (if this is used) > independently they are OID or not. > Conversely the Space Packet has a structure linked to the APID and a > mission implementing a Packet Secondary Header on Idle Packets would > just be crazy. :-) In addition, I think that, being the idle APID > fixed, there is no chance for having a Secondary header in an Idle > Packet [this is TBC]. > > Comments/confirmations are welcome. > > Ciao > > Gian Paolo > The information contained in this E-Mail and any subsequent > correspondence is private and is intended solely for the intended > recipient(s). The information in this communication may be > confidential and/or legally privileged. Nothing in this e-mail is > intended to conclude a contract on behalf of QinetiQ or make QinetiQ > subject to any other legally binding commitments, unless the e-mail > contains an express statement to the contrary or incorporates a formal > Purchase Order. > > For those other than the recipient any disclosure, copying, > distribution, or any action taken or omitted to be taken in reliance > on such information is prohibited and may be unlawful. > > Emails and other electronic communication with QinetiQ may be > monitored and recorded for business purposes including security, > audit > and archival purposes. Any response to this email indicates consent > to this. > > Telephone calls to QinetiQ may be monitored or recorded for quality > control, security and other business purposes. > > QinetiQ Limited > Registered in England & Wales: Company Number:3796233 > Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom > Trading address: Cody Technology Park, Cody Building, Ively Road, > Farnborough, Hampshire, GU14 0LX, United Kingdom > http://www.qinetiq.com/home/notices/legal.html > <http://www.QinetiQ.com/home/legal.html> > > > > > > > > _______________________________________________ > Sls-slp mailing list > Sls-slp at mailman.ccsds.org > http://mailman.ccsds.org/mailman/listinfo/sls-slp From greg.j.kazz at jpl.nasa.gov Thu Mar 5 17:03:41 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Thu, 5 Mar 2009 09:03:41 -0800 Subject: [Sls-slp] JAXA RID against OID Frame In-Reply-To: References: <02D130BD9C29BB4AAD59B77342F7E25F4599639A3C@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F4599639AAD@ALTPHYEMBEVSP10.RES.AD.JPL> That is our plan. thanks, Greg ________________________________ From: Greenberg, Edward Sent: Wednesday, March 04, 2009 6:49 PM To: Kazz, Greg J; Matt Cosby; Gian.Paolo.Calzolari at esa.int Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr Subject: Re: [Sls-slp] JAXA RID against OID Frame So if you can read the spec and think that a project can do that then write it into the spec that you can't do that. On 3/4/09 4:34 PM, "Kazz, Greg J" wrote: Ed, You are saying the service provider (DSN, SN, GN, ESA, etc) would not provide OID packets to the user. I agree. I was only saying that the way the standard is written today, it is possible for a project to think that they could put data into a packet secondary header of an OID packet and think it is a valid thing to do. Greg ________________________________ From: Greenberg, Edward Sent: Wednesday, March 04, 2009 4:18 PM To: Kazz, Greg J; Matt Cosby; Gian.Paolo.Calzolari at esa.int Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr Subject: Re: [Sls-slp] JAXA RID against OID Frame NO, Projects should not be allowed to get fill/idle/OID packets. OID frames on the other hand can contain insert data if managed for the physical channel (TM or AOS) On 3/4/09 8:26 AM, "Kazz, Greg J" wrote: You are all thinking very logically. But flight projects often cut corners and find all sorts of unusual and esoteric ways of utilizing the standards. Consensus on this matter seems to be, yes it is possible, but the limit of the probability of doing so approaches zero. Greg ________________________________ From: Greenberg, Edward Sent: Wednesday, March 04, 2009 3:03 AM To: Matt Cosby; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY; Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr Subject: Re: [Sls-slp] JAXA RID against OID Frame I agree with Matt and Gian Paolo. If you want to send a packet with a meaningful secondary header and no useful information thengive it an APID with that interpretation, not one that says it only contains idle data. Have a wonderful time discussing this trivia. On 3/4/09 1:59 AM, "Cosby Matthew" wrote: Greg, I agree with Gian Paolo. When our TM systems detect an Idle Packet (APID set to 0x7FF) it discards it. >From the TM Spec. 4.3.2.5 Extracted Packets shall be delivered to the users on the basis of the PVN in their header. Incomplete Packets are not required to be delivered in cross support situations. NOTE . Idle Packets are discarded. Data Fields that contain only Idle Data are also discarded. This states that the Idle Packet is discarded and implies that there is no user data within the packet. There probability isn't any where in the standard stating that you can't put a secondary header in the Idle Packet, but this is implied as this packet is thrown out. So quoting Gian Paolo it would be crazy to put any useful data into the idle packet. Regards, Matt. Matthew Cosby QinetiQ Bldg X107 Rm G003 Cody Technology Park Ively Road, Farnborough Hants, GU14 0LX Tel: 01252 396313 Email: mcosby at QinetiQ.com Fax: 01252 392969 Web: www.QinetiQ.com QinetiQ - The Global Defence and Security Experts P Please consider the environment before printing this email. ________________________________ From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Gian.Paolo.Calzolari at esa.int Sent: 03 March 2009 18:21 To: Kazz, Greg J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J. (GSFC-583.0); Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr; Greenberg,Edward Subject: RE: [Sls-slp] JAXA RID against OID Frame "Kazz, Greg J" wrote on 03-03-2009 18:21:35: > G.P., > > But a Space Packet can contain a Secondary Header, which could > contain useful data as well. So in that sense, OID Packet also makes > sense. In other words, discarding an "Idle Packet" can have a > drawback or unintended consequence. CCSDS needs to use consistent > terminology across the board and I think that is what this JAXA rid > is pointing out. I am looking forward to Marjorie's responses to > those rids as well. > > thanks, > > Greg > Greg, The Frame has a structure linked to the Virtual Channel and all frames on a VC have the secondary header (if this is used) independently they are OID or not. Conversely the Space Packet has a structure linked to the APID and a mission implementing a Packet Secondary Header on Idle Packets would just be crazy. :-) In addition, I think that, being the idle APID fixed, there is no chance for having a Secondary header in an Idle Packet [this is TBC]. Comments/confirmations are welcome. Ciao Gian Paolo The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Fri Mar 6 22:18:13 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Fri, 6 Mar 2009 14:18:13 -0800 Subject: [Sls-slp] FW: [SLS=CC] Spring Meetings 2009 Information Overview & Registration Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F4599639CFE@ALTPHYEMBEVSP10.RES.AD.JPL> Please register for the CCSDS Spring Meetings using the URL below. thanks, Greg Kazz Chairman CCSDS SLS-SLP, SLS-NGU, SIS-IPO ________________________________ From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Sent: Friday, March 06, 2009 1:59 PM To: SLS Channel Coding Working Groups Cc: Jean-Luc.Gerner at esa.int; Gilles Moury; Kazz, Greg J; Kiely, Aaron B; Enrico.Vassallo at esa.int Subject: [SLS=CC] Spring Meetings 2009 Information Overview & Registration See http://public.ccsds.org/meetings/2009Spring/default.aspx for the Spring Meetings 2009 Information Overview & register ASAP Best regards ____________________________________________ Gian Paolo Calzolari Systems Engineer, OPS-OT European Space Agency ESA/ESOC Robert Bosch Str. 5 D-64293-Darmstadt Tel +49-6151-902913 fax +49-6151-903046 http://www.esa.int/esoc Email: Gian.Paolo.Calzolari[at]esa.int [replace [at] with @ for the correct e-mail address] ____________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Mar 17 17:37:28 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Tue, 17 Mar 2009 10:37:28 -0700 Subject: [Sls-slp] Updated Version of Space Link Protocols Pink Sheet for Colorado Springs Meeting Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45998BE949@ALTPHYEMBEVSP10.RES.AD.JPL> Dear SLS-SLP and SIS-IPO WGs, Based upon the comments I have received to date on the agency review of the pink sheet I have updated the pink sheet. Note that no technical change has been made to the pink sheet which completed agency review on 1/23/09. There are a few syntactical and descriptive changes which make the pink sheet more readable and understandable. These pink sheets available now in the SLS-SLP public folder at:http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS%2dSLP%2fDraft%20Documents&FolderCTID=&View=%7b16ACDA38%2dFFA3%2d4657%2d8F27%2dB166C23C24A2%7d The file name is: 135x0p302[working]-gjk3_17-09.doc CCSDS 135.0-P-3.1 Space Link Identifiers - this change concerns the addition of Annex A introducing the CCSDS IP Extension (IPE) shim byte(s) allowing for future expansion of IP PDUs and their enumerations. The pink sheets is on the agenda for discussion both at the SIS-IPO and SLS-SLP WG meetings in Colorado Springs (April 20-25, 2009). Best regards, Greg Kazz Chairman CCSDS SLS-SLP, SIS-IPO WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Mon Mar 23 15:54:53 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 23 Mar 2009 08:54:53 -0700 Subject: FW: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45998BEE0B@ALTPHYEMBEVSP10.RES.AD.JPL> All, For discussion at the SLS-SLP WG meeting on Friday AM April 24 at Colorado Springs, CO best regards, Greg ________________________________ From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Sent: Sunday, March 22, 2009 11:15 AM To: Kazz, Greg J Cc: Chris.Taylor at esa.int; Jean-Luc.Gerner at esa.int; Marjorie de Lande Long Subject: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets Greg, the following responses to Jaxa RIDs have been discussed with Chris and Marjorie. Please consider these responses as ESA input for the discussion of the RIDs. Ciao Gian Paolo ======================================================================== RID JAXA-RPA830-01 1) An Idle Packet carries no useful data: This applies to an Idle Space Packet and to an Idle (or Fill) Encapsulation Packet (see below). However, the AOS Insert Service uses the Insert Field of every Transfer Frame on the Physical Channel, including the Idle Frames. Therefore, an Idle Frame can carry useful data so the name "Idle Frame" is not fully appropriate. The Pink Sheets provide the new name "OID Frame". 2) The term "OID Frame" is being introduced to AOS Space Data Link Protocol for consistency with the existing term used for the TM Space Data Link Protocol. See section 4.1.2.7.6.5 of CCSDS 132.0-B-1, September 2003. 3) The term "Idle Frame" was first introduced for AOS by the publication of the restructured Blue Book CCSDS 732.0-B-1 in September 2003: see Table C-1. 4) There is a related editorial error in 4.1.4.2.4.4. The Note 4 at the end of 4.1.4.2.4.4 contains a reference to [4] (Space Link IDs) which should be [6] (Space Packet Protocol) for the specification of the Idle Packet. 5) The change to section 4.2.2.5 mentions the "Fill Encapsulation Packet". The Pink Sheets for the Encapsulation Service will change the name to "Idle Encapsulation Packet". Therefore, 4.2.2.5 could also use the new name. Idle Packets 1) Idle Packet for Space Packet Protocol: In 133.0-B-1, section 4.1.2.3.3.4 says that the Secondary Header Flag must be 0 for Idle Packets. And a note in 4.1.3.2.1.4 says "The Packet Secondary Header is not allowed for Idle Packets." 2) Idle (or Fill) Encapsulation Packet: The data area (Encapsulated Data Field) contains idle data. The Encapsulation Packet Header has no optional secondary fields for carrying extra data. RID JAXA-RPA830-02 1) The RID says the descriptive phrase is unnecessary. But the phrase is in a Note, so there is no formal duplication. The phrase could help the reader understand the meaning of "OID" and it provides a reference to the location of the formal specification of the OID Frame. 2) It would be an improvement if the text was changed from "see 4.1.4" to "see 4.1.4.1.5". RID JAXA-RPA830-03 1) Section 4.1.4.2.4.2 does not define the term "idle pattern". It uses the term "idle pattern" in order to define the meaning of "Idle Data". 2) Apart from the "OID" name change, the new Note 3 is the only change introduced to section 4.1.4.1.5. Note 3 does not alter the specification of "Idle Data", but adds a suggestion that it should have a random pattern, and it explains why. This does not conflict with the other details specified for the Idle Data, in 4.1.4.1.5 or elsewhere in 732.0-B. RID JAXA-RPA830-04 1) The name change in TM and AOS protocols (132.0-B and 732.0-B) from "Packet Service" to "Virtual Channel Packet Service" is consistent with the "Virtual Channel Packet Service" of the TC protocol (232.0-B). The TM and AOS protocols do not use MAPs, so their renamed Virtual Channel Packet Services place the packets into frames. 2) In 732.0-B (AOS), it might be helpful to remove GMAP ID, MAP ID, MAP, MAPA and MAPP from the list of acronyms in Annex A, because they are not used for the AOS protocol. 3) In 132.0-B (TM), it might be helpful to remove GMAP ID from the list of acronyms in Annex A, because it is not used for the TM protocol. RID JAXA-RPA830-05 The RID says it could be confusing to continue to use the term "Packet Service" in AOS and TM protocols (there is a note about this at the end of Table 2-1). The intention of the Pink Sheets has been to replace all instances of "Packet Service" in the text of 132.0-B and 732.0-B to "Virtual Channel Packet Service" or "VCP Service". However, there are some Figures containing the words "Packet Service", and these have not been changed. The note was added to Table 2-1 as explanation. Therefore, it would be a good idea to ask the CCSDS Editor to replace "Packet Service" with "VCP Service" in the Figures, and to remove the note from Table 2-1. [This suggested change applies to 132.0-B and to 732.0-B.] =========================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Mon Mar 23 15:56:09 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 23 Mar 2009 08:56:09 -0700 Subject: [Sls-slp] FW: APID definition for Space Packet Protocol: RID responses and Draft text from ESA Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45998BEE0C@ALTPHYEMBEVSP10.RES.AD.JPL> All, Also for discussion at the SLS-SLP WG meetings in Colorado Springs, CO best regards, Greg ________________________________ From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Sent: Sunday, March 22, 2009 11:37 AM To: Kazz, Greg J Cc: Jean-Luc.Gerner at esa.int; Marjorie de Lande Long; Gian.Paolo.Calzolari at esa.int; Chris.Taylor; Shames, Peter M; Dai Stanton Subject: APID definition for Space Packet Protocol: RID responses and Draft text from ESA Greg, the following responses to RIDs have been discussed with Chris and Marjorie. The proposed text for the RID responses is shown below and is also in the attached text file. You find here attached also (our Draft 3 version) of the amendments to the SPP Blue Book. Please consider these responses as ESA input for the discussion of the RIDs. I hope we will be have to have a proper discussion in Colorado Springs (Peter, will you be there, please?) to finalize this publication of Pink Sheets. Ciao Gian Paolo __________________ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Responses to RIDs SEA-001 to -004 on SPP Pink Sheets: March 2009 SEA-001 Summary of the RID: Remove TM and TC books from normative references in section 1.7. Suggested disposition: Accept Suggested text for disposition: If 133.0-B is changed as proposed in response to RIDs SEA-002 and -003, then there will be no normative references to these TM and TC books and they can be removed from the list in section 1.7. References to these books will be kept in the informative references in Annex B (now Annex C). SEA-002 Summary of the RID: Remove the two paragraphs, added by the Pink Sheets, from section 2.1.1, immediately above Figure 2-1. Suggested disposition: Accept Suggested text for disposition: The existing text in sections 2.1.1. and 2.1.3 has led to misunderstandings about the use of the APID and the APID Qualifier to provide the Path ID of an LDP. Revised text is being proposed for sections 2.1.1 and 2.1.3. The revised text omits the paragraphs covered by the RID. [A draft of 133.0-B containing the proposed text is being sent to the SLS-SLP Chair.] SEA-003 Summary of the RID: Replace the two new sections 4.1.2.3.4.3 and 4.1.2.3.4.4 with a single new requirement that avoids the normative references to the TM and TC books. Suggested disposition: Accept Suggested text for disposition: The proposed wording for the new section 4.1.2.3.4.3 is: "The APID may uniquely identify the individual sending or receiving application process within a particular space vehicle." SEA-004 Summary of the RID: Add a sentence to the new section 4.1.3.3.5, to say that the presence of the error control field is established by management. Suggested disposition: Accept Suggested text for disposition: It is proposed to add a new sentence to the end of section 4.1.3.3.5. The first part of the sentence adds the suggestion from the RID. The field needs to be static, so that is included in the sentence as well: "The presence of the Packet Error Control Field shall be established by management and shall be fixed for a given Path ID throughout all Mission Phases." The Pink Sheets already contain an amendment to add the Packet Error Control Field to the managed parameters in Table 5-1. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 133x0LDPdraft3.doc Type: application/octet-stream Size: 378368 bytes Desc: 133x0LDPdraft3.doc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RIDresponsesDraft1.txt URL: From greg.j.kazz at jpl.nasa.gov Mon Mar 23 18:55:21 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 23 Mar 2009 11:55:21 -0700 Subject: FW: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45998BEE88@ALTPHYEMBEVSP10.RES.AD.JPL> All, The problem with the term, "OID Frame" or "Only Idle Data" Frame is that it still doesn't clearly convey the fact that the PAYLOAD or FRAME DATA FIELD of the frame contains idle data, and that other fields of the transfer frame such as Insert Zone (AOS), Frame Secondary Header (TM), or OCF (all) DO NOT contain Idle data. Until we have a clear way of specifying that concept, we haven't really made progress unfortunately. So I believe the distinction we are trying to make is about frames that contain idle data in the Frame Data Field, therefore 'FDFI' Frame for 'Frame Data Field Idle'. Your comments? thanks, Greg ________________________________ From: Greenberg, Edward Sent: Monday, March 23, 2009 9:03 AM To: Kazz, Greg J Subject: Re: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets OID is Only Idle Data. If frame contains Insert Data then it isn't OID. You could call it NFDI for No Frame Data Included On 3/23/09 8:54 AM, "Kazz, Greg J" wrote: 1) An Idle Packet carries no useful data: This applies to an Idle Space Packet and to an Idle (or Fill) Encapsulation Packet (see below). However, the AOS Insert Service uses the Insert Field of every Transfer Frame on the Physical Channel, including the Idle Frames. Therefore, an Idle Frame can carry useful data so the name "Idle Frame" is not fully appropriate. The Pink Sheets provide the new name "OID Frame". -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gian.Paolo.Calzolari at esa.int Tue Mar 24 23:11:45 2009 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 25 Mar 2009 00:11:45 +0100 Subject: FW: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45998BEE88@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: ?OID Frame? = ?Only Idle Data_field? Frame :-) ?FDFI? Frame for ?Frame Data Field Idle? Frame looks recursive :-) More correct would be "Only Idle Data in Data Field" Frame = OIDDF Frame We shall set the same term everywhere. Idle Frame is misleading. OID is not perfect but more correct and already defined for Packet TM Frame. Then the simplest is to say that OID Frame is a short form for OIDDF Frame. Let's discuss it in Colorado otherwise we enter in a loop. Ciao Gian Paolo sls-slp-bounces at mailman.ccsds.org wrote on 23-03-2009 19:55:21: > All, > > The problem with the term, ?OID Frame? or ?Only Idle Data? Frame is > that it still doesn?t clearly convey the fact that the PAYLOAD or > FRAME DATA FIELD of the frame contains idle data, and that other > fields of the transfer frame such as Insert Zone (AOS), Frame > Secondary Header (TM), or OCF (all) DO NOT contain Idle data. > Until we have a clear way of specifying that concept, we haven?t > really made progress unfortunately. > > So I believe the distinction we are trying to make is about frames > that contain idle data in the Frame Data Field, therefore ?FDFI? > Frame for ?Frame Data Field Idle?. > > Your comments? > > thanks, > Greg > > > From: Greenberg, Edward > Sent: Monday, March 23, 2009 9:03 AM > To: Kazz, Greg J > Subject: Re: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets > > OID is Only Idle Data. If frame contains Insert Data then it isn?t > OID. You could call it NFDI for No Frame Data Included > > > On 3/23/09 8:54 AM, "Kazz, Greg J" wrote: > 1) An Idle Packet carries no useful data: This applies to an Idle Space > Packet and to an Idle (or Fill) Encapsulation Packet (see below). > However, the AOS Insert Service uses the Insert Field of every Transfer > Frame on the Physical Channel, including the Idle Frames. Therefore, an > Idle Frame can carry useful data so the name "Idle Frame" is not fully > appropriate. The Pink Sheets provide the new name "OID Frame". > _______________________________________________ > Sls-slp mailing list > Sls-slp at mailman.ccsds.org > http://mailman.ccsds.org/mailman/listinfo/sls-slp -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Tue Mar 24 23:28:05 2009 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward) Date: Tue, 24 Mar 2009 16:28:05 -0700 Subject: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets In-Reply-To: Message-ID: We only need these frames for synchronous links to maintain the link synchronicity. So how about Synchronously Inserted Idle Data Frame or SIID Frame. The term only is very misleading. Or Synchronously Inserted Frame with Idle Data SIFID or is an acronym with more than 3 letters verboten. On 3/24/09 4:11 PM, "Gian.Paolo.Calzolari at esa.int" wrote: "OID Frame" = "Only Idle Data_field" Frame :-) 'FDFI' Frame for 'Frame Data Field Idle' Frame looks recursive :-) More correct would be "Only Idle Data in Data Field" Frame = OIDDF Frame We shall set the same term everywhere. Idle Frame is misleading. OID is not perfect but more correct and already defined for Packet TM Frame. Then the simplest is to say that OID Frame is a short form for OIDDF Frame. Let's discuss it in Colorado otherwise we enter in a loop. Ciao Gian Paolo sls-slp-bounces at mailman.ccsds.org wrote on 23-03-2009 19:55:21: > All, > > The problem with the term, "OID Frame" or "Only Idle Data" Frame is > that it still doesn't clearly convey the fact that the PAYLOAD or > FRAME DATA FIELD of the frame contains idle data, and that other > fields of the transfer frame such as Insert Zone (AOS), Frame > Secondary Header (TM), or OCF (all) DO NOT contain Idle data. > Until we have a clear way of specifying that concept, we haven't > really made progress unfortunately. > > So I believe the distinction we are trying to make is about frames > that contain idle data in the Frame Data Field, therefore 'FDFI' > Frame for 'Frame Data Field Idle'. > > Your comments? > > thanks, > Greg > > > From: Greenberg, Edward > Sent: Monday, March 23, 2009 9:03 AM > To: Kazz, Greg J > Subject: Re: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets > > OID is Only Idle Data. If frame contains Insert Data then it isn't > OID. You could call it NFDI for No Frame Data Included > > > On 3/23/09 8:54 AM, "Kazz, Greg J" wrote: > 1) An Idle Packet carries no useful data: This applies to an Idle Space > Packet and to an Idle (or Fill) Encapsulation Packet (see below). > However, the AOS Insert Service uses the Insert Field of every Transfer > Frame on the Physical Channel, including the Idle Frames. Therefore, an > Idle Frame can carry useful data so the name "Idle Frame" is not fully > appropriate. The Pink Sheets provide the new name "OID Frame". > _______________________________________________ > Sls-slp mailing list > Sls-slp at mailman.ccsds.org > http://mailman.ccsds.org/mailman/listinfo/sls-slp -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Wed Mar 25 21:13:48 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Wed, 25 Mar 2009 14:13:48 -0700 Subject: [Sls-slp] FW: [Cesg-all] Updated Schedule for CCSDS Spring 2009 Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45998BF2ED@ALTPHYEMBEVSP10.RES.AD.JPL> All, FYI Greg ________________________________ From: cesg-all-bounces at mailman.ccsds.org [mailto:cesg-all-bounces at mailman.ccsds.org] On Behalf Of Adrian J. Hooke Sent: Wednesday, March 25, 2009 2:03 PM To: CCSDS Engineering Steering Group - All Subject: [Cesg-all] Updated Schedule for CCSDS Spring 2009 Area Directors and WG Chairs: 1. The updated Spring 2009 meeting schedule for Colorado Springs is attached. All of the meetings will now be held in the Penrose House and so we will not need to use the Double Tree Hotel as a meeting location. 2. We are still missing many of your meeting agendas. Please take care of this as soon as possible. http://public.ccsds.org/meetings/2009Spring/2009SpringAgendas.aspx 3. So far we only have 91 people registered. Please ping your participants and remind them to register if they haven't already done so. 4. Please also encourage everyone to select the lunch purchase option. As noted on the website, recent legislation imposed on NASA makes it impossible to provide working lunches and snacks. However, the meeting location is a long way from any suitable restaurants and if people leave to go off-site for lunch there will be a significant loss in overall productivity. The Secretariat has arranged for an excellent caterer to come in each morning and take your lunch orders, and we would most strongly urge that you try to get all of your meeting attendees to use the service and stay on-site. This is particularly important as we will need to leave the facility at 5:00PM each day. Best regards Adrian Adrian J. Hooke Chairman, CCSDS Engineering Steering Group (CESG) NASA Headquarters Space Communications and Navigation Office, 7L70 Space Operations Mission Directorate Washington, DC 20546-0001 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Schedule Spring 20091.pdf Type: application/octet-stream Size: 22230 bytes Desc: Schedule Spring 20091.pdf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: