From greg.j.kazz at jpl.nasa.gov Wed Apr 1 15:20:04 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Wed, 1 Apr 2009 08:20:04 -0700 Subject: [Sls-slp] Updated version of Pink sheet to Space Link Identifers Blue Book Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A3137B08@ALTPHYEMBEVSP10.RES.AD.JPL> All, For discussion both in the SLS-SLP WG meeting as well as in the SIS-IPO WG meeting, I have added to both public folders on the CWE (SLS-SLP and SIS-IPO public folders) a copy of the lastest update to the Space Link Identifiers Pink sheets. The file name is: 135x0p302[working]-gjk4-1-09.doc It contains the addition of the enumeration 35 to Annex A. This addition would make it possible to use FRF.20 control messages to configure items on the remote link. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Mon Apr 13 21:25:39 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 13 Apr 2009 14:25:39 -0700 Subject: [Sls-slp] Update to Space Link Identifier Pink Sheet availble on CCSDS CWE Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A33EB8BB@ALTPHYEMBEVSP10.RES.AD.JPL> SLS-SLP and SIS-IPO WGs, I have placed a new update to the Space Link Identifers Pink Sheet under current CCSDS review. This update contains a description of the conditions under which the proposed ID #35 would be used. The file name is 135x0p302working-wbw4-13-09.doc I have loaded this file into the public folders of both the SIS-IPO and SLS-SLP WG directories since it impacts both areas. For SLS: http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS%2dSLP%2fDraft%20Documents&FolderCTID=&View=%7b16ACDA38%2dFFA3%2d4657%2d8F27%2dB166C23C24A2%7d For SIS: http://cwe.ccsds.org/sis/docs/Forms/AllItems.aspx?RootFolder=%2fsis%2fdocs%2fSIS%2dIPO%2fDraft%20Documents&FolderCTID=&View=%7b390C4ADA%2dA69B%2d4E52%2dA0DA%2d50C48F989C4B%7d The change to the text is: Enumeration #35 Frame Relay IP Header Compression Control Protocol (FRIHCP)[1] 1Per this standard, the Frame Relay Header Compression Control Protocol exchange is not required for header compression to take place on the link. The alternate is that the use of header compression is by prior arrangement and the associated parameters have been pre-configured. This is the only option for header compression on a one way link. Note that if header compression options are misconfigured between sender and receiver, the link will not successfully pass IP packets, as is true with any misconfiguration (e.g. Virtual Channel number used for IP over AOS). For this reason, use of IP header compression negotiation is useful and recommended where feasible. Please let me know if you have any comments or concerns about this proposed addition. best regards, Greg Kazz Chairman CCSDS SLS-SLP & SIS-IPO WGs ________________________________ [1] Per this standard, the Frame Relay Header Compression Control Protocol exchange is not required for header compression to take place on the link. The alternate is that the use of header compression is by prior arrangement and the associated parameters have been pre-configured. This is the only option for header compression on a one way link. Note that if header compression options are misconfigured between sender and receiver, the link will not successfully pass IP packets, as is true with any misconfiguration (e.g. Virtual Channel number used for IP over AOS). For this reason, use of IP header compression negotiation is useful and recommended where feasible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Apr 21 04:12:18 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 20 Apr 2009 21:12:18 -0700 Subject: [Sls-slp] Adding a note to Encapsulation Service 4.2.2.4 Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A33EBFD1@ALTPHYEMBEVSP10.RES.AD.JPL> All, During today's SIS-IPO meeting, Dave Israel made what I believe is a very good suggestion, discovered during interoperability testing IP/IPE over Encapsulation over AOS frames. The problem with the current wording of the Encapsulation Service Specification is that two independent implementations will not interoperate if the receive side of the interface implements Encapsulation packet size differently with respect to the transmit side. The proposed note would be added to the Encapsulation Service Pink Sheets, which is a topic for discussion in the SLS-SLP WG meeting on Friday. The section is 4.2.2.4 Length of Length Field The proposed note is: NOTE - An implementation on the transmitting end may choose to either use a fixed Encapsulation header size or adaptively/dynamically adjust the size of the Encapsulation Header size according to the payload size in order to optimize bandwidth use (minimize header overhead). Therefore, an implementation must be capable of receiving encapsulation packets implementing either case. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Tue Apr 21 04:16:31 2009 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward) Date: Mon, 20 Apr 2009 21:16:31 -0700 Subject: [Sls-slp] Re: [Sis-ipo] Adding a note to Encapsulation Service 4.2.2.4 In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45A33EBFD1@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: I agree with Dave's comment except it should be a normative statement not a NOTE! On 4/20/09 9:12 PM, "Kazz, Greg J" wrote: All, During today's SIS-IPO meeting, Dave Israel made what I believe is a very good suggestion, discovered during interoperability testing IP/IPE over Encapsulation over AOS frames. The problem with the current wording of the Encapsulation Service Specification is that two independent implementations will not interoperate if the receive side of the interface implements Encapsulation packet size differently with respect to the transmit side. The proposed note would be added to the Encapsulation Service Pink Sheets, which is a topic for discussion in the SLS-SLP WG meeting on Friday. The section is 4.2.2.4 Length of Length Field The proposed note is: NOTE - An implementation on the transmitting end may choose to either use a fixed Encapsulation header size or adaptively/dynamically adjust the size of the Encapsulation Header size according to the payload size in order to optimize bandwidth use (minimize header overhead). Therefore, an implementation must be capable of receiving encapsulation packets implementing either case. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.walsh at linquest.com Tue Apr 21 04:22:10 2009 From: william.walsh at linquest.com (Walsh, William) Date: Mon, 20 Apr 2009 21:22:10 -0700 Subject: [Sls-slp] RE: [Sis-ipo] Adding a note to Encapsulation Service 4.2.2.4 In-Reply-To: References: <02D130BD9C29BB4AAD59B77342F7E25F45A33EBFD1@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: <223FE771C14B4776A10EF3311925CD38@linquest.local> Greg, Dave, Did this discussion refer to the 2, 4 vs 8 byte encap headers, with 1, 2 or 4 byte length fields? Note that most programs that I've talked to explicitly exempt their contractors from supporting the 8 byte encap header. If this comment regards the choices of idle packets, i.e. 1-byte vs. variable - I'm not sure that part is a bandwidth issue. I apologize that I don't clearly remember the context of the discussion today. Regards, william _____ From: sis-ipo-bounces at mailman.ccsds.org [mailto:sis-ipo-bounces at mailman.ccsds.org] On Behalf Of Greenberg, Edward Sent: Monday, April 20, 2009 9:17 PM To: Kazz, Greg J; sls-slp at mailman.ccsds.org; sis-ipo at mailman.ccsds.org Subject: Re: [Sis-ipo] Adding a note to Encapsulation Service 4.2.2.4 I agree with Dave's comment except it should be a normative statement not a NOTE! On 4/20/09 9:12 PM, "Kazz, Greg J" wrote: All, During today's SIS-IPO meeting, Dave Israel made what I believe is a very good suggestion, discovered during interoperability testing IP/IPE over Encapsulation over AOS frames. The problem with the current wording of the Encapsulation Service Specification is that two independent implementations will not interoperate if the receive side of the interface implements Encapsulation packet size differently with respect to the transmit side. The proposed note would be added to the Encapsulation Service Pink Sheets, which is a topic for discussion in the SLS-SLP WG meeting on Friday. The section is 4.2.2.4 Length of Length Field The proposed note is: NOTE - An implementation on the transmitting end may choose to either use a fixed Encapsulation header size or adaptively/dynamically adjust the size of the Encapsulation Header size according to the payload size in order to optimize bandwidth use (minimize header overhead). Therefore, an implementation must be capable of receiving encapsulation packets implementing either case. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.j.israel at nasa.gov Tue Apr 21 13:28:48 2009 From: david.j.israel at nasa.gov (Israel, David J. (GSFC-5670)) Date: Tue, 21 Apr 2009 08:28:48 -0500 Subject: [Sls-slp] RE: [Sis-ipo] Adding a note to Encapsulation Service 4.2.2.4 In-Reply-To: <223FE771C14B4776A10EF3311925CD38@linquest.local> References: <02D130BD9C29BB4AAD59B77342F7E25F45A33EBFD1@ALTPHYEMBEVSP10.RES.AD.JPL> <223FE771C14B4776A10EF3311925CD38@linquest.local> Message-ID: <0C1AFF6FBF478D418099D6C14EFA28DE28364B4845@NDMSSCC03.ndc.nasa.gov> William, This note means that you need to be able to receive encap packets with any of the various header sizes, in the general case. If a program knows that they would never be receiving data from anybody using the 8 byte header, they would not have to be able to support it. A program can also choose never to transmit 8 byte headers. Dave ________________________________ From: sis-ipo-bounces at mailman.ccsds.org [mailto:sis-ipo-bounces at mailman.ccsds.org] On Behalf Of Walsh, William Sent: Tuesday, April 21, 2009 12:22 AM To: 'Greenberg, Edward'; 'Kazz, Greg J'; sls-slp at mailman.ccsds.org; sis-ipo at mailman.ccsds.org Subject: RE: [Sis-ipo] Adding a note to Encapsulation Service 4.2.2.4 Greg, Dave, Did this discussion refer to the 2, 4 vs 8 byte encap headers, with 1, 2 or 4 byte length fields? Note that most programs that I've talked to explicitly exempt their contractors from supporting the 8 byte encap header. If this comment regards the choices of idle packets, i.e. 1-byte vs. variable - I'm not sure that part is a bandwidth issue. I apologize that I don't clearly remember the context of the discussion today. Regards, william ________________________________ From: sis-ipo-bounces at mailman.ccsds.org [mailto:sis-ipo-bounces at mailman.ccsds.org] On Behalf Of Greenberg, Edward Sent: Monday, April 20, 2009 9:17 PM To: Kazz, Greg J; sls-slp at mailman.ccsds.org; sis-ipo at mailman.ccsds.org Subject: Re: [Sis-ipo] Adding a note to Encapsulation Service 4.2.2.4 I agree with Dave's comment except it should be a normative statement not a NOTE! On 4/20/09 9:12 PM, "Kazz, Greg J" wrote: All, During today's SIS-IPO meeting, Dave Israel made what I believe is a very good suggestion, discovered during interoperability testing IP/IPE over Encapsulation over AOS frames. The problem with the current wording of the Encapsulation Service Specification is that two independent implementations will not interoperate if the receive side of the interface implements Encapsulation packet size differently with respect to the transmit side. The proposed note would be added to the Encapsulation Service Pink Sheets, which is a topic for discussion in the SLS-SLP WG meeting on Friday. The section is 4.2.2.4 Length of Length Field The proposed note is: NOTE - An implementation on the transmitting end may choose to either use a fixed Encapsulation header size or adaptively/dynamically adjust the size of the Encapsulation Header size according to the payload size in order to optimize bandwidth use (minimize header overhead). Therefore, an implementation must be capable of receiving encapsulation packets implementing either case. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.m.shames at jpl.nasa.gov Tue Apr 21 16:36:09 2009 From: peter.m.shames at jpl.nasa.gov (Shames, Peter M) Date: Tue, 21 Apr 2009 09:36:09 -0700 Subject: [Sls-slp] Adding a note to Encapsulation Service 4.2.2.4 In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45A33EBFD1@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: There is a principle in the Internet that reads like this: "Be liberal in what you accept, and conservative in what you send." -- Jon Postel. RFC-1122 We would do well to adopt this ourselves since it directly addresses these sorts of circumstances. Cheers, Peter On 4/20/09 9:12 PM, "Greg Kazz" wrote: All, During today's SIS-IPO meeting, Dave Israel made what I believe is a very good suggestion, discovered during interoperability testing IP/IPE over Encapsulation over AOS frames. The problem with the current wording of the Encapsulation Service Specification is that two independent implementations will not interoperate if the receive side of the interface implements Encapsulation packet size differently with respect to the transmit side. The proposed note would be added to the Encapsulation Service Pink Sheets, which is a topic for discussion in the SLS-SLP WG meeting on Friday. The section is 4.2.2.4 Length of Length Field The proposed note is: NOTE - An implementation on the transmitting end may choose to either use a fixed Encapsulation header size or adaptively/dynamically adjust the size of the Encapsulation Header size according to the payload size in order to optimize bandwidth use (minimize header overhead). Therefore, an implementation must be capable of receiving encapsulation packets implementing either case. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gian.Paolo.Calzolari at esa.int Wed Apr 22 20:10:53 2009 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 22 Apr 2009 22:10:53 +0200 Subject: [Sls-slp] Adding a note to Encapsulation Service 4.2.2.4 In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45A33EBFD1@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: Greg I look forward to discussing it in the SLP Meeting. Regards Gian Paolo From greg.j.kazz at jpl.nasa.gov Thu Apr 23 14:47:33 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Thu, 23 Apr 2009 07:47:33 -0700 Subject: [Sls-slp] ISO 8473 - CCSDS APID Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A33EC254@ALTPHYEMBEVSP10.RES.AD.JPL> G.P., No one seems to be using ISO 8473, yet CCSDS still has this as an APID in table 5.2 in Space Link Identifiers. (Reserved Application Process Identifiers) We should move to remove it from the book - what do you think? Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.j.hooke at jpl.nasa.gov Thu Apr 23 15:22:43 2009 From: adrian.j.hooke at jpl.nasa.gov (Adrian J. Hooke) Date: Thu, 23 Apr 2009 11:22:43 -0400 Subject: [Sls-slp] Re: ISO 8473 - CCSDS APID Message-ID: <6.2.3.4.2.20090423110907.0276e148@mail.jpl.nasa.gov> At 10:47 AM 4/23/2009, Kazz, Greg J wrote: >No one seems to be using ISO 8473, yet CCSDS >still has this as an APID in table 5.2 in Space >Link Identifiers. (Reserved Application Process Identifiers) >We should move to remove it from the book – what do you think? Although reports of its death are greatly exaggerated (http://en.wikipedia.org/wiki/CLNS) - "CLNP is still widely used today in many telecommunications networks around the world" - I do not believe that anyone is advocating its use for connectionless networking in space. Therefore, global deprecation of references to 8473 in CCSDS documents seems to be appropriate. However, the SIS Area should make the final determination relative to its fate. ///adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.blanchet at viagenie.ca Thu Apr 23 16:22:08 2009 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Thu, 23 Apr 2009 10:22:08 -0600 Subject: [Sls-slp] Re: [SIS] Re: ISO 8473 - CCSDS APID In-Reply-To: <6.2.3.4.2.20090423110907.0276e148@mail.jpl.nasa.gov> References: <6.2.3.4.2.20090423110907.0276e148@mail.jpl.nasa.gov> Message-ID: <49F095B0.4000400@viagenie.ca> well, to do some SANA selling, if the table was in a SANA registry, then the specification document do not need to be updated, just the registry. much simpler process. Spec still remains as is. (SANA not yet up, but hopefully soon!) my 2 cents cdn... Marc. Adrian J. Hooke a écrit : > At 10:47 AM 4/23/2009, Kazz, Greg J wrote: >> No one seems to be using ISO 8473, yet CCSDS still has this as an APID >> in table 5.2 in Space Link Identifiers. (*Reserved Application Process >> Identifiers) >> *We should move to remove it from the book – what do you think? > > Although reports of its death are greatly exaggerated ( > http://en.wikipedia.org/wiki/CLNS) - "CLNP is still widely used today > in many telecommunications networks around the world" - I do not believe > that anyone is advocating its use for connectionless networking in > space. Therefore, global deprecation of references to 8473 in CCSDS > documents seems to be appropriate. However, the SIS Area should make the > final determination relative to its fate. > > ///adrian > > > ------------------------------------------------------------------------ > > _______________________________________________ > SIS mailing list > SIS at mailman.ccsds.org > http://mailman.ccsds.org/mailman/listinfo/sis -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From loren.p.clare at jpl.nasa.gov Fri Apr 24 20:11:44 2009 From: loren.p.clare at jpl.nasa.gov (Clare, Loren P) Date: Fri, 24 Apr 2009 13:11:44 -0700 Subject: [Sls-slp] Update on IPE interoperability testing Message-ID: <2541F8DA95F05247A4673DBBD7E03237EB680E5D4E@ALTPHYEMBEVSP20.RES.AD.JPL> This is a note to indicate that since our Monday meeting we have successfully been able to demonstrate exchange between two prototypes, in which the output of the NASA-GSFC-CSTL prototype (via file) is processed by the NASA-JPL-PTL prototype. The IPE shim byte is included in this processing, with uncompressed IP headers. In addition, Dave Israel has relayed that successful testing has been achieved in exchanging uncompressed IP headers from the CSTL prototype to the Avtec prototype (via file). These are noteworthy extensions beyond those discussed at the WG meeting earlier this week. Recall that at the meeting it was presented that two prototypes have been developed and shown to perform live and offline interoperation. These prototypes were created by separate JPL developers; one is implemented in software and the other in FPGA. However interoperability among prototypes implemented at different organizational entities substantially strengthens the validation. Regards, Loren -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.m.shames at jpl.nasa.gov Sat Apr 25 02:55:01 2009 From: peter.m.shames at jpl.nasa.gov (Shames, Peter M) Date: Fri, 24 Apr 2009 19:55:01 -0700 Subject: [Sls-slp] Update on IPE interoperability testing In-Reply-To: <2541F8DA95F05247A4673DBBD7E03237EB680E5D4E@ALTPHYEMBEVSP20.RES.AD.JPL> Message-ID: Good news. Now we just need to hook it up and see it work over a link in real time. Peter On 4/24/09 1:11 PM, "Loren Clare" wrote: This is a note to indicate that since our Monday meeting we have successfully been able to demonstrate exchange between two prototypes, in which the output of the NASA-GSFC-CSTL prototype (via file) is processed by the NASA-JPL-PTL prototype. The IPE shim byte is included in this processing, with uncompressed IP headers. In addition, Dave Israel has relayed that successful testing has been achieved in exchanging uncompressed IP headers from the CSTL prototype to the Avtec prototype (via file). These are noteworthy extensions beyond those discussed at the WG meeting earlier this week. Recall that at the meeting it was presented that two prototypes have been developed and shown to perform live and offline interoperation. These prototypes were created by separate JPL developers; one is implemented in software and the other in FPGA. However interoperability among prototypes implemented at different organizational entities substantially strengthens the validation. Regards, Loren -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Sun Apr 26 04:08:20 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Sat, 25 Apr 2009 21:08:20 -0700 Subject: [Sls-slp] FW: CCSDS SLS - Report of WGs Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A33EC3C5@ALTPHYEMBEVSP10.RES.AD.JPL> FYI Greg ________________________________ From: Jean-Luc Gerner [mailto:jgerner.at.esa at gmail.com] Sent: Saturday, April 25, 2009 6:39 PM To: Kazz, Greg J; Gilles.Moury at cnes.fr; gian.paolo.calzolari at esa.int; Massimo Bertinelli; Kiely, Aaron B; Greenberg, Edward; mcosby at qinetiq.com; lester.waugh at eads.net; guy.lesthievent at cnes.fr Subject: CCSDS SLS - Report of WGs Dear all, Attached please find the SLS report as elaborated together this morning. I will produce a compressed version for the CESG that I will also send to you. Thanks again for your contribution. Best regards Jean-Luc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SLS-Report-to-CESG-CMC-27Apr09 - uncompressed version.ppt Type: application/vnd.ms-powerpoint Size: 414208 bytes Desc: SLS-Report-to-CESG-CMC-27Apr09 - uncompressed version.ppt URL: