<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<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 link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'>Dear SLS-SLP WG members:<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
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 size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
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 size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
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 size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
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 size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'>Below is the rationale for this approach:<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
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 size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>Greg Kazz<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=1 face=Verdana><span style='font-size:9.0pt;
font-family:Verdana'>Chairman SLS-SLP WG</span></font><o:p></o:p></p>
<p class=MsoNormal><font size=3 face=Arial><span style='font-size:12.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
</div>
</body>
</html>