[Sls-slp] CCSDS definition of Protocol IDs

Wed Feb 3 10:38:16 UTC 2016

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.

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