[Sls-slp] CCSDS definition of Protocol IDs

Kazz, Greg J (312B) greg.j.kazz at jpl.nasa.gov
Tue Feb 2 18:47:31 UTC 2016


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<mailto: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<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20160202/8805332b/attachment.html>


More information about the SLS-SLP mailing list