[Sls-slp] CCSDS definition of Protocol IDs
Scott, Keith L.
kscott at mitre.org
Fri Feb 5 12:34:08 UTC 2016
So what’s the motivation for saving two bits? The delta power / bandwidth needed is minimal, it requires more non-byte-aligned processing, and it sets us up for needing that 65th protocol that we just can’t quite get…
Why not just go with an 8-bit field that is one thing (without the protocols and extensions distinction)? Is it that the extension field is optional (incurring more data-dependent header processing)?
Sorry, but while optimizing bit field sizes down to sub-byte level seems like a useful thing, it also seems to have bitten us a number of times.
—keith
On 2/5/16, 3:22 AM, "sls-slp-bounces at mailman.ccsds.org on behalf of Tomaso.deCola at dlr.de" <sls-slp-bounces at mailman.ccsds.org on behalf of Tomaso.deCola at dlr.de> wrote:
>Personally I find this approach more efficient than what proposed in the book right now. One could wonder whether we could go for 6-bits instead of 8-bits so that we have 32 protocol IDs and 32 extensions, because I tend to think that 224 extended protocol ids (as from your approach) are definitely too much, also considering the possible protocol evolution in the space domain in the next 10-20 years according to what we have seen in the last 10 years. For instance the extended protocol IDs in the encaps are all unassigned, meaning that from the time the protocol was designed there was no use. In this discussion, as mentioned in my previous e-mail, it would be also interesting to see how encapsulation of IP datagrams will be carried out: do we still use of IPoC or do we transport IP datagrams directly in USLP and we use the Proto ID field to transport the current IPE?
>
>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
>http://www.dlr.de/kn/institut/abteilungen/san
>
>> -----Original Message-----
>> From: Greenberg, Edward (312B) [mailto:edward.greenberg at jpl.nasa.gov]
>> Sent: Thursday, February 04, 2016 23:24
>> To: Cola, Tomaso de; 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
>>
>> 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.
>
>
>_______________________________________________
>Sls-slp mailing list
>Sls-slp at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sls-slp
More information about the SLS-SLP
mailing list