[Sls-slp] compelling reason to create a separate field just for COP in USLP

Wed Feb 3 18:18:22 UTC 2016

Greg,
        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.

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.

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:

Bypass and Control Flags. = 00 ==> AD Frame (Acceptance, Data) ==> use COP 
(either 1 or P depending on Managed Parameter)
Bypass and Control Flags. = 10 ==> BD Frame (Bypass, Data) ==> Expedited 
Service Frame as per COP in effect
Bypass and Control Flags. = 11 ==> BC Frame (Bypass, Control) ==>COP 
Directive 
Bypass and Control Flags. = 01 ==> AC Frame (Acceptance, Control) NOT 
ALLOWED in COP-1 ===? Could mean NO COP?????

BTW, if you need a Control Flag, why not including it in the frame Header?

Just for some brainstorming.

Regards

Gian Paolo

From:   "Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>
To:     "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc:     "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>, "SLS-SLP 
Mailing List" <sls-slp at mailman.ccsds.org>
Date:   03/02/2016 18:03
Subject:        Re: [Sls-slp] CCSDS definition of Protocol IDs

G.P.,

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.
I don?t see any compelling reason to create a separate field just for COP. 

4.1.4.2.1.2        The TFDF Header shall contain the following fields:
a)        Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, 
mandatory);
b2)        Protocol Identifier Within USLP Data Zone (5 bits, mandatory);
c1)        Protocol Identifier Extension Within USLP Data Zone (4 bits, 
optional); ;---> same as  
http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html 
?aslo can contain ipe_header values
c2)         Spare (4 bits, optional); 
d)        Pointer Field (First Header Pointer or Last Valid Octet (16 
bits, optional) ).

Regards,
Greg

From: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, February 3, 2016 at 2:38 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov>
Cc: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>, SLS-SLP 
Mailing List <sls-slp at mailman.ccsds.org>
Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs

Greg, 
        assuming that USLP will be able to carry 2**13 = 8192 different 
upper layers protocols look to me as thinking big.
Though I like optimism I wonder whether this is appropriate.

Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html 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 
http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html 
). 
I there a good reason for thinking that USLP could carry  8192 different 
while Encapsulation Packet is limited to 22?

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):
4.1.4.2.1.2        The TFDF Header shall contain the following fields:
a)        Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, 
mandatory);
b1)        COP usage (2 bits, mandatory);   ---> see below
b2)        Protocol Identifier Within USLP Data Zone (3 bits, 
mandatory);---> same as
http://sanaregistry.org/r/protocol_id/protocol_id.html
c1)        Protocol Identifier Extension Within USLP Data Zone (4 bits, 
optional); ;---> same as  
http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html
c2)         Spare (4 bits, optional); ;-->  good for a link to IPoC?????
d)        First Header Pointer or Last Valid Octet (16 bits, optional).

COP usage (2 bits, mandatory); 
00 = No directives 
01 = COP-1 directives are contained within the TFDZ.
10 = COP-P directives are contained within the TFDZ
11 = reserved 

Regards 

Gian Paolo 

From:        "Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>
To:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
Cc:        "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Date:        02/02/2016 19:48
Subject:        [Sls-slp] CCSDS definition of Protocol IDs
Sent by:        sls-slp-bounces at mailman.ccsds.org

Peter, 

USLP is planning on defining a Protocol Id (PID) field and an Extended 
Protocol ID field in the Transfer Frame Data Field Header.
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.
There is a SANA registry for PIDs under 
http://sanaregistry.org/r/protocol_id/protocol_id.html

IPoC also defines PIDs as well for the IPE header. See 
http://sanaregistry.org/r/ipe_header/ipe_header.html
In this case, the smallest size IPE header is 8 bits, but it has a 
multiple octet extension capability beyond 1 octet.

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.
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.

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 ? 
In the review of USLP, we will address questions like, ?Is a 13 bit PID 
name space sufficient for all agency needs ??

Your thoughts ? 

Thanks! 
Greg 

From: "Greenberg, Edward (312B)" <edward.greenberg at jpl.nasa.gov>
Date: Tuesday, February 2, 2016 at 9:53 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov>
Subject: PIDs 

Encap uses 3 bits +8bits when 3bits=111 
USLP uses 5 bits +8 bits when 5 bits =11111 

Thus if we assume that the PIP space for Encap in 5 bit form we get 
11xxx+xxxxxxxx

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_______________________________________________
Sls-slp mailing list
Sls-slp at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sls-slp

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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20160203/361ea15e/attachment.html>