<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Idle patterns have always been at the users discretion.  Some patterns are better than others for different coding.  Since the data is discarded the spec specifiers decided not to define a specific pattern and leave it up to the mission people to decide
 what patter they wanted to use.</div>
<div><br>
</div>
<div>I would like to get your opinion on this proposal.   The SPP has gone adrift but it would be nice to maintain the packet format.  I am not interested in the way "service" is described because it is an implementation that is currently not used and mandatory.
  The main change that I would like to see is to allow for the inclusion of standard labels in the secondary header.  But there are issues:</div>
<div>    1.  Some mission use the secondary header flag for non-standard headers </div>
<div>    2.  The missions have the prerogative to assign APIDs and ESA has established there own usage in the PUS</div>
<div> I think that we need to maintain compatibility  with current use so I would suggest the following:</div>
<ol>
<li>Assign a specific APID that informs the system that the secondary header contains standard labels</li><li>Identify a version mechanism for labels and a mechanism for identifying a succession of labels</li><li>Create a book to contain standard labels that are register in SANA:
<ul>
<li>Identity label with desired APID and possibly other info like Quality of Service and maybe format ID</li><li>Security label for security sequence number etal</li><li>Routing label with source and destination addresses for short relaying (I.e. lander to orbiter to lander) (direct or multicast)</li></ul>
</li></ol>
<div>This way the current implementation with all the current management aspects are not affected. </div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>SLS-SLP <<a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a>> on behalf of John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, January 31, 2018 at 12:41 PM<br>
<span style="font-weight:bold">To: </span>SLS-SLP WG <<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>><br>
<span style="font-weight:bold">Subject: </span>[Sls-slp] Idle Packet Idle Pattern<br>
</div>
<div><br>
</div>
<div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></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]-->
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt">Dear All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I’m sorry that I wasn’t able to participate in today’s telecon, due to a prior commitment. Having not participated, I don’t know the final fate of the SPP book. But there is one other item that I came across
 that I’d like to bring to the WG’s attention as something else to consider in the process of cleaning up (or replacing) the SPP book.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">The Packet Processing function of the AOS SDLP includes generation of Idle Packets when no packets containing user data are available. The definition of “Idle Packet” is cross-referenced to the SPP book.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt">The SPP book states “</span><span style="font-size:12.0pt">If the Packet is an Idle Packet, the User Data Field shall contain Idle Data”, and follows this with the NOTE “The bit
 pattern of Idle Data is not specified in this Recommendation.” The trail goes cold there.<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt">A similar situation exists for the multiplexing schemes for VCs and MCs (that is they are not defined by the SDLP Recommended Standards), but in those cases the multiplexing schemes
 are identified as Managed Parameters. Given that “Managed Parameters” is another way of saying “stuff that has to be configured that is not defined in the book itself”, I suggest that the packet Idle Pattern also be treated as a Managed Parameter.
<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt">John<o:p></o:p></span></p>
</div>
</div>
</div>
</span>
</body>
</html>