From greg.j.kazz at jpl.nasa.gov Mon Jul 6 20:54:21 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 6 Jul 2009 13:54:21 -0700 Subject: [Sls-slp] Draft RID resolutions to RIDS against AOS and TM Space Data Link Protocols Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A3CB2815@ALTPHYEMBEVSP10.RES.AD.JPL> All, Attached are my draft RID resolutions to the RIDS that both JAXA and INPE have written against AOS and TM Space Data Link Protocols based upon our discussion in Colorado Springs. In summary, the JAXA RIDs were focused upon the 'OID' term. The INPE RIDs were purely editorial. I would appreciate it if you would let me know, if you have any issues concerning these resolutions by July 22, 2009. The resolutions of these RIDs are required to be provided to the Secretariat before any updates to these documents per the current pink sheets can be performed. Pink sheets can be viewed at http://public.ccsds.org/review/default.aspx best regards, Greg Kazz Chairman CCSDS SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JAXA-RPA0830-01.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JAXA-RPA0830-02.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JAXA-RPA0830-03.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JAXA-RPA0830-04.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JAXA-RPA0830-05.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: INPE RID Feb to CCSDS 132 0-P-1 1 review.doc Type: application/msword Size: 29184 bytes Desc: INPE RID Feb to CCSDS 132 0-P-1 1 review.doc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: INPE RID Feb to CCSDS 732 0-P-2 1 review.doc Type: application/msword Size: 29696 bytes Desc: INPE RID Feb to CCSDS 732 0-P-2 1 review.doc URL: From greg.j.kazz at jpl.nasa.gov Tue Jul 14 17:21:19 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Tue, 14 Jul 2009 10:21:19 -0700 Subject: [Sls-slp] RID and RID response to Prox-1 Data Link Protocol Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45B40B3033@ALTPHYEMBEVSP10.RES.AD.JPL> All, I have received the following RIDs, from Vignesh Krishnumurthy, RSA regarding an actual inconsistency in the Proximity-1 Data Link Protocol Specification - see the RID request and the proposed RID responses attached to this email. Your participation in this matter is greatly appreciated! I will post both the RID request and response on the CWE under the SLS-SLP WG: http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents%2fProx1_vigneshs_RIDs&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2} If you have trouble with this URL, navigate the following path: SLS-SLP/Draft Documents/Prox1_vigneshs_RIDs The main issue has to do with the following statement (number 2, the underlined text below) that contradicts the Receiving Node requirement for handling the Source/Destination Flag (S/D Flag): 3.2.2.9 Source-or-Destination Identifier (yellow highlight is unintended - please ignore) 3.2.2.9.1 Bit 20 of the Transfer Frame Header shall contain the Source-or-Destination Identifier. 3.2.2.9.2 The Source-or-Destination Identifier shall identify the link node to which the value in the SCID field applies: a) a setting of '0' shall indicate that: 1) The SCID refers to the source of the transfer frame, 2) The test of the SCID shall be included in the Frame sublayer only when Test_Source is true; The underline text needs to be removed (See RID resolution text in the second attachment) and replaced with text that says the test is always performed by the receiving node. Please take a look at the attachments and I would appreciate it if you can post your comments to the SLS-SLP WG via sls-slp at mailman.ccsds.org mailing list. The good news is the update will correct these errors in the specification and make it more understandable. We will need to resolve this issue at the upcoming meeting in Noordwijk, the Netherlands. Best regards, Greg Kazz Chairman CCSDS SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vignesh_Krishnamurthy_RID_Request_July_10_09.doc Type: application/msword Size: 37888 bytes Desc: vignesh_Krishnamurthy_RID_Request_July_10_09.doc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vignesh_Krishnamurthy_RID_Response_July_14_09.doc Type: application/msword Size: 50688 bytes Desc: vignesh_Krishnamurthy_RID_Response_July_14_09.doc URL: From greg.j.kazz at jpl.nasa.gov Thu Jul 16 20:49:01 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Thu, 16 Jul 2009 13:49:01 -0700 Subject: [Sls-slp] A Homogeneous Approach to Secondary Headers/Insert Zones across TM, TC, and AOS Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45B40B33AF@ALTPHYEMBEVSP10.RES.AD.JPL> Dear SLS-SLP WG members: Attached is a first draft modification to the AOS specification provide to you as a trail approach towards the goal of making the TM, TC, and AOS Space Data Link protocols the same with respect to the definition and use of services defined for both the Insert Zone and Transfer Frame Secondary Headers. (A copy of this draft modification is also available on the CWE under http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2} The need for this approach is driven by the recent work in the Space Data Link Layer Security WG, in which the need for a Transfer Frame Secondary Header for Security is emerging. I would very much appreciate your comments on both the rationale and the draft modified AOS specification (we choose the AOS spec first, to demonstrate the feasibility of this approach - but at this time there may be inconsistencies in this text that will be resolved later). Below is the rationale for this approach: Rationale for a homogeneous approach for defining and using Transfer Frame Secondary Headers in Virtual Channels and Insert Zones for Master Channels for the TM, TC, and AOS Space Data Link Protocols. (Note: since Prox-1 does not have the concept of a Virtual Channel nor is a Security Secondary Header yet defined for it, Proximity-1 is not included in this approach.) Background: 1) TM was developed to be the telemetry service from a single S/C thus there is only 1 master channel and multiple VCs. The model I would give is that there is one controller of the link that multiplexes multiple VCs into the channel. 2) AOS was also developed to support a single high rate mission entity that had multiple VCs. The specification recognized that VCs could be created by different agency Instruments (ISS Model) and the link controller (ISS) would merge the frames and add insert zone data. Here again there was a node that would merge frames but was in control of link data. 3) The coming era may contain nodes in a network that provide layer 2 (link layer data units-frames) switching. This node is simply taking multiple physical channels and multiplexing them together to form an aggregate physical channel. In this case this node is a routing node and does not build frames it just multiplexes them adding nothing. 4) It is possible, in the current model, to assign a different Master Channel ID to the frames produced by an agency's Instrument/Lab on a space platform (ISS) but there is a controlling entity in this model that can use the Insert Zone. For this reason we would recommend that we use the Master Channel ID for the controlling unit that has the capability to provide Insert Zone data and use the VCID to provide for separation of instrument/Lab channel data other than Insert Zone data. Thus we have changed the association of the Insert Zone from the physical channel to the Master channel. This approach also allows us to redefine the MC-FSH service in TM to be an Insert Zone thus eliminating the duality of the signaling flag and providing for both services if desired. 4) If we believe that we are developing approaches for the future then the merging of frames received from different channels may well be a model for a relay node where each mission builds its frames, encrypts/decrypts them and the relay node just routes the frames onto/off other physical links. 5) As we understand it today no one uses either Insert Zones or Secondary Headers. CNES adds time to its TM frames which could be considered an Insert Zone, however we doubt that CNES defines a secondary header for this usage. 6) This document does not invalidate any of the current services being used for TM, AOS or TC but does allow future missions to more fully utilize the proposed flexibilities. As an example, there is no reason why a mission could not require a secondary header to be of fixed length and be included in each frame in the VC, but new missions with greater capabilities could utilize the flexibly provided by the redefinition of the Secondary header. 7) This approach defines a secondary header for TC, TM, and AOS. (Note that Proximity-1 is not included because it neither contains Virtual Channels nor a proposed Security Header.) The security would be put on by the user on the frame, any insert data that is put in by the mission Master Channel assembler would be outside the user's purview. The proposal states that we could accommodate Insert Zones for a master channel to be backward compatible for an explicit need that we presently don't have. Greg Kazz Chairman SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 732x0b2Pink7-16-09 (2)_GJK.doc Type: application/msword Size: 737792 bytes Desc: 732x0b2Pink7-16-09 (2)_GJK.doc URL: From gilles.moury at cnes.fr Fri Jul 17 15:58:32 2009 From: gilles.moury at cnes.fr (Moury Gilles) Date: Fri, 17 Jul 2009 17:58:32 +0200 Subject: [Sls-slp] RE : [Sls-sea-dls] A Homogeneous Approach to Secondary Headers/Insert Zones across TM, TC, and AOS In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45B40B33AF@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: <8AE00EF6032F0A47BAF1544ACFCC83400342B30F@cst-xch-002.cnesnet.ad.cnes.fr> Dear Greg, I concur to this proposal that would basically introduce (potentially nested) Frame Secondary Headers both in TC, TM and AOS space data link protocols. This would enable the definition of a standard FSH for the Space Data Link Security Protocol, usable in TC, TM & AOS. Nevertheless, I have the following remarks : - insert zone in AOS is already being used. At CNES, we use AOS for all our Payload high rate TM links (>1Mb/s). We use the insert service to carry ancillary data pertaining to the frame content : e.g. : ID of file being dumped, Destination ID of file being dumped, security protocol ancillary data, ... Therefore, any modification being done to AOS should not obsolete the insert service. - insert service on AOS is also used by Ariane5 launcher to carry hard real-time data (CVI) for which we need reliable extraction on the fly from the TM stream for safety purposes. This usage is fully in-line with what the insert zone was designed for (low rate, fully synchronous, real-time data transmission in a high rate TM stream). Again, any modification done to AOS protocol should not obsolete insert service. - if FSH service is introduced in AOS, FSH should be transmitted after insert zone, insert zone being transmitted just after the FPH (to maintain backward compatibility). - introducing insert service in the TM Space Data Link Protocol does not seem necessary since insert service is really meant for the above mentioned type of traffic which does not exist for low rate TM links using TM SDLP. Introducing insert service in TM SDLP Best regards, Gilles Gilles MOURY CNES Toulouse -----Message d'origine----- De : sls-sea-dls-bounces at mailman.ccsds.org [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Kazz, Greg J (313B) Envoyé : jeudi 16 juillet 2009 22:49 À : sls-slp at mailman.ccsds.org; sls-sea-dls at mailman.ccsds.org Cc : Kuo, Neal R (313B) Objet : [Sls-sea-dls] A Homogeneous Approach to Secondary Headers/Insert Zones across TM, TC, and AOS Dear SLS-SLP WG members: Attached is a first draft modification to the AOS specification provide to you as a trail approach towards the goal of making the TM, TC, and AOS Space Data Link protocols the same with respect to the definition and use of services defined for both the Insert Zone and Transfer Frame Secondary Headers. (A copy of this draft modification is also available on the CWE under http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2} The need for this approach is driven by the recent work in the Space Data Link Layer Security WG, in which the need for a Transfer Frame Secondary Header for Security is emerging. I would very much appreciate your comments on both the rationale and the draft modified AOS specification (we choose the AOS spec first, to demonstrate the feasibility of this approach - but at this time there may be inconsistencies in this text that will be resolved later). Below is the rationale for this approach: Rationale for a homogeneous approach for defining and using Transfer Frame Secondary Headers in Virtual Channels and Insert Zones for Master Channels for the TM, TC, and AOS Space Data Link Protocols. (Note: since Prox-1 does not have the concept of a Virtual Channel nor is a Security Secondary Header yet defined for it, Proximity-1 is not included in this approach.) Background: 1) TM was developed to be the telemetry service from a single S/C thus there is only 1 master channel and multiple VCs. The model I would give is that there is one controller of the link that multiplexes multiple VCs into the channel. 2) AOS was also developed to support a single high rate mission entity that had multiple VCs. The specification recognized that VCs could be created by different agency Instruments (ISS Model) and the link controller (ISS) would merge the frames and add insert zone data. Here again there was a node that would merge frames but was in control of link data. 3) The coming era may contain nodes in a network that provide layer 2 (link layer data units-frames) switching. This node is simply taking multiple physical channels and multiplexing them together to form an aggregate physical channel. In this case this node is a routing node and does not build frames it just multiplexes them adding nothing. 4) It is possible, in the current model, to assign a different Master Channel ID to the frames produced by an agency's Instrument/Lab on a space platform (ISS) but there is a controlling entity in this model that can use the Insert Zone. For this reason we would recommend that we use the Master Channel ID for the controlling unit that has the capability to provide Insert Zone data and use the VCID to provide for separation of instrument/Lab channel data other than Insert Zone data. Thus we have changed the association of the Insert Zone from the physical channel to the Master channel. This approach also allows us to redefine the MC-FSH service in TM to be an Insert Zone thus eliminating the duality of the signaling flag and providing for both services if desired. 4) If we believe that we are developing approaches for the future then the merging of frames received from different channels may well be a model for a relay node where each mission builds its frames, encrypts/decrypts them and the relay node just routes the frames onto/off other physical links. 5) As we understand it today no one uses either Insert Zones or Secondary Headers. CNES adds time to its TM frames which could be considered an Insert Zone, however we doubt that CNES defines a secondary header for this usage. 6) This document does not invalidate any of the current services being used for TM, AOS or TC but does allow future missions to more fully utilize the proposed flexibilities. As an example, there is no reason why a mission could not require a secondary header to be of fixed length and be included in each frame in the VC, but new missions with greater capabilities could utilize the flexibly provided by the redefinition of the Secondary header. 7) This approach defines a secondary header for TC, TM, and AOS. (Note that Proximity-1 is not included because it neither contains Virtual Channels nor a proposed Security Header.) The security would be put on by the user on the frame, any insert data that is put in by the mission Master Channel assembler would be outside the user's purview. The proposal states that we could accommodate Insert Zones for a master channel to be backward compatible for an explicit need that we presently don't have. Greg Kazz Chairman SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Fri Jul 17 17:03:12 2009 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (313B)) Date: Fri, 17 Jul 2009 10:03:12 -0700 Subject: [Sls-slp] Re: RE : [Sls-sea-dls] A Homogeneous Approach to Secondary Headers/Insert Zones across TM, TC, and AOS In-Reply-To: <8AE00EF6032F0A47BAF1544ACFCC83400342B30F@cst-xch-002.cnesnet.ad.cnes.fr> Message-ID: Gilles, It is encouraging that you support the introduction of the secondary header into AOS while maintaining Insert zone. We agree that adding the insert zone to TM presently is not required. We thought it would be useful to make the structured capabilities of TC,TM and AOS te same and clean up the secondary header issues in TM. I hope you find what we did to the AOS Specification adequate for all you present and future needs. On 7/17/09 8:58 AM, "Moury Gilles" wrote: Dear Greg, I concur to this proposal that would basically introduce (potentially nested) Frame Secondary Headers both in TC, TM and AOS space data link protocols. This would enable the definition of a standard FSH for the Space Data Link Security Protocol, usable in TC, TM & AOS. Nevertheless, I have the following remarks : - insert zone in AOS is already being used. At CNES, we use AOS for all our Payload high rate TM links (>1Mb/s). We use the insert service to carry ancillary data pertaining to the frame content : e.g. : ID of file being dumped, Destination ID of file being dumped, security protocol ancillary data, ... Therefore, any modification being done to AOS should not obsolete the insert service. - insert service on AOS is also used by Ariane5 launcher to carry hard real-time data (CVI) for which we need reliable extraction on the fly from the TM stream for safety purposes. This usage is fully in-line with what the insert zone was designed for (low rate, fully synchronous, real-time data transmission in a high rate TM stream). Again, any modification done to AOS protocol should not obsolete insert service. - if FSH service is introduced in AOS, FSH should be transmitted after insert zone, insert zone being transmitted just after the FPH (to maintain backward compatibility). - introducing insert service in the TM Space Data Link Protocol does not seem necessary since insert service is really meant for the above mentioned type of traffic which does not exist for low rate TM links using TM SDLP. Introducing insert service in TM SDLP Best regards, Gilles Gilles MOURY CNES Toulouse -----Message d'origine----- De : sls-sea-dls-bounces at mailman.ccsds.org [mailto:sls-sea-dls-bounces at mailman.ccsds.org] De la part de Kazz, Greg J (313B) Envoyé : jeudi 16 juillet 2009 22:49 À : sls-slp at mailman.ccsds.org; sls-sea-dls at mailman.ccsds.org Cc : Kuo, Neal R (313B) Objet : [Sls-sea-dls] A Homogeneous Approach to Secondary Headers/Insert Zones across TM, TC, and AOS Dear SLS-SLP WG members: Attached is a first draft modification to the AOS specification provide to you as a trail approach towards the goal of making the TM, TC, and AOS Space Data Link protocols the same with respect to the definition and use of services defined for both the Insert Zone and Transfer Frame Secondary Headers. (A copy of this draft modification is also available on the CWE under http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2} The need for this approach is driven by the recent work in the Space Data Link Layer Security WG, in which the need for a Transfer Frame Secondary Header for Security is emerging. I would very much appreciate your comments on both the rationale and the draft modified AOS specification (we choose the AOS spec first, to demonstrate the feasibility of this approach - but at this time there may be inconsistencies in this text that will be resolved later). Below is the rationale for this approach: Rationale for a homogeneous approach for defining and using Transfer Frame Secondary Headers in Virtual Channels and Insert Zones for Master Channels for the TM, TC, and AOS Space Data Link Protocols. (Note: since Prox-1 does not have the concept of a Virtual Channel nor is a Security Secondary Header yet defined for it, Proximity-1 is not included in this approach.) Background: 1) TM was developed to be the telemetry service from a single S/C thus there is only 1 master channel and multiple VCs. The model I would give is that there is one controller of the link that multiplexes multiple VCs into the channel. 2) AOS was also developed to support a single high rate mission entity that had multiple VCs. The specification recognized that VCs could be created by different agency Instruments (ISS Model) and the link controller (ISS) would merge the frames and add insert zone data. Here again there was a node that would merge frames but was in control of link data. 3) The coming era may contain nodes in a network that provide layer 2 (link layer data units-frames) switching. This node is simply taking multiple physical channels and multiplexing them together to form an aggregate physical channel. In this case this node is a routing node and does not build frames it just multiplexes them adding nothing. 4) It is possible, in the current model, to assign a different Master Channel ID to the frames produced by an agency's Instrument/Lab on a space platform (ISS) but there is a controlling entity in this model that can use the Insert Zone. For this reason we would recommend that we use the Master Channel ID for the controlling unit that has the capability to provide Insert Zone data and use the VCID to provide for separation of instrument/Lab channel data other than Insert Zone data. Thus we have changed the association of the Insert Zone from the physical channel to the Master channel. This approach also allows us to redefine the MC-FSH service in TM to be an Insert Zone thus eliminating the duality of the signaling flag and providing for both services if desired. 4) If we believe that we are developing approaches for the future then the merging of frames received from different channels may well be a model for a relay node where each mission builds its frames, encrypts/decrypts them and the relay node just routes the frames onto/off other physical links. 5) As we understand it today no one uses either Insert Zones or Secondary Headers. CNES adds time to its TM frames which could be considered an Insert Zone, however we doubt that CNES defines a secondary header for this usage. 6) This document does not invalidate any of the current services being used for TM, AOS or TC but does allow future missions to more fully utilize the proposed flexibilities. As an example, there is no reason why a mission could not require a secondary header to be of fixed length and be included in each frame in the VC, but new missions with greater capabilities could utilize the flexibly provided by the redefinition of the Secondary header. 7) This approach defines a secondary header for TC, TM, and AOS. (Note that Proximity-1 is not included because it neither contains Virtual Channels nor a proposed Security Header.) The security would be put on by the user on the frame, any insert data that is put in by the mission Master Channel assembler would be outside the user's purview. The proposal states that we could accommodate Insert Zones for a master channel to be backward compatible for an explicit need that we presently don't have. Greg Kazz Chairman SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Thu Jul 23 17:38:30 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Thu, 23 Jul 2009 10:38:30 -0700 Subject: [Sls-slp] Restrictions on Services within TM Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45B40B3989@ALTPHYEMBEVSP10.RES.AD.JPL> All, Can any of you help provide the rationale as to why these restrictions on services in the current CCSDS TM Space Data Link Protocol book exist? I am having a difficult time in trying to come up with such a rationale. Perhaps these restrictions are no longer valid? The text below is copied from section 2.2.4 of the current CCSDS TM Space Data Link Protocol book: Restrictions on Services There are some restrictions on the services provided on a Physical Channel: a) if the Master Channel Frame Service exists on a Master Channel, other services shall not exist simultaneously on that Master Channel; b) on one Master Channel, the Virtual Channel Operational Control Field Service shall not exist simultaneously with the Master Channel Operational Control Field Service; c) if the Virtual Channel Frame Service exists on a Virtual Channel, other services shall not exist simultaneously on that Virtual Channel; d) on one Virtual Channel, the Virtual Channel Packet (VCP) Service shall not exist simultaneously with the Virtual Channel Access Service. thanks and best regards, Greg Kazz Chairman CCSDS SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Thu Jul 23 19:51:33 2009 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (313B)) Date: Thu, 23 Jul 2009 12:51:33 -0700 Subject: [Sls-slp] Restrictions on Services within TM In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45B40B3989@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: Greg, B) and D) are there because they are exclusive. In other words you can't have Packet service and VCA service on the same VC but I too don't understand the other restrictions. On 7/23/09 10:38 AM, "Kazz, Greg J (313B)" wrote: All, Can any of you help provide the rationale as to why these restrictions on services in the current CCSDS TM Space Data Link Protocol book exist? I am having a difficult time in trying to come up with such a rationale. Perhaps these restrictions are no longer valid? The text below is copied from section 2.2.4 of the current CCSDS TM Space Data Link Protocol book: Restrictions on Services There are some restrictions on the services provided on a Physical Channel: a) if the Master Channel Frame Service exists on a Master Channel, other services shall not exist simultaneously on that Master Channel; b) on one Master Channel, the Virtual Channel Operational Control Field Service shall not exist simultaneously with the Master Channel Operational Control Field Service; c) if the Virtual Channel Frame Service exists on a Virtual Channel, other services shall not exist simultaneously on that Virtual Channel; d) on one Virtual Channel, the Virtual Channel Packet (VCP) Service shall not exist simultaneously with the Virtual Channel Access Service. thanks and best regards, Greg Kazz Chairman CCSDS SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyamada at pub.isas.jaxa.jp Mon Jul 27 07:39:22 2009 From: tyamada at pub.isas.jaxa.jp (Takahiro Yamada) Date: Mon, 27 Jul 2009 16:39:22 +0900 Subject: [Sls-slp] Restrictions on Services within TM In-Reply-To: <02D130BD9C29BB4AAD59B77342F7E25F45B40B3989@ALTPHYEMBEVSP10.RES.AD.JPL> References: <02D130BD9C29BB4AAD59B77342F7E25F45B40B3989@ALTPHYEMBEVSP10.RES.AD.JPL> Message-ID: <60BF7CF5-322D-4ACC-BE21-82A09FB1D3AD@pub.isas.jaxa.jp> Greg, > Can any of you help provide the rationale as to why these > restrictions on services in the current CCSDS TM Space Data Link > Protocol book exist? > a) if the Master Channel Frame Service exists on a Master > Channel, other > services shall not exist simultaneously on that Master Channel; > c) if the Virtual Channel Frame Service exists on a Virtual > Channel, > other services shall not exist simultaneously on that Virtual Channel; The Master/Virtual Channel Service is a very special service in the sense that no other protocol has such a service. From 2.2.3.6 and 2.2.3.9 of the same book, "The Master/Virtual Channel Frame (MCF/VCF) Service provides transfer of a sequence of fixed-length TM Transfer Frames of a Master/Virtual Channel, created by an independent protocol entity, across a space link." If other services are to be used on that Master/Virtual Channel, the "independent protocol entity" (mentioned above) should provide these services. Therefore, the service provider in question should not provide any other services on the same Master/Virtual Channel. Best regards, Takahiro Yamada. From greg.j.kazz at jpl.nasa.gov Mon Jul 27 23:24:55 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Mon, 27 Jul 2009 16:24:55 -0700 Subject: [Sls-slp] New SLS-SLP Task concerning proposed AOS, TM, TC FSH and Insert Zone Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45B40B3D51@ALTPHYEMBEVSP10.RES.AD.JPL> All, I have requested in the CWE that a new task for SLS-SLP WG be approved. You can visit the proposed new task at: Project Title: Common Frame Secondary Header (FSH) and Insert Zone definition and Usage across AOS, TM, and TC Space Data Link Protocols Click Here to View More Information Please visit the CWE under the following URL to examine the proposed pink sheet changes to the AOS, TC, and TM Space Data Link Protocol with the above goal of supporting the work being done in the Data Link Layer Security WG as well as making the books homogenous with respect to Insert Zone and FSH definition and usage. There are three files to be seen at the URL below: http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents%2fFSH_IZ&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2} Your comments are most welcome. best regards, Greg Kazz Chairman CCSDS SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Jul 28 18:45:57 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 28 Jul 2009 11:45:57 -0700 Subject: [Sls-slp] Added Frame Figures to CWE for FSH/Insert Zone SLP Task Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45B40B3E66@ALTPHYEMBEVSP10.RES.AD.JPL> All, The new figures modified in the draft pink sheets are not readable. Therefore I've attached a powerpoint presentation that contains them called: Frame Figures.ppt. You can view them in the same directory as the pink sheets for the AOS, TM, and TC Space Data link protocols. See http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents%2fFSH_IZ&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2} best regards, Greg Kazz Chairman CCSDS SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Jul 28 22:00:49 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Tue, 28 Jul 2009 15:00:49 -0700 Subject: [Sls-slp] FSH and Insert Zone diagrams now integrated into AOS, TC, TM draft pink sheets Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45B43CAE27@ALTPHYEMBEVSP10.RES.AD.JPL> All, I have placed three new documents on the CWE. See URL below. They contain 7-28-09 (July 28) in the file name to distinguish them from the previous versions. They contain the updated diagrams also found in the powerpoint files. http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents%2fFSH_IZ&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2} best regards, Greg Kazz Chairman SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Wed Jul 29 19:17:49 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Wed, 29 Jul 2009 12:17:49 -0700 Subject: [Sls-slp] Regarding the proposed FSH/Insert Zone Changes to AOS, TM, and TC Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45B43CAF44@ALTPHYEMBEVSP10.RES.AD.JPL> SLS-SLPers, Answers to Marjorie's questions are in RED. best regards, Greg Kazz Chairman SLS-SLP WG chair Ed and Greg, I am reviewing your Pink Sheets - so far, I have been looking only at the book for TM. There are a few points I have problems with, so this is a request for some clarification. I'm new to this security header stuff, so I could use a bit of help. 1. Context Are the proposed changes all intended to support the CCSDS security header for the data link layer? Or are there some additional purposes? **Primarily but we thought it was time to clear up the MC_FSH and VC_FSH ambiguity and to release the VC_FSH from the clutches of management and setups. In other words to fulfill the capability ascribed to the secondary header---announced presence by the flag, and self delimiting like packets** 2. Modifications to VC_FSH Service for TM The existing VC_FSH service allows the Frame Secondary Header Field to have different lengths on different VCs within a Master Channel. The length is fixed within a VC. The changes replace the existing fixed-length VC_FSH Service by a new variable-length VC_FSH Service. In the new service, the length of the Frame Secondary Header Field is variable within a Virtual Channel on a frame-by-frame basis. As a result, the length of the Transfer Frame Data Field is also variable on a frame-by-frame basis. This causes various problems which I won't go into now. What is the intended use of this facility? ***If an implementation relies on the secondary header being of the same length in each frame of a particular VC then the implementation could put constraints on the secondary user to have a fixed size and to be synchronized with the frame generation. This is a local matter on a spacecraft creator/recipient but does require added complexity for multimission service providers that provide secondary header services. **** The changes mention having multiple users of the VC_FSH Service within a VC. But there is (from the point of view of the TM Space Data Link Protocol) only one user of the Transfer Frame Data Fields of the frames within a VC: either the Virtual Channel Packet (VCP) Service or the VCA Service. [The VCP service could in theory have more than one user if it is handling multiple packet types, but even then the packets are placed into a single stream of frames.] So, the VC is carrying either: - a single stream of frames carrying bits of packets, or a single stream of VCA-SDUs. ***So where is the complexity? The secondary header service could just like the packet service multiplex multiple secondary headers into a frame (assuming of course that they will not be too long to fit in a single frame-a management issue). In the security header (which is a secondary header of a specific type we have a bit that signals the presence of another secondary header to follow the security header. *** Is it likely that the encryption and/or authentication requirements are going to vary within one of these streams on a frame-by-frame basis? ***NO** And if the requirements vary at this level, how can the variable-length VC_FSH Service contribute to supporting the requirements? How are the service inputs on different SAPs (VCP and VC_FSH) brought together inside the TM Space Data Link Protocol entity so that they end up together in the same frame? ***The process of building a frame is sequential. The insert zone is placed followed by the secondary header(s) and then the packet data is inserted. The first header pointer is computed by this later process and the SH flag is set if secondary header data is included. If one is trying to form the multiplexed packet data field in parallel and just drop it in place then secondary headers need to be constant size. Again its an implementation issue no a specification issue.**** Would it be an alternative to introduce new services such as VCPsec Service and VCAsec Service? Here the security requirements could be parameters on the SAP where the Packets or VCA-SDUs are presented to the TM Space Data Link Protocol entity. In performing the service, the protocol entity could coordinate the generation of the contents of the Transfer Frame Data Field with the generation of the contents of the security fields in the FSH. This avoids having to coordinate separate SAP requests to the (asynchronous) VCP service and the (synchronous) VC_FSH Service. ***This is implementation methodology and we need to investigate it further. *** 3. Removal of MC_FSH Service and existing form of VC_FSH Service for TM Clearly, the new facilities proposed in the changes are not backward-compatible with existing implementations. This is part of the price of adding the new link-layer security capabilities. However, the proposed changes are also removing existing services, such as the MC_FSH Service from TM. This introduces a potential future problem with forward compatibility because new implementations will not support the removed services. Why not keep the existing MC_FSH Service, as well as adding the new Master Channel Insert Service? ***We have keep the MC_FSH Service, we just changed its name and remove its influence on the secondary header flag. This field was a managed field but in presence and length, same as the Insert service. **** The changes are making substantial changes to existing services, such as changing the nature of the VC_FSH Service of TM. The service has been changed but the name has not, which could be confusing in some circumstances. Why not keep the existing VC_FSH Service, and add a new service called (for example) Virtual Channel Variable Frame Secondary Header (VC_VFSH) Service? *** The present specification provides all the fields to make the VC_FSH service dynamic and flexible (as we have done) but the words constrained it's flexibility for no apparent reason other than simplicity for a earlier era where simplicity was required.*** 4. Cryptographic functions inside the TM Space Data Link Protocol entity Section 2.3.1 of 132.0-B Pink Sheets contains a list starting with the text "The protocol entity performs the following protocol functions". The changes have added a new entry to the list: "Cryptographic functions as required utilizing Virtual Channel Secondary Header data." I didn't find any further mention of the cryptographic functions in the document. What is planned in this respect? How does the protocol entity interface to any support for the cryptographic activities? ***Again an implementation issue for which we may have to add text that is similar to the secondary header service implementation text.**** The current Cryptograph service White paper (in the process of being upgraded to a white book) is on the CCSDS CWE. If you want we can send you the materials on the security service spec as of now. Best regards, Marjorie -------------- next part -------------- An HTML attachment was scrubbed... URL: