<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;">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
G.P.,</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
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.</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
I don’t see any compelling reason to create a separate field just for COP. </div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<br>
</div>
<div><font size="2" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">4.1.4.2.1.2 The TFDF Header shall contain the following fields:</font><br>
<font size="2" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory);</font><br>
<font size="2" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">b2) Protocol Identifier Within USLP Data Zone</font><font size="2" color="red" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;"> (5
bits, mandatory);</font><br>
<font size="2" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">c1) Protocol Identifier Extension Within USLP Data Zone</font><font size="2" color="red" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;"> (4
bits, optional); ;---> same as </font><font size="2" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;"> </font><font size="2" color="blue" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;"><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> </font><font color="#0000ff" face="sans-serif" size="2">…aslo
can contain ipe_header values</font><br>
<font size="2" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">c2) </font><font size="2" color="red" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">Spare
(4 bits, optional); </font><br>
<font size="2" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) ).</font></div>
<div><font size="2" face="sans-serif" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;"><br>
</font></div>
<div>Regards,</div>
<div>Greg</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<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>"<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>
<span style="font-weight:bold">Date: </span>Wednesday, February 3, 2016 at 2:38 AM<br>
<span style="font-weight:bold">To: </span>"Kazz, Greg J (313B)" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>><br>
<span style="font-weight:bold">Cc: </span>"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>
<span style="font-weight:bold">Subject: </span>Re: [Sls-slp] CCSDS definition of Protocol IDs<br>
</div>
<div><br>
</div>
<div>
<div><font size="2" face="sans-serif">Greg,</font> <br>
<font size="2" face="sans-serif"> assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big.</font><br>
<font size="2" face="sans-serif">Though I like optimism I wonder whether this is appropriate.</font><br>
<br>
<font size="2" face="sans-serif">Indeed </font><a href="http://sanaregistry.org/r/protocol_id/protocol_id.html"><font size="2" color="blue" face="sans-serif">http://sanaregistry.org/r/protocol_id/protocol_id.html</font></a><font size="2" face="sans-serif">
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 </font><a href="http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html"><font size="2" color="blue" face="sans-serif">http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</font></a><font size="2" face="sans-serif">
).</font> <br>
<font size="2" face="sans-serif">I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22?</font><br>
<br>
<font size="2" face="sans-serif">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):</font><br>
<font size="2" face="sans-serif">4.1.4.2.1.2 The TFDF Header shall contain the following fields:</font><br>
<font size="2" face="sans-serif">a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory);</font><br>
<font size="2" face="sans-serif">b1) </font><font size="2" color="red" face="sans-serif">COP usage (2 bits, mandatory); ---> see below</font><br>
<font size="2" face="sans-serif">b2) Protocol Identifier Within USLP Data Zone</font><font size="2" color="red" face="sans-serif"> (3 bits, mandatory);---> same as</font><font size="2" face="sans-serif"></font><a href="http://sanaregistry.org/r/protocol_id/protocol_id.html"><font size="2" color="blue" face="sans-serif">http://sanaregistry.org/r/protocol_id/protocol_id.html</font></a><font size="2" face="sans-serif"></font><br>
<font size="2" face="sans-serif">c1) Protocol Identifier Extension Within USLP Data Zone</font><font size="2" color="red" face="sans-serif"> (4 bits, optional); ;---> same as
</font><font size="2" face="sans-serif"> </font><a href="http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html"><font size="2" color="blue" face="sans-serif">http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</font></a><font size="2" face="sans-serif"></font><br>
<font size="2" face="sans-serif">c2) </font><font size="2" color="red" face="sans-serif">Spare (4 bits, optional); ;--> good for a link to IPoC?????</font><br>
<font size="2" face="sans-serif">d) First Header Pointer or Last Valid Octet (16 bits, optional).</font><br>
<br>
<br>
<font size="2" color="red" face="sans-serif">COP usage (2 bits, mandatory); </font>
<br>
<font size="2" face="sans-serif">00 = No directives</font> <br>
<font size="2" face="sans-serif">01 = </font><font size="3" face="Times New Roman">COP-1 directives are contained within the TFDZ.</font><br>
<font size="3" face="Times New Roman">10 = COP-P directives are contained within the TFDZ</font><br>
<font size="3" face="Times New Roman">11 = reserved</font> <br>
<br>
<font size="3" face="Times New Roman">Regards</font> <br>
<br>
<font size="3" face="Times New Roman">Gian Paolo</font> <br>
<br>
<br>
<br>
<font size="1" color="#5f5f5f" face="sans-serif">From: </font><font size="1" face="sans-serif">"Kazz, Greg J (312B)" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>></font><br>
<font size="1" color="#5f5f5f" face="sans-serif">To: </font><font size="1" face="sans-serif">"Shames, Peter M (312B)" <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>></font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Cc: </font><font size="1" face="sans-serif">"<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>></font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Date: </font><font size="1" face="sans-serif">02/02/2016 19:48</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Subject: </font><font size="1" face="sans-serif">[Sls-slp] CCSDS definition of Protocol IDs</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Sent by: </font><font size="1" face="sans-serif"><a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a></font><br>
<hr noshade="">
<br>
<br>
<br>
<font size="4" face="Calibri">Peter,</font> <br>
<br>
<font size="4" face="Calibri">USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header.</font><br>
<font size="4" face="Calibri">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.</font><br>
<font size="4" face="Calibri">There is a SANA registry for PIDs under </font><a href="http://sanaregistry.org/r/protocol_id/protocol_id.html"><font size="4" color="blue" face="Calibri"><u>http://sanaregistry.org/r/protocol_id/protocol_id.html</u></font></a><br>
<br>
<font size="4" face="Calibri">IPoC also defines PIDs as well for the IPE header. See
</font><a href="http://sanaregistry.org/r/ipe_header/ipe_header.html"><font size="4" color="blue" face="Calibri"><u>http://sanaregistry.org/r/ipe_header/ipe_header.html</u></font></a><br>
<font size="4" face="Calibri">In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet.</font><br>
<br>
<font size="4" face="Calibri">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.</font><br>
<font size="4" face="Calibri">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.</font><br>
<br>
<font size="4" face="Calibri">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 ?</font> <br>
<font size="4" face="Calibri">In the review of USLP, we will address questions like, “Is a 13 bit PID name space sufficient for all agency needs ?”</font><br>
<br>
<font size="4" face="Calibri">Your thoughts ?</font> <br>
<br>
<font size="4" face="Calibri">Thanks!</font> <br>
<font size="4" face="Calibri">Greg</font> <br>
<br>
<font size="2" face="Calibri"><b>From: </b>"Greenberg, Edward (312B)" <</font><a href="mailto:edward.greenberg@jpl.nasa.gov"><font size="2" color="blue" face="Calibri"><u>edward.greenberg@jpl.nasa.gov</u></font></a><font size="2" face="Calibri">><b><br>
Date: </b>Tuesday, February 2, 2016 at 9:53 AM<b><br>
To: </b>"Kazz, Greg J (313B)" <</font><a href="mailto:greg.j.kazz@jpl.nasa.gov"><font size="2" color="blue" face="Calibri"><u>greg.j.kazz@jpl.nasa.gov</u></font></a><font size="2" face="Calibri">><b><br>
Subject: </b>PIDs</font> <br>
<br>
<font size="2" face="Calibri">Encap uses 3 bits +8bits when 3bits=111</font> <br>
<font size="2" face="Calibri">USLP uses 5 bits +8 bits when 5 bits =11111</font> <br>
<br>
<font size="2" face="Calibri">Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx</font><br>
<br>
<br>
<font size="2" face="Calibri">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</font><tt><font size="2">_______________________________________________<br>
Sls-slp mailing list<br>
<a href="mailto:Sls-slp@mailman.ccsds.org">Sls-slp@mailman.ccsds.org</a><br>
</font></tt><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp"><tt><font size="2">http://mailman.ccsds.org/mailman/listinfo/sls-slp</font></tt></a><tt><font size="2"><br>
</font></tt><br>
<br>
<pre>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
</pre>
</div>
</div>
</span>
</body>
</html>