<HTML>
<HEAD>
<TITLE>Re: RE : [Sls-sea-dls] A Homogeneous Approach to Secondary Headers/Insert Zones across TM, TC, and AOS</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>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.<BR>
<BR>
<BR>
On 7/17/09 8:58 AM, "Moury Gilles" <gilles.moury@cnes.fr> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE='font-size:12.0px'><FONT COLOR="#0000FF"><FONT FACE="Arial">Dear Greg,<BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">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.<BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">Nevertheless, I have the following remarks :<BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">- 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, ...</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> </FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">Therefore, any modification being done to AOS should not obsolete the insert service.<BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">- 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.<BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">- 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). <BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">- 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 <BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">Best regards,<BR>
</FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">Gilles<BR>
</FONT></FONT><FONT FACE="Arial">Gilles MOURY</FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE="Arial">CNES Toulouse</FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE='font-size:12.0px'><FONT FACE="Verdana, Helvetica, Arial"> <BR>
<BR>
</FONT><FONT FACE="Tahoma">-----Message d'origine-----<BR>
<B>De :</B> sls-sea-dls-bounces@mailman.ccsds.org [<a href="mailto:sls-sea-dls-bounces@mailman.ccsds.org]">mailto:sls-sea-dls-bounces@mailman.ccsds.org]</a> <B>De la part de</B> Kazz, Greg J (313B)<BR>
<B>Envoyé :</B> jeudi 16 juillet 2009 22:49<BR>
<B>À :</B> sls-slp@mailman.ccsds.org; sls-sea-dls@mailman.ccsds.org<BR>
<B>Cc :</B> Kuo, Neal R (313B)<BR>
<B>Objet :</B> [Sls-sea-dls] A Homogeneous Approach to Secondary Headers/Insert Zones across TM, TC, and AOS<BR>
<BR>
</FONT><FONT FACE="Verdana, Helvetica, Arial"> <BR>
<BR>
<BR>
</FONT></SPAN><FONT FACE="Verdana, Helvetica, Arial"><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'>Dear SLS-SLP WG members:<BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'> <BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'>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 <BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'> <BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'><a href="http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2}">http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2}</a><BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'> <BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'>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.<BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'> <BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'>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).<BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'> <BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'>Below is the rationale for this approach:<BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'> <BR>
</SPAN></FONT><SPAN STYLE='font-size:12.0px'> <BR>
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.)<BR>
<BR>
Background: <BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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. <BR>
<BR>
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. <BR>
<BR>
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. <BR>
<BR>
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.<BR>
<BR>
<BR>
<BR>
Greg Kazz<BR>
<BR>
Chairman SLS-SLP WG<BR>
<BR>
</SPAN><FONT SIZE="5"><SPAN STYLE='font-size:16.0px'> <BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
</SPAN></FONT>
</BODY>
</HTML>