From greg.j.kazz at jpl.nasa.gov Fri May 1 00:12:19 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Thu, 30 Apr 2009 17:12:19 -0700 Subject: [Sls-slp] FW: SLS-SLP Meeting Berlin: Slides for TC Retransmissions Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A35DD1CA@ALTPHYEMBEVSP10.RES.AD.JPL> Yves, I am following up on an action item assigned to me at the Colorado Springs meeting in the SLS area. The action is to request the CSS-CSTS WG examine the potential impact the attached proposed ESA change to the CCSDS Telecommand Standards may have regarding the addition of a new capability to allow for repeated retransmission of the same TC frame. For example, if this proposal is approved one would be able to populate the new retransmission repeat parameter and use it to request the repetition of a series of frame numbers such as 1,1,1,1,1,1,2,2,2,2,2,2, etc. This change was proposed by ESA in particular to support the LISA - Pathfinder mission in the early acquisition phase since it will be tumbling and may require commanding in a contingency mode. Attached is an overview of the proposal by Margorie de Lande Long as well as a Zip file containing the proposed changes to the CCSDS SLS area documents. The SLS-SLP WG believes these changes may potentially impact both FSP and FCLTU services. However, we request the CSS-CSTS WG make an assessment, so SLS-SLP can factor that into the decision process of either approving or disapproving the changes. Please let me know if you have any questions and thanks in advance for your support. best regards, Greg Kazz CCSDS SLS-SLP WG Chair -----Original Message----- From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Sent: Friday, April 24, 2009 4:00 PM To: Kazz, Greg J Cc: Marjorie de Lande Long Subject: Fw: SLS-SLP Meeting Berlin: Slides for TC Retransmissions BERLIN PRESENTATION ----- Forwarded by Gian Paolo Calzolari/esoc/ESA on 24-04-2009 23:15 ----- Marjorie de Lande Long Greg Kazz cc 09-10-2008 16:54 "Gian.Paolo.Calzolari" Subject SLS-SLP Meeting Berlin: Slides for TC Retransmissions Greg, Here are the slides for the presentation about TC Retransmissions for the SLS-SLP meeting in Berlin on Thursday 16th October. Looking forward to seeing you next week, Marjorie Marjorie de Lande Long I B + M A de Lande Long Software + Consultancy (See attached file: TCretransBerlin.ppt) -------------- next part -------------- A non-text attachment was scrubbed... Name: TCretransBerlin.ppt Type: application/vnd.ms-powerpoint Size: 44032 bytes Desc: TCretransBerlin.ppt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TCretrans2d(26feb2009).zip Type: application/x-zip-compressed Size: 1639635 bytes Desc: TCretrans2d(26feb2009).zip URL: From greg.j.kazz at jpl.nasa.gov Mon May 4 15:16:12 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 4 May 2009 08:16:12 -0700 Subject: [Sls-slp] FW: SLS Report to CESG/CMC Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A35DD345@ALTPHYEMBEVSP10.RES.AD.JPL> All, FYI Greg -----Original Message----- From: Jean-Luc.Gerner at esa.int [mailto:Jean-Luc.Gerner at esa.int] Sent: Monday, May 04, 2009 7:49 AM To: Enrico.Vassallo at esa.int; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J; Kiely, Aaron B Cc: Gilles.Moury at cnes.fr Subject: SLS Report to CESG/CMC Dear SLS WG chairs, You will be able to find at: http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2Fsls%2Fdocs%2FSLS%20Area%2FMeeting%20Materials%2F2009%2FSpring 1. the 'uncompressed' SLS area report to CESG/CMC, i.e. the compilation of your inputs 2. the report as delivered to CESG/CMC, which is a compressed version of the above Have a good reading Best regards and thank you again for your support. Jean-Luc Gerner TEC-ETN Tel: +31 71 565 4473 From greg.j.kazz at jpl.nasa.gov Mon May 4 22:49:16 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 4 May 2009 15:49:16 -0700 Subject: [Sls-slp] Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A35DD46F@ALTPHYEMBEVSP10.RES.AD.JPL> All, At both the SIS-IPO and SLS-SLP WG meeting in Colorado Springs, the following action item was accepted: WG members to poll their respective agencies to determine if the following Space Link Identifiers can be depreciated from the Space Link Identifiers Blue Book. These IDs are: 1. IPv4 (proposal is to remove this CCSDS packet version number ) 2. SCPS-NP (proposal is to remove this CCSDS packet version number ) 3. ISO-8473 (proposal is to remove the APID 2046 assignment) Note that the timing as to when these changes can be made to the CCSDS documents affected is still TBD. This action is only on the agencies to determine if there would be any negative consequence for carrying out these proposals. The sections of the CCSDS documents affected for your information only are as follows: 1. Remove IPv4, SCPS-NP Packet Version numbers from Table 7.6. Also Note 2 needs to be removed from that table. In addition, in Annex C, rows 2 and 3 of that table also need to be deleted, since they deal with IPv4 and SCPS-NP packet version numbers. 2. The only other document that I could find that talks about IPv4 or SCPS-NP packet version numbers specifically is the Proximity-1 Space Data Link specification (2006 current version, BB-4). Tom let me know what you think, but I recommend we would make a technical corrigendum to this document commensurate with the proposed changes to Space Link Identifiers above. In Section 2.2.2.2 CCSDS Packet Delivery Service, we should remove the references to IPv4 and SCPS-NP and say ... (see Table 7.6 of Reference 10, Space Link Identifiers Blue Book). Also need to remove IPv4 from the acronym list. 3. Lastly, we gained consensus at the COS meetings to deprecate ISO 8473 from Table 5.2 Reserved APIDs in Space Link Identifiers. The same action applies for agencies to do diligence to ensure it is not used. In that spirit, reference [16] would also be removed from that document. This change would be rolled into the change package for the Space Link Identifiers BB. Best regards, Greg Kazz Chairman SLS-SLP and SIS-IPO WGs -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Mon May 11 15:19:32 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 11 May 2009 08:19:32 -0700 Subject: FW: [Sls-slp] Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A35DD9E7@ALTPHYEMBEVSP10.RES.AD.JPL> All, For your information - Greg -----Original Message----- From: Takahiro Yamada [mailto:tyamada at pub.isas.jaxa.jp] Sent: Monday, May 11, 2009 2:54 AM To: Kazz, Greg J Subject: Re: [Sls-slp] Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID Greg, > * IPv4 (proposal is to remove this CCSDS packet version number ) > * SCPS-NP (proposal is to remove this CCSDS packet version number ) > * ISO-8473 (proposal is to remove the APID 2046 assignment) JAXA does not have a plan to use any of these protocols on space links. Best regards, Takahiro Yamada From greg.j.kazz at jpl.nasa.gov Tue May 12 17:28:11 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Tue, 12 May 2009 10:28:11 -0700 Subject: [Sls-slp] Performance Question concerning ESA proposed TC # retransmit parameter Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A35DDBFC@ALTPHYEMBEVSP10.RES.AD.JPL> Marjorie/G.P. The following performance question and use case question has come up concerning the proposed ESA TC # retransmissions parameter: 1) Performance: Has there been any mathematical modeling to help determine what the expected increase in throughput that will likely be for various repeat/re-trans counts over the TC Space Link ? Could it have a significant link-margin consideration as well? 2) Use Case: Also would the number of retransmissions parameter set to greater than one be envisioned for any non-link layer driven scenarios? For example, I think it might be interesting to consider what role this plays in a space internetworking environment. Presumably this would just be in the link level set of services ... but maybe you want to make sure a key routing table arrives at a particular spacecraft? Would we ever consider that the spacecraft would implement this between themselves ? thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles.moury at cnes.fr Thu May 14 07:28:19 2009 From: gilles.moury at cnes.fr (Moury Gilles) Date: Thu, 14 May 2009 09:28:19 +0200 Subject: [Sls-slp] Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45A35DD9E7@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: <8AE00EF6032F0A47BAF1544ACFCC83400342B1DE@cst-xch-002.cnesnet.ad.cnes.fr> Dear all, Same for CNES : no intention to use IPv4, SCPS-NP, ISO-8473 packets direct insertion in CCSDS data link frames. This capability can be removed. Best regards, Gilles Gilles MOURY CNES Toulouse -----Message d'origine----- De : sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] De la part de Kazz, Greg J Envoyé : lundi 11 mai 2009 17:20 À : sls-slp at mailman.ccsds.org Objet : FW: [Sls-slp] Action Item: Poll Agencies on use of IPv4, SCPS-NP,and ISO-8473 APID All, For your information - Greg -----Original Message----- From: Takahiro Yamada [mailto:tyamada at pub.isas.jaxa.jp] Sent: Monday, May 11, 2009 2:54 AM To: Kazz, Greg J Subject: Re: [Sls-slp] Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID Greg, > * IPv4 (proposal is to remove this CCSDS packet version number ) > * SCPS-NP (proposal is to remove this CCSDS packet version number ) > * ISO-8473 (proposal is to remove the APID 2046 assignment) JAXA does not have a plan to use any of these protocols on space links. Best regards, Takahiro Yamada _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp From adrian.j.hooke at jpl.nasa.gov Thu May 14 11:14:06 2009 From: adrian.j.hooke at jpl.nasa.gov (Adrian J. Hooke) Date: Thu, 14 May 2009 07:14:06 -0400 Subject: [Sls-slp] Re: Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID Message-ID: <6.2.3.4.2.20090514071214.02913be0@mail.jpl.nasa.gov> >-----Original Message----- >From: Takahiro Yamada [mailto:tyamada at pub.isas.jaxa.jp] >Sent: Monday, May 11, 2009 2:54 AM >To: Kazz, Greg J >Subject: Re: [Sls-slp] Action Item: Poll Agencies on use of IPv4, >SCPS-NP, and ISO-8473 APID > > * IPv4 (proposal is to remove this CCSDS packet version number ) > > * SCPS-NP (proposal is to remove this CCSDS packet version number ) > > * ISO-8473 (proposal is to remove the APID 2046 assignment) > >JAXA does not have a plan to use any of these protocols on space links. Takahiro: does this include the manned space side of JAXA? Best regards Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jean-Luc.Gerner at esa.int Thu May 14 13:26:40 2009 From: Jean-Luc.Gerner at esa.int (Jean-Luc.Gerner at esa.int) Date: Thu, 14 May 2009 15:26:40 +0200 Subject: [Sls-slp] Re: Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID In-Reply-To: <6.2.3.4.2.20090514071214.02913be0@mail.jpl.nasa.gov> Message-ID: ESA is using IPv4 on the Space Station (from what I know). Jean-Luc Gerner TEC-ETN Tel: +31 71 565 4473 "Adrian J. Hooke" To Sent by: Takahiro Yamada sls-slp-bounces at ma ilman.ccsds.org cc "sls-slp at mailman.ccsds.org" 14/05/2009 13:14 Subject [Sls-slp] Re: Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID -----Original Message----- From: Takahiro Yamada [ mailto:tyamada at pub.isas.jaxa.jp] Sent: Monday, May 11, 2009 2:54 AM To: Kazz, Greg J Subject: Re: [Sls-slp] Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID > * IPv4 (proposal is to remove this CCSDS packet version number ) > * SCPS-NP (proposal is to remove this CCSDS packet version number ) > * ISO-8473 (proposal is to remove the APID 2046 assignment) JAXA does not have a plan to use any of these protocols on space links. Takahiro: does this include the manned space side of JAXA? Best regards Adrian _______________________________________________ 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 May 14 16:02:50 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Thu, 14 May 2009 09:02:50 -0700 Subject: [Sls-slp] Re: Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID In-Reply-To: References: <6.2.3.4.2.20090514071214.02913be0@mail.jpl.nasa.gov> Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A376A38A@ALTPHYEMBEVSP10.RES.AD.JPL> Jean-Luc, Can you provide us with some more details on this? Are they using IPv4 datagrams put directly into CCSDS AOS frames? thanks, Greg -----Original Message----- From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Jean-Luc.Gerner at esa.int Sent: Thursday, May 14, 2009 6:27 AM To: Hooke, Adrian J Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; sls-slp-bounces at mailman.ccsds.org Subject: Re: [Sls-slp] Re: Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID ESA is using IPv4 on the Space Station (from what I know). Jean-Luc Gerner TEC-ETN Tel: +31 71 565 4473 "Adrian J. Hooke" To Sent by: Takahiro Yamada sls-slp-bounces at ma ilman.ccsds.org cc "sls-slp at mailman.ccsds.org" 14/05/2009 13:14 Subject [Sls-slp] Re: Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID -----Original Message----- From: Takahiro Yamada [ mailto:tyamada at pub.isas.jaxa.jp] Sent: Monday, May 11, 2009 2:54 AM To: Kazz, Greg J Subject: Re: [Sls-slp] Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID > * IPv4 (proposal is to remove this CCSDS packet version number ) > * SCPS-NP (proposal is to remove this CCSDS packet version number ) > * ISO-8473 (proposal is to remove the APID 2046 assignment) JAXA does not have a plan to use any of these protocols on space links. Takahiro: does this include the manned space side of JAXA? Best regards Adrian _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp From tyamada at pub.isas.jaxa.jp Fri May 15 10:27:28 2009 From: tyamada at pub.isas.jaxa.jp (Takahiro Yamada) Date: Fri, 15 May 2009 19:27:28 +0900 Subject: [Sls-slp] Re: Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID In-Reply-To: <6.2.3.4.2.20090514071214.02913be0@mail.jpl.nasa.gov> References: <6.2.3.4.2.20090514071214.02913be0@mail.jpl.nasa.gov> Message-ID: Adrian, > Takahiro: does this include the manned space side of JAXA? I forgot about it. I sent a message to the space station people and will let you know the result next week. Best regards, Takahiro Yamada From tyamada at pub.isas.jaxa.jp Wed May 20 08:31:31 2009 From: tyamada at pub.isas.jaxa.jp (Takahiro Yamada) Date: Wed, 20 May 2009 17:31:31 +0900 Subject: [Sls-slp] Re: Action Item: Poll Agencies on use of IPv4, SCPS-NP, and ISO-8473 APID In-Reply-To: References: <6.2.3.4.2.20090514071214.02913be0@mail.jpl.nasa.gov> Message-ID: <6DE633B6-B496-4BBB-852B-0FD02E04490B@pub.isas.jaxa.jp> Adrian, >> Takahiro: does this include the manned space side of JAXA? > > I forgot about it. I sent a message to the space station people and > will let you know the result next week. As far as the cross support interface is concerned, the CCSDS Space Packet is the only Packet that is used on any interface of the Japanese module of the International Space Station. Best regards, Takahiro Yamada From edward.greenberg at jpl.nasa.gov Thu May 28 17:37:22 2009 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward) Date: Thu, 28 May 2009 10:37:22 -0700 Subject: [Sls-slp] Cross support implementation Limitations Message-ID: The link layer security working group needs to understand the limitations in the current link layer implementations in order to understand the effects of minor or even major structural changes to link layer structures. For example CNES has missions that insert a frame time tag as a secondary header each telemetry frame for some of its missions. If the Security working group, for example, recommended that the security header precede the insert zone and/or current secondary header would that effect current services? Return Frame services only require information in the primary header and validation/coding acknowledgement, they don't examine the frame's content. Packet extraction however would be effected if the structure of the frame would change even if security was not used. When security is included, exclusive of just adding fields to the end of the frame data field processing may not be effected but finding the data field portion in the frame may/will probably be effected. Forward link implementations currently only deal with TC frames. Security, if layered above a frame delimitation and validation service would most likely not effect that underlying service sublayer. The processing of the frame's contents for extraction of packets however would certainly require changes in any event to handle the security. So the question that needs to be answered is what are the bounds that current Multimission service place on the current frame structures. It is questionable if current missions that are handled by mission unique processing should impose limitations on what should/could be done to modify the framing structures. I would suspect that the biggest issue will be the placement of the Security Header within the frame and the use of spare bits within the primary header. So it would be important to identify those implementations that would be effected by location of the security header within the frame or the limitations that must be included for its inclusion. An issue that arises is the insert zone. Can the insert zone (even though it will be required to be the same size in every frame) be required to be in the exact same location within frames of different VCs? I can see where implementations that use the insert zone would desire it to be independent of VC and thus require the insert zone to be capable of being delimited exclusively from primary header information. This could require that the security header, in each frame, be the same size and be contained in all frames if required for any VC when an insert zone is used. I would also suggest that we examine the possible use of secondary headers for AOS frames. The insert zone is an important feature for low rate links but becomes a burden for high rate links. A secondary header carrying the "insert zone contents" from a lower rate link simply supply that same service when included in a few frames when the frame rate increases.