<font size=2 face="sans-serif">Greg,</font>
<br><font size=2 face="sans-serif"> with
respect to your comment about no compelling reason to create a separate
field just for COP, I must say that mixing things is never a good idea.</font>
<br>
<br><font size=2 face="sans-serif">BTW, as COP in effect is a managed parameter
you may need only one bit basically to replicate the behaviour of the Bypass
and Control Flags in COP-1.</font>
<br>
<br><font size=2 face="sans-serif">In fact, as the Bypass Flag is already
present in the USLP Frame Header, it is enough to define the Control Flag
using the same approach from TC:</font>
<br>
<br><font size=2 face="sans-serif">Bypass and Control Flags. = 00 ==>
AD Frame (Acceptance, Data) ==> use COP (either 1 or P depending on
Managed Parameter)</font>
<br><font size=2 face="sans-serif">Bypass and Control Flags. = 10 ==>
BD Frame (Bypass, Data) ==> Expedited Service Frame as per COP in effect</font>
<br><font size=2 face="sans-serif">Bypass and Control Flags. = 11 ==>
BC Frame (Bypass, Control) ==>COP Directive </font>
<br><font size=2 face="sans-serif">Bypass and Control Flags. = 01 ==>
AC Frame (Acceptance, Control) NOT ALLOWED in COP-1 ===? Could mean NO
COP?????</font>
<br>
<br><font size=2 face="sans-serif">BTW, if you need a Control Flag, why
not including it in the frame Header?</font>
<br>
<br><font size=2 face="sans-serif">Just for some brainstorming.</font>
<br>
<br><font size=2 face="sans-serif">Regards</font>
<br>
<br><font size=2 face="sans-serif">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">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int></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 18:03</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>
<hr noshade>
<br>
<br>
<br><font size=4 face="Calibri">G.P.,</font>
<br>
<br><font size=4 face="Calibri">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.</font>
<br><font size=4 face="Calibri">I don’t see any compelling reason to create
a separate field just for COP. </font>
<br>
<br><font size=2 face="sans-serif">4.1.4.2.1.2 The
TFDF Header shall contain the following fields:<br>
a) Transfer Frame Data Zone (TFDZ) Construction
Rules (3 bits, mandatory);<br>
b2) Protocol Identifier Within USLP Data Zone
(5 bits, mandatory);<br>
c1) Protocol Identifier Extension Within USLP
Data Zone (4 bits, optional); ;---> same as </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=2 color=blue face="sans-serif">…aslo can contain ipe_header
values</font><font size=2 face="sans-serif"><br>
c2) Spare (4 bits, optional); <br>
d) Pointer Field (First Header Pointer or Last
Valid Octet (16 bits, optional) ).</font>
<br>
<br><font size=3>Regards,</font>
<br><font size=3>Greg</font>
<br>
<br><font size=2 face="Calibri"><b>From: </b>"</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=2 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=2 face="Calibri">"
<</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=2 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=2 face="Calibri">><b><br>
Date: </b>Wednesday, February 3, 2016 at 2:38 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>
Cc: </b>"Shames, Peter M (312B)" <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=2 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=2 face="Calibri">>,
SLS-SLP Mailing List <</font><a href="mailto:sls-slp@mailman.ccsds.org"><font size=2 color=blue face="Calibri"><u>sls-slp@mailman.ccsds.org</u></font></a><font size=2 face="Calibri">><b><br>
Subject: </b>Re: [Sls-slp] CCSDS definition of Protocol IDs</font>
<br>
<br><font size=2 face="sans-serif">Greg,</font><font size=4 face="Calibri">
</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.<br>
Though I like optimism I wonder whether this is appropriate.</font><font size=4 face="Calibri"><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=4 face="Calibri"> </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=4 face="Calibri"><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):<br>
4.1.4.2.1.2 The TFDF Header shall contain the
following fields:<br>
a) Transfer Frame Data Zone (TFDZ) Construction
Rules (3 bits, mandatory);<br>
b1) </font><font size=2 color=red face="sans-serif">COP
usage (2 bits, mandatory); ---> see below</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><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=2 face="sans-serif"><br>
d) First Header Pointer or Last Valid Octet
(16 bits, optional).</font><font size=4 face="Calibri"><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=4 face="Calibri"> </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.<br>
10 = COP-P directives are contained within the TFDZ<br>
11 = reserved</font><font size=4 face="Calibri"> <br>
</font><font size=3 face="Times New Roman"><br>
Regards</font><font size=4 face="Calibri"> <br>
</font><font size=3 face="Times New Roman"><br>
Gian Paolo</font><font size=4 face="Calibri"> <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)" <</font><a href=mailto:greg.j.kazz@jpl.nasa.gov><font size=1 color=blue face="sans-serif"><u>greg.j.kazz@jpl.nasa.gov</u></font></a><font size=1 face="sans-serif">></font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=1 face="sans-serif">"Shames,
Peter M (312B)" <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=1 color=blue face="sans-serif"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=1 face="sans-serif">></font><font size=1 color=#5f5f5f face="sans-serif"><br>
Cc: </font><font size=1 face="sans-serif">"</font><a href="mailto:sls-slp@mailman.ccsds.org"><font size=1 color=blue face="sans-serif"><u>sls-slp@mailman.ccsds.org</u></font></a><font size=1 face="sans-serif">"
<</font><a href="mailto:sls-slp@mailman.ccsds.org"><font size=1 color=blue face="sans-serif"><u>sls-slp@mailman.ccsds.org</u></font></a><font size=1 face="sans-serif">></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=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=1 color=#5f5f5f face="sans-serif"><br>
Sent by: </font><a href="mailto:sls-slp-bounces@mailman.ccsds.org"><font size=1 color=blue face="sans-serif"><u>sls-slp-bounces@mailman.ccsds.org</u></font></a><font size=4 face="Calibri"><br>
</font>
<hr noshade><font size=4 face="Calibri"><br>
<br>
</font><font size=4 face="Calibri"><br>
Peter,</font><font size=4 face="Calibri"> <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.<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.<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=4 face="Calibri"><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=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=4 face="Calibri"><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.<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=4 face="Calibri"><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=4 face="Calibri">
</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=4 face="Calibri"><br>
</font><font size=4 face="Calibri"><br>
Your thoughts ?</font><font size=4 face="Calibri"> <br>
</font><font size=4 face="Calibri"><br>
Thanks!</font><font size=4 face="Calibri"> </font><font size=4 face="Calibri"><br>
Greg</font><font size=4 face="Calibri"> <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=4 face="Calibri"> <br>
</font><font size=2 face="Calibri"><br>
Encap uses 3 bits +8bits when 3bits=111</font><font size=4 face="Calibri">
</font><font size=2 face="Calibri"><br>
USLP uses 5 bits +8 bits when 5 bits =11111</font><font size=4 face="Calibri">
<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=4 face="Calibri"><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_______________________________________________<br>
Sls-slp mailing list</font><font size=2 color=blue face="Calibri"><u><br>
</u></font><a href="mailto:Sls-slp@mailman.ccsds.org"><font size=2 color=blue face="Calibri"><u>Sls-slp@mailman.ccsds.org</u></font></a><font size=4 color=blue face="Calibri"><u><br>
</u></font><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp"><font size=2 color=blue face="Calibri"><u>http://mailman.ccsds.org/mailman/listinfo/sls-slp</u></font></a><font size=4 face="Calibri"><br>
<br>
</font>
<br><font size=4 face="Calibri">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>
<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>