<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)" <greg.j.kazz@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Shames, Peter
M (312B)" <peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"sls-slp@mailman.ccsds.org"
<sls-slp@mailman.ccsds.org></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">sls-slp-bounces@mailman.ccsds.org</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>
Sls-slp@mailman.ccsds.org<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>