<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=iso-8859-1">
<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: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:0in;
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:0in;
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:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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]-->
</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">I think that Tomaso’s observation is accurate. The USLP PID field is 5 bits allowing 32 possible PIPs. I believe that that number is sufficient but we need
to allow for our possible miscalculation so we specified one of those values to extend the PID field. It makes no sense to make the extension anything other than an octet. The question is how the contents of the extended field is interpreted. My recommendation
is that we have 32 IDs in the 5 bit field and these should be interpreted as an 8 bit field with 3 leading zero. These 32 IDs would be reserved in the extension field. Thus the extension field provides an additional 256-32 PID and the value of the all PIDs
can be a unique digital value. This gives us a maximum of 255 unique PIDs. <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>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<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""> sls-slp-bounces@mailman.ccsds.org [mailto:sls-slp-bounces@mailman.ccsds.org]
<b>On Behalf Of </b>Tomaso.deCola@dlr.de<br>
<b>Sent:</b> Thursday, February 04, 2016 1:32 AM<br>
<b>To:</b> Kazz, Greg J (312B)<br>
<b>Cc:</b> Shames, Peter M (312B); Gian.Paolo.Calzolari@esa.int; 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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Greg,<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">Still coming back to the point of the PID size, I perfectly understand that it is better to have some margin to avoid problems coming up later. On the other
hand, I notice that summing up PID+extensions we have 9 bits, which are even more than those made available with the Proto field (8 bits) in IPv4. So the question is, do we really need such large number? Or, said in different terms, what are the requirements
we want to target with such setting? I would have expected that accommodating up to 64 protocol combinations would have been sufficient. Finally, I’m wondering how USLP encapsulation works in the case of IPoC: do we still have the IPE header or is this somehow
mapped in the PID+extensions of USLP? In any case, I imagine these special cases (along with any others) will be properly illustrated in the green book.<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">Thanks in advance for your comments on these thoughts.<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">Best Regards,<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:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<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"">
<a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a> [<a href="mailto:sls-slp-bounces@mailman.ccsds.org">mailto:sls-slp-bounces@mailman.ccsds.org</a>]
<b>On Behalf Of </b>Kazz, Greg J (312B)<br>
<b>Sent:</b> Wednesday, February 03, 2016 18:03<br>
<b>To:</b> <a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a><br>
<b>Cc:</b> Shames, Peter M (312B); SLS-SLP Mailing List<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>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">G.P.,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">We have learned through the lesson of IPoC that a 3 bit PID is too small and restrictive, so that is why in USLP we defined the PID to be bigger I.e., 5 bits
also limited because the first 3 bits are used up by the TFDZ construction rules. I agree that the extended protocol ID field of 8 bits is too big so using the first 4 bits for the PID extension would give us 9 total bits or 512 combinations for PIDs. That
would leave 4 bits of spares thereafter.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">I don’t see any compelling reason to create a separate field just for COP. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">4.1.4.2.1.2 The TFDF Header shall contain the following fields:</span><br>
<span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory);</span><br>
<span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory);</span><br>
<span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as <a href="http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html">http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</a> </span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:blue">…aslo
can contain ipe_header values</span><br>
<span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">c2) Spare (4 bits, optional); </span><br>
<span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) ).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Greg<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:15.0pt;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 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">From:
</span></b><span style="font-size:11.0pt;font-family:"Calibri","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>><br>
<b>Date: </b>Wednesday, February 3, 2016 at 2:38 AM<br>
<b>To: </b>"Kazz, Greg J (313B)" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>><br>
<b>Cc: </b>"Shames, Peter M (312B)" <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>>, SLS-SLP Mailing List <<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:15.0pt;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">Greg,</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black"> assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big.</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">Though I like optimism I wonder whether this is appropriate.</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">Indeed
</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><a href="http://sanaregistry.org/r/protocol_id/protocol_id.html"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">http://sanaregistry.org/r/protocol_id/protocol_id.html</span></a></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">
defines the Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not really 2**7 = 128 different protocol as the construction allows 16 +6 protocols as
some values are reserved (see </span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><a href="http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</span></a></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">
).</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22?</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">If not please consider the following alternative definition (justified also by the current definition of the fields containing either a protocol ID or a COP directive indication):</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">4.1.4.2.1.2 The TFDF Header shall contain the following fields:</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory);</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">b1) </span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:red">COP usage (2 bits, mandatory); ---> see below</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">b2) Protocol Identifier Within USLP Data Zone</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:red"> (3 bits, mandatory);---> same as</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><a href="http://sanaregistry.org/r/protocol_id/protocol_id.html"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">http://sanaregistry.org/r/protocol_id/protocol_id.html</span></a><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">c1) Protocol Identifier Extension Within USLP Data Zone</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:red"> (4 bits, optional); ;---> same
as </span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black"> </span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><a href="http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</span></a><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">c2)
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:red">Spare (4 bits, optional); ;--> good for a link to IPoC?????</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">d) First Header Pointer or Last Valid Octet (16 bits, optional).</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
<br>
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:red">COP usage (2 bits, mandatory);
</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">00 = No directives</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">01 =
</span><span style="color:black">COP-1 directives are contained within the TFDZ.</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="color:black">10 = COP-P directives are contained within the TFDZ</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="color:black">11 = reserved</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
<br>
</span><span style="color:black">Regards</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
<br>
</span><span style="color:black">Gian Paolo</span><span style="font-size:15.0pt;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">"Kazz, Greg J (312B)" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>></span><span style="font-size:15.0pt;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">"Shames, Peter M (312B)" <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>></span><span style="font-size:15.0pt;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: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:15.0pt;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">02/02/2016 19:48</span><span style="font-size:15.0pt;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">[Sls-slp] CCSDS definition of Protocol IDs</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Sent by: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:black"><a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a></span><span style="font-size:15.0pt;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:15.0pt;font-family:"Calibri","sans-serif";color:black">
<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">
</span></div>
<p class="MsoNormal" style="margin-bottom:15.0pt"><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
<br>
<br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">Peter,</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
<br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header.</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits.</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">There is a SANA registry for PIDs under
</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><a href="http://sanaregistry.org/r/protocol_id/protocol_id.html"><span style="font-size:13.5pt">http://sanaregistry.org/r/protocol_id/protocol_id.html</span></a><br>
<br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">IPoC also defines PIDs as well for the IPE header. See
</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><a href="http://sanaregistry.org/r/ipe_header/ipe_header.html"><span style="font-size:13.5pt">http://sanaregistry.org/r/ipe_header/ipe_header.html</span></a><br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet.</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
<br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits.</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below.</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
<br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">Question – What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for
USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ?</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">In the review of USLP, we will address questions like, “Is a 13 bit PID name space sufficient for all agency needs ?”</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
<br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">Your thoughts ?</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
<br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">Thanks!</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
</span><span style="font-size:13.5pt;font-family:"Calibri","sans-serif";color:black">Greg</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
<br>
</span><b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:black">From:
</span></b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:black">"Greenberg, Edward (312B)" <</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><a href="mailto:edward.greenberg@jpl.nasa.gov"><span style="font-size:10.0pt">edward.greenberg@jpl.nasa.gov</span></a></span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:black">><b><br>
Date: </b>Tuesday, February 2, 2016 at 9:53 AM<b><br>
To: </b>"Kazz, Greg J (313B)" <</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><a href="mailto:greg.j.kazz@jpl.nasa.gov"><span style="font-size:10.0pt">greg.j.kazz@jpl.nasa.gov</span></a></span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:black">><b><br>
Subject: </b>PIDs</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
<br>
</span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:black">Encap uses 3 bits +8bits when 3bits=111</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
</span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:black">USLP uses 5 bits +8 bits when 5 bits =11111</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black">
<br>
<br>
</span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:black">Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><br>
<br>
<br>
</span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:black">The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap</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</tt><br>
<tt><a href="mailto:Sls-slp@mailman.ccsds.org">Sls-slp@mailman.ccsds.org</a></tt><br>
</span><span style="font-size:15.0pt;font-family:"Calibri","sans-serif";color:black"><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp"><tt><span style="font-size:10.0pt">http://mailman.ccsds.org/mailman/listinfo/sls-slp</span></tt></a><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>