<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:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Then I must agree with you all
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">….we keep the header length as it is now (i.e., 32 bits) but we use only 8 bits for the proto and the remaining 5 go reserved, as from Keith suggestion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Tomaso<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:dimgray">————————————————————————</span><span style="color:#1F497D">
<br>
</span><b><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:dimgray">Deutsches Zentrum für Luft- und Raumfahrt</span></b><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:dimgray"> (DLR)</span><span style="color:#1F497D">
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:dimgray">German Aerospace Center</span><span style="color:#1F497D">
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:dimgray">Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany</span><span style="color:#1F497D">
<o:p></o:p></span></p>
<p class="MsoNormal"><b><span lang="IT" style="font-size:10.0pt;font-family:"Arial","sans-serif";color:dimgray">Tomaso de Cola, Ph.D.</span></b><span lang="IT" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:dimgray">Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 |</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><a href="mailto:tomaso.decola@dlr.de"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">tomaso.decola@dlr.de</span></a>
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"><a href="http://www.dlr.de/kn/institut/abteilungen/san">http://www.dlr.de/kn/institut/abteilungen/san</a></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Scott, Keith L. [mailto:kscott@mitre.org]
<br>
<b>Sent:</b> Friday, February 05, 2016 15:56<br>
<b>To:</b> Gian.Paolo.Calzolari@esa.int; Cola, Tomaso de<br>
<b>Cc:</b> edward.greenberg@jpl.nasa.gov; greg.j.kazz@jpl.nasa.gov; peter.m.shames@jpl.nasa.gov; sls-slp@mailman.ccsds.org<br>
<b>Subject:</b> Re: [Sls-slp] CCSDS definition of Protocol IDs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">Sorry, this was more in response to Tomaso’s text: <span style="color:red">(TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a
total of 32 bits</span>.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">I think I’m agreeing with you. :)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">—keith<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-family:"Calibri","sans-serif";color:black">From: </span></b><span style="font-family:"Calibri","sans-serif";color:black">Gian Calzolari <<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>><br>
<b>Date: </b>Friday, February 5, 2016 at 9:48 AM<br>
<b>To: </b>"Scott, Keith L." <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>><br>
<b>Cc: </b>Edward Greenberg <<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>>, Greg Kazz <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>>, Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>>,
"<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>" <<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>>, "<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>" <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>><br>
<b>Subject: </b>Re: [Sls-slp] CCSDS definition of Protocol IDs<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">Sorry Keith but I am quite puzzled as the mail you forward is not the mail I sent......</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">I just said: Also to be said that USLP is a little schizophrenic as sometimes it looks to saving bits and sometimes emphasises that USLP framers are so long that it is not worth
saving bits :o)</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">Regards</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"> <br>
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">Gian Paolo</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"> <br>
<br>
<br>
<br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">"Scott, Keith L." <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">"<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>"
<<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>>, "<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>" <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Cc: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">"<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>"
<<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>>, "<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>>, "<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>"
<<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>>, "<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>" <<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"> <br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">05/02/2016 15:39</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">Re: [Sls-slp] CCSDS definition of Protocol IDs</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">
<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">
</span></div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-family:"Calibri","sans-serif";color:black">From:
</span></b><span style="font-family:"Calibri","sans-serif";color:black">Gian Calzolari <<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>><br>
<b>Date: </b>Friday, February 5, 2016 at 8:03 AM<br>
<b>To: </b>"<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>" <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>><br>
<b>Cc: </b>Edward Greenberg <<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>>, Greg Kazz <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>>, "Scott, Keith L." <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>,
Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>>, "<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>" <<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>><br>
<b>Subject: </b>RE: [Sls-slp] CCSDS definition of Protocol IDs<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">Also to be said that USLP is a little schizophrenic as sometimes it looks to saving bits and sometimes emphasises that USLP framers are so long that it is not worth
saving bits :o)</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><br>
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">Have a nice week end</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">
<br>
<br>
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">Gian Paolo</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">
<br>
<br>
<br>
<br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">From: <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">To: <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>, <<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>>, <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">Cc: <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>>, <<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>>, <<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">Date: 05/02/2016 14:00</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black">Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">
<hr size="2" width="100%" noshade="" style="color:black" align="center">
</span></div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><br>
<br>
<br>
</span><tt><span style="font-size:10.0pt">Keith,</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<tt>I think you raised an important point: compactness vs. processing complexity. I think that however we should see this trade-off looking at the entire Transfer frame data field header, which contains the protocol field (s). At the moment it is 32-bit aligned
<b><span style="color:red">(TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits</span></b>, which is something always desirable. If we reduce the protocol IDs from a total of 13 down to 8, the header
becomes of 27 bits. If we reduce from 13 to 6, it becomes 25 bits. </tt><br>
<tt>I'm certainly fine with the 8 bits, I just wanted to avoid a large field (the initial 13 bits), which will be used only for very small extent of it.</tt><br>
<br>
<tt>Regards,</tt><br>
<br>
<tt>Tomaso</tt><br>
<br>
<tt>———————————————————————— </tt><br>
<tt>Deutsches Zentrum für Luft- und Raumfahrt (DLR) </tt><br>
<tt>German Aerospace Center </tt><br>
<tt>Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
</tt><br>
<tt>Tomaso de Cola, Ph.D. </tt><br>
<tt>Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | <a href="mailto:tomaso.decola@dlr.de">
<span style="color:black">tomaso.decola@dlr.de</span></a> </tt><br>
</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://www.dlr.de/kn/institut/abteilungen/san"><tt><span style="font-size:10.0pt;color:black">http://www.dlr.de/kn/institut/abteilungen/san</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<br>
<br>
<tt>> -----Original Message-----</tt><br>
<tt>> From: Scott, Keith L. [</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:kscott@mitre.org"><tt><span style="font-size:10.0pt;color:black">mailto:kscott@mitre.org</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">]</span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> Sent: Friday, February 05, 2016 13:34</tt><br>
<tt>> To: Cola, Tomaso de; <a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>;</tt><br>
<tt>> <a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a></tt><br>
<tt>> Cc: <a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>;
<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>; sls-</tt><br>
<tt>> <a href="mailto:slp@mailman.ccsds.org">slp@mailman.ccsds.org</a></tt><br>
<tt>> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs</tt><br>
<tt>> </tt><br>
<tt>> So what’s the motivation for saving two bits? The delta power / bandwidth</tt><br>
<tt>> needed is minimal, it requires more non-byte-aligned processing, and it sets us</tt><br>
<tt>> up for needing that 65th protocol that we just can’t quite get…</tt><br>
<tt>> </tt><br>
<tt>> Why not just go with an 8-bit field that is one thing (without the protocols and</tt><br>
<tt>> extensions distinction)? Is it that the extension field is optional (incurring more</tt><br>
<tt>> data-dependent header processing)?</tt><br>
<tt>> </tt><br>
<tt>> Sorry, but while optimizing bit field sizes down to sub-byte level seems like a</tt><br>
<tt>> useful thing, it also seems to have bitten us a number of times.</tt><br>
<tt>> </tt><br>
<tt>> —keith</tt><br>
<tt>> </tt><br>
<tt>> </tt><br>
<tt>> </tt><br>
<tt>> On 2/5/16, 3:22 AM, "<a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a> on behalf of</tt><br>
<tt>> <a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>" <<a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a> on behalf of</tt><br>
<tt>> <a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>> wrote:</tt><br>
<tt>> </tt><br>
<tt>> >Personally I find this approach more efficient than what proposed in the book</tt><br>
<tt>> right now. One could wonder whether we could go for 6-bits instead of 8-bits so</tt><br>
<tt>> that we have 32 protocol IDs and 32 extensions, because I tend to think that 224</tt><br>
<tt>> extended protocol ids (as from your approach) are definitely too much, also</tt><br>
<tt>> considering the possible protocol evolution in the space domain in the next 10-</tt><br>
<tt>> 20 years according to what we have seen in the last 10 years. For instance the</tt><br>
<tt>> extended protocol IDs in the encaps are all unassigned, meaning that from the</tt><br>
<tt>> time the protocol was designed there was no use. In this discussion, as</tt><br>
<tt>> mentioned in my previous e-mail, it would be also interesting to see how</tt><br>
<tt>> encapsulation of IP datagrams will be carried out: do we still use of IPoC or do</tt><br>
<tt>> we transport IP datagrams directly in USLP and we use the Proto ID field to</tt><br>
<tt>> transport the current IPE?</tt><br>
<tt>> ></tt><br>
<tt>> >Tomaso</tt><br>
<tt>> ></tt><br>
<tt>> >------------------------</tt><br>
<tt>> >Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center</tt><br>
<tt>> >Institute of Communications and Navigation | Satellite Networks |</tt><br>
<tt>> >Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D.</tt><br>
<tt>> >Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 |</tt><br>
<tt>> ><a href="mailto:tomaso.decola@dlr.de">tomaso.decola@dlr.de</a> </tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://www.dlr.de/kn/institut/abteilungen/san"><tt><span style="font-size:10.0pt;color:black">http://www.dlr.de/kn/institut/abteilungen/san</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> ></tt><br>
<tt>> >> -----Original Message-----</tt><br>
<tt>> >> From: Greenberg, Edward (312B) [</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:edward.greenberg@jpl.nasa.gov"><tt><span style="font-size:10.0pt;color:black">mailto:edward.greenberg@jpl.nasa.gov</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">]</span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> Sent: Thursday, February 04, 2016 23:24</tt><br>
<tt>> >> To: Cola, Tomaso de; Kazz, Greg J (312B)</tt><br>
<tt>> >> Cc: Shames, Peter M (312B); <a href="mailto:Gian.Paolo.Calzolari@esa.int">
Gian.Paolo.Calzolari@esa.int</a>; sls-</tt><br>
<tt>> >> <a href="mailto:slp@mailman.ccsds.org">slp@mailman.ccsds.org</a></tt><br>
<tt>> >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs</tt><br>
<tt>> >></tt><br>
<tt>> >> I think so...Do you have a problem with that?</tt><br>
<tt>> >></tt><br>
<tt>> >> -----Original Message-----</tt><br>
<tt>> >> From: <a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a> [</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:Tomaso.deCola@dlr.de"><tt><span style="font-size:10.0pt;color:black">mailto:Tomaso.deCola@dlr.de</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">]</span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> Sent: Thursday, February 04, 2016 10:00 AM</tt><br>
<tt>> >> To: Greenberg, Edward (312B); Kazz, Greg J (312B)</tt><br>
<tt>> >> Cc: Shames, Peter M (312B); <a href="mailto:Gian.Paolo.Calzolari@esa.int">
Gian.Paolo.Calzolari@esa.int</a>; sls-</tt><br>
<tt>> >> <a href="mailto:slp@mailman.ccsds.org">slp@mailman.ccsds.org</a></tt><br>
<tt>> >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs</tt><br>
<tt>> >></tt><br>
<tt>> >> Hi Ed,</tt><br>
<tt>> >></tt><br>
<tt>> >> So if I get it correctly, we'll have a unique field for the proto</tt><br>
<tt>> >> spanning 8 bits,</tt><br>
<tt>> >> where:</tt><br>
<tt>> >></tt><br>
<tt>> >> 0-31: regular protocol id</tt><br>
<tt>> >> 32-255: extension protocol id</tt><br>
<tt>> >></tt><br>
<tt>> >> Then probably the cases '0' and '255' could go reserved for special uses.</tt><br>
<tt>> >></tt><br>
<tt>> >> Is my interpretation correct?</tt><br>
<tt>> >> ________________________________________</tt><br>
<tt>> >> Da: Greenberg, Edward (312B) [<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>]</tt><br>
<tt>> >> Inviato: giovedì 4 febbraio 2016 18.18</tt><br>
<tt>> >> A: Cola, Tomaso de; Kazz, Greg J (312B)</tt><br>
<tt>> >> Cc: Shames, Peter M (312B); <a href="mailto:Gian.Paolo.Calzolari@esa.int">
Gian.Paolo.Calzolari@esa.int</a>; sls-</tt><br>
<tt>> >> <a href="mailto:slp@mailman.ccsds.org">slp@mailman.ccsds.org</a></tt><br>
<tt>> >> Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs</tt><br>
<tt>> >></tt><br>
<tt>> >> I think that Tomaso's observation is accurate. The USLP PID field is</tt><br>
<tt>> >> 5 bits allowing 32 possible PIPs. I believe that that number is</tt><br>
<tt>> >> sufficient but we need to allow for our possible miscalculation so we</tt><br>
<tt>> >> specified one of those values to extend the PID field. It makes no sense to</tt><br>
<tt>> make the extension anything other</tt><br>
<tt>> >> than an octet. The question is how the contents of the extended field is</tt><br>
<tt>> >> interpreted. My recommendation is that we have 32 IDs in the 5 bit</tt><br>
<tt>> >> field and these should be interpreted as an 8 bit field with 3 leading zero.</tt><br>
<tt>> These 32 IDs</tt><br>
<tt>> >> would be reserved in the extension field. Thus the extension field provides</tt><br>
<tt>> an</tt><br>
<tt>> >> additional 256-32 PID and the value of the all PIDs can be a unique</tt><br>
<tt>> >> digital value. This gives us a maximum of 255 unique PIDs.</tt><br>
<tt>> >></tt><br>
<tt>> >> From: <a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a> [</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:sls-slp-"><tt><span style="font-size:10.0pt;color:black">mailto:sls-slp-</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> <a href="mailto:bounces@mailman.ccsds.org">bounces@mailman.ccsds.org</a>] On Behalf Of
<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a></tt><br>
<tt>> >> Sent: Thursday, February 04, 2016 1:32 AM</tt><br>
<tt>> >> To: Kazz, Greg J (312B)</tt><br>
<tt>> >> Cc: Shames, Peter M (312B); <a href="mailto:Gian.Paolo.Calzolari@esa.int">
Gian.Paolo.Calzolari@esa.int</a>; sls-</tt><br>
<tt>> >> <a href="mailto:slp@mailman.ccsds.org">slp@mailman.ccsds.org</a></tt><br>
<tt>> >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs</tt><br>
<tt>> >></tt><br>
<tt>> >> Greg,</tt><br>
<tt>> >></tt><br>
<tt>> >> Still coming back to the point of the PID size, I perfectly</tt><br>
<tt>> >> understand that it is better to have some margin to avoid problems</tt><br>
<tt>> >> coming up later. On the other hand, I notice that summing up</tt><br>
<tt>> >> PID+extensions we have 9 bits, which are even more than those made</tt><br>
<tt>> >> available with the Proto field (8 bits) in IPv4. So the question is,</tt><br>
<tt>> >> do we really need such large number? Or, said in different terms,</tt><br>
<tt>> >> what are the requirements we want to target with such setting? I</tt><br>
<tt>> >> would have expected that accommodating up to 64 protocol combinations</tt><br>
<tt>> >> would have been sufficient. Finally, I'm wondering how USLP</tt><br>
<tt>> >> encapsulation works in the case of</tt><br>
<tt>> >> IPoC: do we still have the IPE header or is this somehow mapped in</tt><br>
<tt>> >> the</tt><br>
<tt>> >> PID+extensions of USLP? In any case, I imagine these special cases</tt><br>
<tt>> >> PID+(along with</tt><br>
<tt>> >> any others) will be properly illustrated in the green book.</tt><br>
<tt>> >></tt><br>
<tt>> >> Thanks in advance for your comments on these thoughts.</tt><br>
<tt>> >></tt><br>
<tt>> >> Best Regards,</tt><br>
<tt>> >></tt><br>
<tt>> >> Tomaso</tt><br>
<tt>> >></tt><br>
<tt>> >> ------------------------</tt><br>
<tt>> >> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace</tt><br>
<tt>> >> Center Institute of Communications and Navigation | Satellite</tt><br>
<tt>> >> Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola,</tt><br>
<tt>> Ph.D.</tt><br>
<tt>> >> Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 |</tt><br>
<tt>> >> <a href="mailto:tomaso.decola@dlr.de">tomaso.decola@dlr.de</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:tomaso.decola@dlr.de"><tt><span style="font-size:10.0pt;color:black">mailto:tomaso.decola@dlr.de</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> </tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://www.dlr.de/kn/institut/abteilungen/san"><tt><span style="font-size:10.0pt;color:black">http://www.dlr.de/kn/institut/abteilungen/san</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >></tt><br>
<tt>> >> From: <a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:sls-slp-"><tt><span style="font-size:10.0pt;color:black">mailto:sls-slp-</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> <a href="mailto:bounces@mailman.ccsds.org">bounces@mailman.ccsds.org</a>> [</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:sls-slp-bounces@mailman.ccsds.org"><tt><span style="font-size:10.0pt;color:black">mailto:sls-slp-bounces@mailman.ccsds.org</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">]</span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> On Behalf Of Kazz, Greg J (312B)</tt><br>
<tt>> >> Sent: Wednesday, February 03, 2016 18:03</tt><br>
<tt>> >> To: <a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:Gian.Paolo.Calzolari@esa.int"><tt><span style="font-size:10.0pt;color:black">mailto:Gian.Paolo.Calzolari@esa.int</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> Cc: Shames, Peter M (312B); SLS-SLP Mailing List</tt><br>
<tt>> >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs</tt><br>
<tt>> >></tt><br>
<tt>> >> G.P.,</tt><br>
<tt>> >></tt><br>
<tt>> >> We have learned through the lesson of IPoC that a 3 bit PID is too</tt><br>
<tt>> >> small and restrictive, so that is why in USLP we defined the PID to</tt><br>
<tt>> >> be bigger I.e., 5 bits also limited because the first 3 bits are used up by the</tt><br>
<tt>> TFDZ construction rules.</tt><br>
<tt>> >> I agree that the extended protocol ID field of 8 bits is too big so</tt><br>
<tt>> >> using the first 4 bits for the PID extension would give us 9 total</tt><br>
<tt>> >> bits or 512 combinations for PIDs. That would leave 4 bits of spares</tt><br>
<tt>> thereafter.</tt><br>
<tt>> >> I don't see any compelling reason to create a separate field just for COP.</tt><br>
<tt>> >></tt><br>
<tt>> >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields:</tt><br>
<tt>> >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits,</tt><br>
<tt>> >> mandatory);</tt><br>
<tt>> >> b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory);</tt><br>
<tt>> >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits,</tt><br>
<tt>> optional); ;-</tt><br>
<tt>> >> --> same as</tt><br>
<tt>> >> </tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.h"><tt><span style="font-size:10.0pt;color:black">http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.h</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> tml</tt><br>
<tt>> >> .aslo can contain ipe_header values</tt><br>
<tt>> >> c2) Spare (4 bits, optional);</tt><br>
<tt>> >> d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits,</tt><br>
<tt>> optional)</tt><br>
<tt>> >> ).</tt><br>
<tt>> >></tt><br>
<tt>> >> Regards,</tt><br>
<tt>> >> Greg</tt><br>
<tt>> >></tt><br>
<tt>> >> From: "<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:Gian.Paolo.Calzolari@esa.int"><tt><span style="font-size:10.0pt;color:black">mailto:Gian.Paolo.Calzolari@esa.int</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>"</span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> <<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:Gian.Paolo.Calzolari@esa.int"><tt><span style="font-size:10.0pt;color:black">mailto:Gian.Paolo.Calzolari@esa.int</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> Date: Wednesday, February 3, 2016 at 2:38 AM</tt><br>
<tt>> >> To: "Kazz, Greg J (313B)"</tt><br>
<tt>> >> <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:greg.j.kazz@jpl.nasa.gov"><tt><span style="font-size:10.0pt;color:black">mailto:greg.j.kazz@jpl.nasa.gov</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> Cc: "Shames, Peter M (312B)"</tt><br>
<tt>> >> <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:peter.m.shames@jpl.nasa.gov"><tt><span style="font-size:10.0pt;color:black">mailto:peter.m.shames@jpl.nasa.gov</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>>,</span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> SLS- SLP Mailing List <<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:sls-"><tt><span style="font-size:10.0pt;color:black">mailto:sls-</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> <a href="mailto:slp@mailman.ccsds.org">slp@mailman.ccsds.org</a>>></tt><br>
<tt>> >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs</tt><br>
<tt>> >></tt><br>
<tt>> >> Greg,</tt><br>
<tt>> >> assuming that USLP will be able to carry 2**13 = 8192</tt><br>
<tt>> >> different upper layers protocols look to me as thinking big.</tt><br>
<tt>> >> Though I like optimism I wonder whether this is appropriate.</tt><br>
<tt>> >></tt><br>
<tt>> >> Indeed </tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://sanaregistry.org/r/protocol_id/protocol_id.html"><tt><span style="font-size:10.0pt;color:black">http://sanaregistry.org/r/protocol_id/protocol_id.html</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">
defines</span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> the Protocol Identifier for Encapsulation Service over 3 bits with</tt><br>
<tt>> >> Extended Protocol Identifier for Encapsulation Service over 4 bits</tt><br>
<tt>> >> (i.e. a total of 7 bits but not really 2**7 = 128 different protocol</tt><br>
<tt>> >> as the construction allows 16 +6 protocols as some values are</tt><br>
<tt>> >> reserved (see</tt><br>
<tt>> </tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html"><tt><span style="font-size:10.0pt;color:black">http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">
).</span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> I there a good reason for thinking that USLP could carry 8192</tt><br>
<tt>> >> different while Encapsulation Packet is limited to 22?</tt><br>
<tt>> >></tt><br>
<tt>> >> If not please consider the following alternative definition</tt><br>
<tt>> >> (justified also by the current definition of the fields containing</tt><br>
<tt>> >> either a protocol ID or a COP directive indication):</tt><br>
<tt>> >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields:</tt><br>
<tt>> >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits,</tt><br>
<tt>> >> mandatory);</tt><br>
<tt>> >> b1) COP usage (2 bits, mandatory); ---> see below</tt><br>
<tt>> >> b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---></tt><br>
<tt>> same</tt><br>
<tt>> >> a<a href="shttp://sanaregistry.org/r/protocol_id/protocol_id.html">shttp://sanaregistry.org/r/protocol_id/protocol_id.html</a></tt><br>
<tt>> >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits,</tt><br>
<tt>> optional); ;-</tt><br>
<tt>> >> --> same as</tt><br>
<tt>> >> </tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html"><tt><span style="font-size:10.0pt;color:black">http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> c2) Spare (4 bits, optional); ;--> good for a link to IPoC?????</tt><br>
<tt>> >> d) First Header Pointer or Last Valid Octet (16 bits, optional).</tt><br>
<tt>> >></tt><br>
<tt>> >></tt><br>
<tt>> >> COP usage (2 bits, mandatory);</tt><br>
<tt>> >> 00 = No directives</tt><br>
<tt>> >> 01 = COP-1 directives are contained within the TFDZ.</tt><br>
<tt>> >> 10 = COP-P directives are contained within the TFDZ</tt><br>
<tt>> >> 11 = reserved</tt><br>
<tt>> >></tt><br>
<tt>> >> Regards</tt><br>
<tt>> >></tt><br>
<tt>> >> Gian Paolo</tt><br>
<tt>> >></tt><br>
<tt>> >></tt><br>
<tt>> >></tt><br>
<tt>> >> From: "Kazz, Greg J (312B)"</tt><br>
<tt>> >> <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:greg.j.kazz@jpl.nasa.gov"><tt><span style="font-size:10.0pt;color:black">mailto:greg.j.kazz@jpl.nasa.gov</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> To: "Shames, Peter M (312B)"</tt><br>
<tt>> >> <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:peter.m.shames@jpl.nasa.gov"><tt><span style="font-size:10.0pt;color:black">mailto:peter.m.shames@jpl.nasa.gov</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> Cc: "<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:sls-slp@mailman.ccsds.org"><tt><span style="font-size:10.0pt;color:black">mailto:sls-slp@mailman.ccsds.org</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>"</span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> <sls-</tt><br>
<tt>> >> <a href="mailto:slp@mailman.ccsds.org">slp@mailman.ccsds.org</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:sls-slp@mailman.ccsds.org"><tt><span style="font-size:10.0pt;color:black">mailto:sls-slp@mailman.ccsds.org</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> Date: 02/02/2016 19:48</tt><br>
<tt>> >> Subject: [Sls-slp] CCSDS definition of Protocol IDs</tt><br>
<tt>> >> Sent by: <a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:sls-slp-"><tt><span style="font-size:10.0pt;color:black">mailto:sls-slp-</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> <a href="mailto:bounces@mailman.ccsds.org">bounces@mailman.ccsds.org</a>></tt><br>
<tt>> >> ________________________________</tt><br>
<tt>> >></tt><br>
<tt>> >></tt><br>
<tt>> >></tt><br>
<tt>> >> Peter,</tt><br>
<tt>> >></tt><br>
<tt>> >> USLP is planning on defining a Protocol Id (PID) field and an</tt><br>
<tt>> >> Extended Protocol ID field in the Transfer Frame Data Field Header.</tt><br>
<tt>> >> Encapsulation Service currently defines Protocol ID to be a 3 bit</tt><br>
<tt>> >> field, followed by an optional Protocol Extension Field of 8 bits for a total of</tt><br>
<tt>> 11 bits.</tt><br>
<tt>> >> There is a SANA registry for PIDs under</tt><br>
<tt>> >> </tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://sanaregistry.org/r/protocol_id/protocol_id.html"><tt><span style="font-size:10.0pt;color:black">http://sanaregistry.org/r/protocol_id/protocol_id.html</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >></tt><br>
<tt>> >> IPoC also defines PIDs as well for the IPE header. See</tt><br>
<tt>> >> </tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://sanaregistry.org/r/ipe_header/ipe_header.html"><tt><span style="font-size:10.0pt;color:black">http://sanaregistry.org/r/ipe_header/ipe_header.html</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> In this case, the smallest size IPE header is 8 bits, but it has a</tt><br>
<tt>> >> multiple octet extension capability beyond 1 octet.</tt><br>
<tt>> >></tt><br>
<tt>> >> USLP currently in draft form, has defined the PID to be 5 bits long,</tt><br>
<tt>> >> followed by an optional Protocol Extension Field of 8 bits for a total of 13</tt><br>
<tt>> bits.</tt><br>
<tt>> >> Below is an approach from Ed Greenberg, that shows that the</tt><br>
<tt>> >> Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email</tt><br>
<tt>> message below.</tt><br>
<tt>> >></tt><br>
<tt>> >> Question - What does CCSDS, from an organization point of view,</tt><br>
<tt>> >> envision a need to define PIDs across all of CCSDS not just USLP or</tt><br>
<tt>> >> Encap service ? Or is it appropriate for USLP to define the term,</tt><br>
<tt>> >> Protocol ID and have it apply locally I.e., only to the USLP links ?</tt><br>
<tt>> >> In the review of USLP, we will address questions like, "Is a 13 bit</tt><br>
<tt>> >> PID name space sufficient for all agency needs ?"</tt><br>
<tt>> >></tt><br>
<tt>> >> Your thoughts ?</tt><br>
<tt>> >></tt><br>
<tt>> >> Thanks!</tt><br>
<tt>> >> Greg</tt><br>
<tt>> >></tt><br>
<tt>> >> From: "Greenberg, Edward (312B)"</tt><br>
<tt>> >></tt><br>
<tt>> <<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:edward.greenberg@jpl.nasa.gov"><tt><span style="font-size:10.0pt;color:black">mailto:edward.greenberg@jpl.nasa.gov</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> Date: Tuesday, February 2, 2016 at 9:53 AM</tt><br>
<tt>> >> To: "Kazz, Greg J (313B)"</tt><br>
<tt>> >> <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:greg.j.kazz@jpl.nasa.gov"><tt><span style="font-size:10.0pt;color:black">mailto:greg.j.kazz@jpl.nasa.gov</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">>></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> Subject: PIDs</tt><br>
<tt>> >></tt><br>
<tt>> >> Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when</tt><br>
<tt>> >> 5 bits =11111</tt><br>
<tt>> >></tt><br>
<tt>> >> Thus if we assume that the PIP space for Encap in 5 bit form we get</tt><br>
<tt>> >> 11xxx+xxxxxxxx</tt><br>
<tt>> >></tt><br>
<tt>> >></tt><br>
<tt>> >> The only issue is that new PIDs for USLP that have their first 2 bits</tt><br>
<tt>> >> as 00, 01 or</tt><br>
<tt>> >> 10 don't map to</tt><br>
<tt>> >> Encap_______________________________________________</tt><br>
<tt>> >> Sls-slp mailing list</tt><br>
<tt>> >> <a href="mailto:Sls-slp@mailman.ccsds.org">Sls-slp@mailman.ccsds.org</a><</tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="mailto:Sls-slp@mailman.ccsds.org"><tt><span style="font-size:10.0pt;color:black">mailto:Sls-slp@mailman.ccsds.org</span></tt></a></span><tt><span style="font-size:10.0pt;color:black">></span></tt><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >> </tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp"><tt><span style="font-size:10.0pt;color:black">http://mailman.ccsds.org/mailman/listinfo/sls-slp</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<tt>> >></tt><br>
<tt>> >> This message and any attachments are intended for the use of the</tt><br>
<tt>> >> addressee or addressees only.</tt><br>
<tt>> >></tt><br>
<tt>> >> The unauthorised disclosure, use, dissemination or copying (either in</tt><br>
<tt>> >> whole or in part) of its</tt><br>
<tt>> >></tt><br>
<tt>> >> content is not permitted.</tt><br>
<tt>> >></tt><br>
<tt>> >> If you received this message in error, please notify the sender and</tt><br>
<tt>> >> delete it from your system.</tt><br>
<tt>> >></tt><br>
<tt>> >> Emails can be altered and their integrity cannot be guaranteed by the</tt><br>
<tt>> sender.</tt><br>
<tt>> >></tt><br>
<tt>> >></tt><br>
<tt>> >></tt><br>
<tt>> >> Please consider the environment before printing this email.</tt><br>
<tt>> ></tt><br>
<tt>> ></tt><br>
<tt>> >_______________________________________________</tt><br>
<tt>> >Sls-slp mailing list</tt><br>
<tt>> ><a href="mailto:Sls-slp@mailman.ccsds.org">Sls-slp@mailman.ccsds.org</a></tt><br>
<tt>> ></tt></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp"><tt><span style="font-size:10.0pt;color:black">http://mailman.ccsds.org/mailman/listinfo/sls-slp</span></tt></a></span><span style="font-size:10.0pt;font-family:"Courier New";color:black"><br>
<br>
</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
<pre><span style="color:black">This message and any attachments are intended for the use of the addressee or addressees only.<o:p></o:p></span></pre>
<pre><span style="color:black">The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its<o:p></o:p></span></pre>
<pre><span style="color:black">content is not permitted.<o:p></o:p></span></pre>
<pre><span style="color:black">If you received this message in error, please notify the sender and delete it from your system.<o:p></o:p></span></pre>
<pre><span style="color:black">Emails can be altered and their integrity cannot be guaranteed by the sender.<o:p></o:p></span></pre>
<pre><span style="color:black"><o:p> </o:p></span></pre>
<pre><span style="color:black">Please consider the environment before printing this email.<o:p></o:p></span></pre>
</div>
</div>
</div>
</div>
</body>
</html>