[Sls-slp] CCSDS definition of Protocol IDs
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Fri Feb 5 13:03:15 UTC 2016
Also to be said that USLP is a little schizophrenic as sometimes it looks
to saving bits and sometimes emphasises that USLP framers are so long that
it is not worth saving bits :o)
Have a nice week end
Gian Paolo
From: <Tomaso.deCola at dlr.de>
To: <kscott at mitre.org>, <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>
Date: 05/02/2016 14:00
Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs
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
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/20160205/357a678f/attachment.html>
More information about the SLS-SLP
mailing list