<font size=2 face="sans-serif">Of course some values in </font><a href=http://sanaregistry.org/r/protocol_id/protocol_id.html><font size=2 color=blue face="sans-serif"><u>http://sanaregistry.org/r/protocol_id/protocol_id.html</u></font></a><font size=2 face="sans-serif">
and </font><a href=http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html><font size=2 color=blue face="sans-serif"><u>http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</u></font></a><font size=2 face="sans-serif">
may not be allowed in USLP (e.g. 000binary = Fill (the encapsulation data
field, if present, contains no protocol data).</font><font size=3> </font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Gian.Paolo.Calzolari@esa.int</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</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">Cc:
</font><font size=1 face="sans-serif">"Shames, Peter
M\(312B\)" <peter.m.shames@jpl.nasa.gov>, "SLS-SLP Mailing
List" <sls-slp@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">03/02/2016 11:39</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [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=2 face="sans-serif">Greg,</font><font size=3> </font><font size=2 face="sans-serif"><br>
assuming that USLP will be able to carry 2**13
= 8192 different upper layers protocols look to me as thinking big.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Though I like optimism I wonder whether this is appropriate.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
Indeed </font><a href=http://sanaregistry.org/r/protocol_id/protocol_id.html><font size=2 color=blue face="sans-serif"><u>http://sanaregistry.org/r/protocol_id/protocol_id.html</u></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"><u>http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</u></font></a><font size=2 face="sans-serif">
).</font><font size=3> </font><font size=2 face="sans-serif"><br>
I there a good reason for thinking that USLP could carry 8192 different
while Encapsulation Packet is limited to 22?</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
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><font size=3> </font><font size=2 face="sans-serif"><br>
4.1.4.2.1.2 The TFDF Header shall contain the
following fields:</font><font size=3> </font><font size=2 face="sans-serif"><br>
a) Transfer Frame Data Zone (TFDZ) Construction
Rules (3 bits, mandatory);</font><font size=3> </font><font size=2 face="sans-serif"><br>
b1) </font><font size=2 color=red face="sans-serif">COP
usage (2 bits, mandatory); ---> see below</font><font size=3>
</font><font size=2 face="sans-serif"><br>
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"><u>http://sanaregistry.org/r/protocol_id/protocol_id.html</u></font></a><font size=2 face="sans-serif">
<br>
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"><u>http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</u></font></a><font size=2 face="sans-serif">
<br>
c2) </font><font size=2 color=red face="sans-serif">Spare
(4 bits, optional); ;--> good for a link to IPoC?????</font><font size=3>
</font><font size=2 face="sans-serif"><br>
d) First Header Pointer or Last Valid Octet
(16 bits, optional).</font><font size=3> <br>
<br>
</font><font size=2 color=red face="sans-serif"><br>
COP usage (2 bits, mandatory); </font><font size=2 face="sans-serif"><br>
00 = No directives</font><font size=3> </font><font size=2 face="sans-serif"><br>
01 = </font><font size=3 face="Times New Roman">COP-1 directives are contained
within the TFDZ.</font><font size=3> </font><font size=3 face="Times New Roman"><br>
10 = COP-P directives are contained within the TFDZ</font><font size=3>
</font><font size=3 face="Times New Roman"><br>
11 = reserved</font><font size=3> <br>
</font><font size=3 face="Times New Roman"><br>
Regards</font><font size=3> <br>
</font><font size=3 face="Times New Roman"><br>
Gian Paolo</font><font size=3> <br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
From: </font><font size=1 face="sans-serif">"Kazz,
Greg J (312B)" <greg.j.kazz@jpl.nasa.gov></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=1 face="sans-serif">"Shames,
Peter M (312B)" <peter.m.shames@jpl.nasa.gov></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Cc: </font><font size=1 face="sans-serif">"sls-slp@mailman.ccsds.org"
<sls-slp@mailman.ccsds.org></font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">02/02/2016
19:48</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">[Sls-slp]
CCSDS definition of Protocol IDs</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Sent by: </font><font size=1 face="sans-serif">sls-slp-bounces@mailman.ccsds.org</font><font size=3>
<br>
</font>
<hr noshade><font size=3><br>
<br>
</font><font size=4 face="Calibri"><br>
Peter,</font><font size=3> <br>
</font><font size=4 face="Calibri"><br>
USLP is planning on defining a Protocol Id (PID) field and an Extended
Protocol ID field in the Transfer Frame Data Field Header.</font><font size=3>
</font><font size=4 face="Calibri"><br>
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><font size=3> </font><font size=4 face="Calibri"><br>
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><font size=3>
<br>
</font><font size=4 face="Calibri"><br>
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><font size=3>
</font><font size=4 face="Calibri"><br>
In this case, the smallest size IPE header is 8 bits, but it has a multiple
octet extension capability beyond 1 octet.</font><font size=3> <br>
</font><font size=4 face="Calibri"><br>
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><font size=3>
</font><font size=4 face="Calibri"><br>
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><font size=3>
<br>
</font><font size=4 face="Calibri"><br>
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><font size=3> </font><font size=4 face="Calibri"><br>
In the review of USLP, we will address questions like, “Is a 13 bit PID
name space sufficient for all agency needs ?”</font><font size=3> <br>
</font><font size=4 face="Calibri"><br>
Your thoughts ?</font><font size=3> <br>
</font><font size=4 face="Calibri"><br>
Thanks!</font><font size=3> </font><font size=4 face="Calibri"><br>
Greg</font><font size=3> <br>
</font><font size=2 face="Calibri"><b><br>
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><font size=3> <br>
</font><font size=2 face="Calibri"><br>
Encap uses 3 bits +8bits when 3bits=111</font><font size=3> </font><font size=2 face="Calibri"><br>
USLP uses 5 bits +8 bits when 5 bits =11111</font><font size=3> <br>
</font><font size=2 face="Calibri"><br>
Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx</font><font size=3>
<br>
<br>
</font><font size=2 face="Calibri"><br>
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</font></tt><font size=3 color=blue><u><br>
</u></font><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp"><tt><font size=2 color=blue><u>http://mailman.ccsds.org/mailman/listinfo/sls-slp</u></font></tt></a><font size=3><br>
<br>
</font>
<br><tt><font size=3>This message and any attachments are intended for
the use of the addressee or addressees only.<br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its<br>
content is not permitted.<br>
If you received this message in error, please notify the sender and delete
it from your system.<br>
Emails can be altered and their integrity cannot be guaranteed by the sender.<br>
<br>
Please consider the environment before printing this email.<br>
</font></tt><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>