[Sls-slp] Re: RE : [Sls-sea-dls] A Homogeneous Approach to Secondary Headers/Insert Zones across TM, TC, and AOS

[Greenberg, Edward (313B)]

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" <gilles.moury at cnes.fr> 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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20090717/349802cf/attachment.html>