[Sls-slp] CCSDS definition of Protocol IDs

Fri Feb 5 13:00:38 UTC 2016

Keith,

I think you raised an important point: compactness vs. processing complexity. I think that however we should see this trade-off looking at the entire Transfer frame data field header, which contains the protocol field (s). At the moment it is 32-bit aligned (TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits, which is something always desirable. If we reduce the protocol IDs from a total of 13 down to 8, the header becomes of 27 bits. If we reduce from 13 to 6, it becomes 25 bits. 
I'm certainly fine with the 8 bits, I just wanted to avoid a large field (the initial 13 bits), which will be used only for very small extent of it.

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 
http://www.dlr.de/kn/institut/abteilungen/san 

> -----Original Message-----
> From: Scott, Keith L. [mailto:kscott at mitre.org]
> Sent: Friday, February 05, 2016 13:34
> To: Cola, Tomaso de; edward.greenberg at jpl.nasa.gov;
> greg.j.kazz at jpl.nasa.gov
> Cc: peter.m.shames at jpl.nasa.gov; Gian.Paolo.Calzolari at esa.int; sls-
> slp at mailman.ccsds.org
> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs
> 
> 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
> >> PID+(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.h
> >> tml
> >> .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