[Sls-slp] CCSDS definition of Protocol IDs

Thu Feb 4 22:23:54 UTC 2016

I think so...Do you have a problem with that?

-----Original Message-----
From: Tomaso.deCola at dlr.de [mailto:Tomaso.deCola at dlr.de] 
Sent: Thursday, February 04, 2016 10:00 AM
To: Greenberg, Edward (312B); Kazz, Greg J (312B)
Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls-slp at mailman.ccsds.org
Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs

Hi Ed,

So if I get it correctly, we'll have a unique field for the proto spanning 8 bits, where:

0-31: regular protocol id
32-255: extension protocol id

Then probably the cases '0' and '255' could go reserved for special uses.

Is my interpretation correct?
________________________________________
Da: Greenberg, Edward (312B) [edward.greenberg at jpl.nasa.gov]
Inviato: giovedì 4 febbraio 2016 18.18
A: Cola, Tomaso de; Kazz, Greg J (312B)
Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls-slp at mailman.ccsds.org
Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs

I think that Tomaso's observation is accurate.  The USLP PID field is 5 bits allowing 32 possible PIPs.  I believe that that number is sufficient but we need to allow for our possible miscalculation so we specified one of those values to extend the PID field.  It makes no sense to make the extension anything other than an octet.   The question is how the contents of the extended field is interpreted.  My recommendation is that we have 32 IDs in the 5 bit field and these should be interpreted as an 8 bit field with 3 leading zero.  These 32 IDs would be reserved in the extension field.   Thus the extension field provides an additional 256-32 PID and the value of the all PIDs can be a unique digital value.  This gives us a maximum of 255 unique PIDs.

From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de
Sent: Thursday, February 04, 2016 1:32 AM
To: Kazz, Greg J (312B)
Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls-slp at mailman.ccsds.org
Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs

Greg,

Still coming back to the point of the PID size, I perfectly understand that it is better to have some margin to avoid problems coming up later. On the other hand, I notice that summing up PID+extensions we have 9 bits, which are even more than those made available with the Proto field (8 bits) in IPv4. So the question is, do we really need such large number? Or, said in different terms, what are the requirements we want to target with such setting? I would have expected that accommodating up to 64 protocol combinations would have been sufficient. Finally, I'm wondering how USLP encapsulation works  in the case of IPoC: do we still have the IPE header or is this somehow mapped in the PID+extensions of USLP? In any case, I imagine these special cases (along with any others) will be properly illustrated in the green book.

Thanks in advance  for your comments on these thoughts.

Best Regards,

Tomaso

------------------------
Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>
http://www.dlr.de/kn/institut/abteilungen/san

From: sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org> [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
Sent: Wednesday, February 03, 2016 18:03
To: Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>
Cc: Shames, Peter M (312B); SLS-SLP Mailing List
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<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto: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<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, SLS-SLP Mailing List <sls-slp at mailman.ccsds.org<mailto: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 ashttp://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<mailto:greg.j.kazz at jpl.nasa.gov>>
To:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc:        "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto: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<mailto: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<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_______________________________________________
Sls-slp mailing list
Sls-slp at mailman.ccsds.org<mailto: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.