<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v =
"urn:schemas-microsoft-com:vml" xmlns:o =
"urn:schemas-microsoft-com:office:office" xmlns:w =
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1619" name=GENERATOR>
<STYLE>
<!--
/* Font Definitions */
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</STYLE>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff size=2>Dear
Greg,</FONT></SPAN></DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=282132315-17072009></SPAN> </DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff
size=2>Nevertheless, I have the following remarks :</FONT></SPAN></DIV>
<DIV><SPAN class=282132315-17072009></SPAN> </DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff size=2>-
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 face=Arial color=#0000ff size=2>Therefore,
any modification being done to AOS should not obsolete the insert
service.</FONT></SPAN></DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff size=2>-
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.</FONT></SPAN></DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff size=2>- 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). </FONT></SPAN></DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff size=2>-
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 </FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff size=2>Best
regards,</FONT></SPAN></DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=282132315-17072009><FONT face=Arial color=#0000ff
size=2>Gilles</FONT></SPAN></DIV><!-- Converted from text/rtf format -->
<P><SPAN lang=fr><FONT face=Arial size=2>Gilles MOURY</FONT></SPAN> <BR><SPAN
lang=fr><FONT face=Arial size=2>CNES Toulouse</FONT></SPAN> </P>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=fr dir=ltr align=left><FONT face=Tahoma
size=2>-----Message d'origine-----<BR><B>De :</B>
sls-sea-dls-bounces@mailman.ccsds.org
[mailto:sls-sea-dls-bounces@mailman.ccsds.org] <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></DIV>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial">Dear SLS-SLP WG
members:<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial">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 <o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial">http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS-SLP%2fDraft%20Documents&FolderCTID=&View={16ACDA38-FFA3-4657-8F27-B166C23C24A2}<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial">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.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial">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).<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial">Below is the rationale for this
approach:<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Verdana size=1><SPAN
style="FONT-SIZE: 9pt; FONT-FAMILY: Verdana">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.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Verdana size=1><SPAN
style="FONT-SIZE: 9pt; FONT-FAMILY: Verdana"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Verdana size=1><SPAN
style="FONT-SIZE: 9pt; FONT-FAMILY: Verdana">Greg
Kazz<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Verdana size=1><SPAN
style="FONT-SIZE: 9pt; FONT-FAMILY: Verdana">Chairman SLS-SLP
WG</SPAN></FONT><o:p></o:p></P>
<P class=MsoNormal><FONT face=Arial size=3><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>