<font size=2 face="sans-serif">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)</font>
<br>
<br><font size=2 face="sans-serif">Have a nice week end</font>
<br>
<br>
<br><font size=2 face="sans-serif">Gian Paolo</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif"><Tomaso.deCola@dlr.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif"><kscott@mitre.org>,
<edward.greenberg@jpl.nasa.gov>, <greg.j.kazz@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif"><peter.m.shames@jpl.nasa.gov>,
<Gian.Paolo.Calzolari@esa.int>, <sls-slp@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">05/02/2016 14:00</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">RE: [Sls-slp]
CCSDS definition of Protocol IDs</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Keith,<br>
<br>
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. <br>
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.<br>
<br>
Regards,<br>
<br>
Tomaso<br>
<br>
———————————————————————— <br>
Deutsches Zentrum für Luft- und Raumfahrt (DLR) <br>
German Aerospace Center <br>
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen
| 82234 Wessling | Germany <br>
Tomaso de Cola, Ph.D. <br>
Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola@dlr.de
<br>
</font></tt><a href=http://www.dlr.de/kn/institut/abteilungen/san><tt><font size=2>http://www.dlr.de/kn/institut/abteilungen/san</font></tt></a><tt><font size=2>
<br>
<br>
<br>
> -----Original Message-----<br>
> From: Scott, Keith L. [</font></tt><a href=mailto:kscott@mitre.org><tt><font size=2>mailto:kscott@mitre.org</font></tt></a><tt><font size=2>]<br>
> Sent: Friday, February 05, 2016 13:34<br>
> To: Cola, Tomaso de; edward.greenberg@jpl.nasa.gov;<br>
> greg.j.kazz@jpl.nasa.gov<br>
> Cc: peter.m.shames@jpl.nasa.gov; Gian.Paolo.Calzolari@esa.int; sls-<br>
> slp@mailman.ccsds.org<br>
> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs<br>
> <br>
> So what’s the motivation for saving two bits? The delta power
/ bandwidth<br>
> needed is minimal, it requires more non-byte-aligned processing, and
it sets us<br>
> up for needing that 65th protocol that we just can’t quite get…<br>
> <br>
> Why not just go with an 8-bit field that is one thing (without the
protocols and<br>
> extensions distinction)? Is it that the extension field is optional
(incurring more<br>
> data-dependent header processing)?<br>
> <br>
> Sorry, but while optimizing bit field sizes down to sub-byte level
seems like a<br>
> useful thing, it also seems to have bitten us a number of times.<br>
> <br>
>
—keith<br>
> <br>
> <br>
> <br>
> On 2/5/16, 3:22 AM, "sls-slp-bounces@mailman.ccsds.org on behalf
of<br>
> Tomaso.deCola@dlr.de" <sls-slp-bounces@mailman.ccsds.org on
behalf of<br>
> Tomaso.deCola@dlr.de> wrote:<br>
> <br>
> >Personally I find this approach more efficient than what proposed
in the book<br>
> right now. One could wonder whether we could go for 6-bits instead
of 8-bits so<br>
> that we have 32 protocol IDs and 32 extensions, because I tend to
think that 224<br>
> extended protocol ids (as from your approach) are definitely too much,
also<br>
> considering the possible protocol evolution in the space domain in
the next 10-<br>
> 20 years according to what we have seen in the last 10 years. For
instance the<br>
> extended protocol IDs in the encaps are all unassigned, meaning that
from the<br>
> time the protocol was designed there was no use. In this discussion,
as<br>
> mentioned in my previous e-mail, it would be also interesting to see
how<br>
> encapsulation of IP datagrams will be carried out: do we still use
of IPoC or do<br>
> we transport IP datagrams directly in USLP and we use the Proto ID
field to<br>
> transport the current IPE?<br>
> ><br>
> >Tomaso<br>
> ><br>
> >------------------------<br>
> >Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace
Center<br>
> >Institute of Communications and Navigation | Satellite Networks
|<br>
> >Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D.<br>
> >Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 |<br>
> >tomaso.decola@dlr.de </font></tt><a href=http://www.dlr.de/kn/institut/abteilungen/san><tt><font size=2>http://www.dlr.de/kn/institut/abteilungen/san</font></tt></a><tt><font size=2><br>
> ><br>
> >> -----Original Message-----<br>
> >> From: Greenberg, Edward (312B) [</font></tt><a href=mailto:edward.greenberg@jpl.nasa.gov><tt><font size=2>mailto:edward.greenberg@jpl.nasa.gov</font></tt></a><tt><font size=2>]<br>
> >> Sent: Thursday, February 04, 2016 23:24<br>
> >> To: Cola, Tomaso de; Kazz, Greg J (312B)<br>
> >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari@esa.int;
sls-<br>
> >> slp@mailman.ccsds.org<br>
> >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs<br>
> >><br>
> >> I think so...Do you have a problem with that?<br>
> >><br>
> >> -----Original Message-----<br>
> >> From: Tomaso.deCola@dlr.de [</font></tt><a href=mailto:Tomaso.deCola@dlr.de><tt><font size=2>mailto:Tomaso.deCola@dlr.de</font></tt></a><tt><font size=2>]<br>
> >> Sent: Thursday, February 04, 2016 10:00 AM<br>
> >> To: Greenberg, Edward (312B); Kazz, Greg J (312B)<br>
> >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari@esa.int;
sls-<br>
> >> slp@mailman.ccsds.org<br>
> >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs<br>
> >><br>
> >> Hi Ed,<br>
> >><br>
> >> So if I get it correctly, we'll have a unique field for the
proto<br>
> >> spanning 8 bits,<br>
> >> where:<br>
> >><br>
> >> 0-31: regular protocol id<br>
> >> 32-255: extension protocol id<br>
> >><br>
> >> Then probably the cases '0' and '255' could go reserved for
special uses.<br>
> >><br>
> >> Is my interpretation correct?<br>
> >> ________________________________________<br>
> >> Da: Greenberg, Edward (312B) [edward.greenberg@jpl.nasa.gov]<br>
> >> Inviato: giovedì 4 febbraio 2016 18.18<br>
> >> A: Cola, Tomaso de; Kazz, Greg J (312B)<br>
> >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari@esa.int;
sls-<br>
> >> slp@mailman.ccsds.org<br>
> >> Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs<br>
> >><br>
> >> I think that Tomaso's observation is accurate. The
USLP PID field is<br>
> >> 5 bits allowing 32 possible PIPs. I believe that that
number is<br>
> >> sufficient but we need to allow for our possible miscalculation
so we<br>
> >> specified one of those values to extend the PID field. It
makes no sense to<br>
> make the extension anything other<br>
> >> than an octet. The question is how the contents of
the extended field is<br>
> >> interpreted. My recommendation is that we have 32 IDs
in the 5 bit<br>
> >> field and these should be interpreted as an 8 bit field with
3 leading zero.<br>
> These 32 IDs<br>
> >> would be reserved in the extension field. Thus the
extension field provides<br>
> an<br>
> >> additional 256-32 PID and the value of the all PIDs can be
a unique<br>
> >> digital value. This gives us a maximum of 255 unique
PIDs.<br>
> >><br>
> >> From: sls-slp-bounces@mailman.ccsds.org [</font></tt><a href="mailto:sls-slp-"><tt><font size=2>mailto:sls-slp-</font></tt></a><tt><font size=2><br>
> >> bounces@mailman.ccsds.org] On Behalf Of Tomaso.deCola@dlr.de<br>
> >> Sent: Thursday, February 04, 2016 1:32 AM<br>
> >> To: Kazz, Greg J (312B)<br>
> >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari@esa.int;
sls-<br>
> >> slp@mailman.ccsds.org<br>
> >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs<br>
> >><br>
> >> Greg,<br>
> >><br>
> >> Still coming back to the point of the PID size, I perfectly<br>
> >> understand that it is better to have some margin to avoid
problems<br>
> >> coming up later. On the other hand, I notice that summing
up<br>
> >> PID+extensions we have 9 bits, which are even more than those
made<br>
> >> available with the Proto field (8 bits) in IPv4. So the question
is,<br>
> >> do we really need such large number? Or, said in different
terms,<br>
> >> what are the requirements we want to target with such setting?
I<br>
> >> would have expected that accommodating up to 64 protocol
combinations<br>
> >> would have been sufficient. Finally, I'm wondering how USLP<br>
> >> encapsulation works in the case of<br>
> >> IPoC: do we still have the IPE header or is this somehow
mapped in<br>
> >> the<br>
> >> PID+extensions of USLP? In any case, I imagine these special
cases<br>
> >> PID+(along with<br>
> >> any others) will be properly illustrated in the green book.<br>
> >><br>
> >> Thanks in advance for your comments on these thoughts.<br>
> >><br>
> >> Best Regards,<br>
> >><br>
> >> Tomaso<br>
> >><br>
> >> ------------------------<br>
> >> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace<br>
> >> Center Institute of Communications and Navigation | Satellite<br>
> >> Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso
de Cola,<br>
> Ph.D.<br>
> >> Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844
|<br>
> >> tomaso.decola@dlr.de<</font></tt><a href=mailto:tomaso.decola@dlr.de><tt><font size=2>mailto:tomaso.decola@dlr.de</font></tt></a><tt><font size=2>><br>
> >> </font></tt><a href=http://www.dlr.de/kn/institut/abteilungen/san><tt><font size=2>http://www.dlr.de/kn/institut/abteilungen/san</font></tt></a><tt><font size=2><br>
> >><br>
> >> From: sls-slp-bounces@mailman.ccsds.org<</font></tt><a href="mailto:sls-slp-"><tt><font size=2>mailto:sls-slp-</font></tt></a><tt><font size=2><br>
> >> bounces@mailman.ccsds.org> [</font></tt><a href="mailto:sls-slp-bounces@mailman.ccsds.org"><tt><font size=2>mailto:sls-slp-bounces@mailman.ccsds.org</font></tt></a><tt><font size=2>]<br>
> >> On Behalf Of Kazz, Greg J (312B)<br>
> >> Sent: Wednesday, February 03, 2016 18:03<br>
> >> To: Gian.Paolo.Calzolari@esa.int<</font></tt><a href=mailto:Gian.Paolo.Calzolari@esa.int><tt><font size=2>mailto:Gian.Paolo.Calzolari@esa.int</font></tt></a><tt><font size=2>><br>
> >> Cc: Shames, Peter M (312B); SLS-SLP Mailing List<br>
> >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs<br>
> >><br>
> >> G.P.,<br>
> >><br>
> >> We have learned through the lesson of IPoC that a 3 bit PID
is too<br>
> >> small and restrictive, so that is why in USLP we defined
the PID to<br>
> >> be bigger I.e., 5 bits also limited because the first 3 bits
are used up by the<br>
> TFDZ construction rules.<br>
> >> I agree that the extended protocol ID field of 8 bits is
too big so<br>
> >> using the first 4 bits for the PID extension would give us
9 total<br>
> >> bits or 512 combinations for PIDs. That would leave 4 bits
of spares<br>
> thereafter.<br>
> >> I don't see any compelling reason to create a separate field
just for COP.<br>
> >><br>
> >> 4.1.4.2.1.2 The TFDF Header shall
contain the following fields:<br>
> >> a) Transfer Frame Data Zone (TFDZ)
Construction Rules (3 bits,<br>
> >> mandatory);<br>
> >> b2) Protocol Identifier Within
USLP Data Zone (5 bits, mandatory);<br>
> >> c1) Protocol Identifier Extension
Within USLP Data Zone (4 bits,<br>
> optional); ;-<br>
> >> --> same as<br>
> >> </font></tt><a href=http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.h><tt><font size=2>http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.h</font></tt></a><tt><font size=2><br>
> >> tml<br>
> >> .aslo can contain ipe_header values<br>
> >> c2) Spare (4 bits, optional);<br>
> >> d) Pointer Field (First Header
Pointer or Last Valid Octet (16 bits,<br>
> optional)<br>
> >> ).<br>
> >><br>
> >> Regards,<br>
> >> Greg<br>
> >><br>
> >> From: "Gian.Paolo.Calzolari@esa.int<</font></tt><a href=mailto:Gian.Paolo.Calzolari@esa.int><tt><font size=2>mailto:Gian.Paolo.Calzolari@esa.int</font></tt></a><tt><font size=2>>"<br>
> >> <Gian.Paolo.Calzolari@esa.int<</font></tt><a href=mailto:Gian.Paolo.Calzolari@esa.int><tt><font size=2>mailto:Gian.Paolo.Calzolari@esa.int</font></tt></a><tt><font size=2>>><br>
> >> Date: Wednesday, February 3, 2016 at 2:38 AM<br>
> >> To: "Kazz, Greg J (313B)"<br>
> >> <greg.j.kazz@jpl.nasa.gov<</font></tt><a href=mailto:greg.j.kazz@jpl.nasa.gov><tt><font size=2>mailto:greg.j.kazz@jpl.nasa.gov</font></tt></a><tt><font size=2>>><br>
> >> Cc: "Shames, Peter M (312B)"<br>
> >> <peter.m.shames@jpl.nasa.gov<</font></tt><a href=mailto:peter.m.shames@jpl.nasa.gov><tt><font size=2>mailto:peter.m.shames@jpl.nasa.gov</font></tt></a><tt><font size=2>>>,<br>
> >> SLS- SLP Mailing List <sls-slp@mailman.ccsds.org<</font></tt><a href="mailto:sls-"><tt><font size=2>mailto:sls-</font></tt></a><tt><font size=2><br>
> >> slp@mailman.ccsds.org>><br>
> >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs<br>
> >><br>
> >> Greg,<br>
> >> assuming that USLP will be able
to carry 2**13 = 8192<br>
> >> different upper layers protocols look to me as thinking big.<br>
> >> Though I like optimism I wonder whether this is appropriate.<br>
> >><br>
> >> Indeed </font></tt><a href=http://sanaregistry.org/r/protocol_id/protocol_id.html><tt><font size=2>http://sanaregistry.org/r/protocol_id/protocol_id.html</font></tt></a><tt><font size=2>
defines<br>
> >> the Protocol Identifier for Encapsulation Service over 3
bits with<br>
> >> Extended Protocol Identifier for Encapsulation Service over
4 bits<br>
> >> (i.e. a total of 7 bits but not really 2**7 = 128 different
protocol<br>
> >> as the construction allows 16 +6 protocols as some values
are<br>
> >> reserved (see<br>
> </font></tt><a href=http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html><tt><font size=2>http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</font></tt></a><tt><font size=2>
).<br>
> >> I there a good reason for thinking that USLP could carry
8192<br>
> >> different while Encapsulation Packet is limited to 22?<br>
> >><br>
> >> If not please consider the following alternative definition<br>
> >> (justified also by the current definition of the fields containing<br>
> >> either a protocol ID or a COP directive indication):<br>
> >> 4.1.4.2.1.2 The TFDF Header shall
contain the following fields:<br>
> >> a) Transfer Frame Data Zone (TFDZ)
Construction Rules (3 bits,<br>
> >> mandatory);<br>
> >> b1) COP usage (2 bits, mandatory);
---> see below<br>
> >> b2) Protocol Identifier Within
USLP Data Zone (3 bits, mandatory);---><br>
> same<br>
> >> ashttp://sanaregistry.org/r/protocol_id/protocol_id.html<br>
> >> c1) Protocol Identifier Extension
Within USLP Data Zone (4 bits,<br>
> optional); ;-<br>
> >> --> same as<br>
> >> </font></tt><a href=http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html><tt><font size=2>http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</font></tt></a><tt><font size=2><br>
> >> c2) Spare (4 bits, optional);
;--> good for a link to IPoC?????<br>
> >> d) First Header Pointer or Last
Valid Octet (16 bits, optional).<br>
> >><br>
> >><br>
> >> COP usage (2 bits, mandatory);<br>
> >> 00 = No directives<br>
> >> 01 = COP-1 directives are contained within the TFDZ.<br>
> >> 10 = COP-P directives are contained within the TFDZ<br>
> >> 11 = reserved<br>
> >><br>
> >> Regards<br>
> >><br>
> >> Gian Paolo<br>
> >><br>
> >><br>
> >><br>
> >> From: "Kazz, Greg J (312B)"<br>
> >> <greg.j.kazz@jpl.nasa.gov<</font></tt><a href=mailto:greg.j.kazz@jpl.nasa.gov><tt><font size=2>mailto:greg.j.kazz@jpl.nasa.gov</font></tt></a><tt><font size=2>>><br>
> >> To: "Shames, Peter M (312B)"<br>
> >> <peter.m.shames@jpl.nasa.gov<</font></tt><a href=mailto:peter.m.shames@jpl.nasa.gov><tt><font size=2>mailto:peter.m.shames@jpl.nasa.gov</font></tt></a><tt><font size=2>>><br>
> >> Cc: "sls-slp@mailman.ccsds.org<</font></tt><a href="mailto:sls-slp@mailman.ccsds.org"><tt><font size=2>mailto:sls-slp@mailman.ccsds.org</font></tt></a><tt><font size=2>>"<br>
> <sls-<br>
> >> slp@mailman.ccsds.org<</font></tt><a href="mailto:sls-slp@mailman.ccsds.org"><tt><font size=2>mailto:sls-slp@mailman.ccsds.org</font></tt></a><tt><font size=2>>><br>
> >> Date: 02/02/2016 19:48<br>
> >> Subject: [Sls-slp] CCSDS definition
of Protocol IDs<br>
> >> Sent by: sls-slp-bounces@mailman.ccsds.org<</font></tt><a href="mailto:sls-slp-"><tt><font size=2>mailto:sls-slp-</font></tt></a><tt><font size=2><br>
> >> bounces@mailman.ccsds.org><br>
> >> ________________________________<br>
> >><br>
> >><br>
> >><br>
> >> Peter,<br>
> >><br>
> >> USLP is planning on defining a Protocol Id (PID) field and
an<br>
> >> Extended Protocol ID field in the Transfer Frame Data Field
Header.<br>
> >> Encapsulation Service currently defines Protocol ID to be
a 3 bit<br>
> >> field, followed by an optional Protocol Extension Field of
8 bits for a total of<br>
> 11 bits.<br>
> >> There is a SANA registry for PIDs under<br>
> >> </font></tt><a href=http://sanaregistry.org/r/protocol_id/protocol_id.html><tt><font size=2>http://sanaregistry.org/r/protocol_id/protocol_id.html</font></tt></a><tt><font size=2><br>
> >><br>
> >> IPoC also defines PIDs as well for the IPE header. See<br>
> >> </font></tt><a href=http://sanaregistry.org/r/ipe_header/ipe_header.html><tt><font size=2>http://sanaregistry.org/r/ipe_header/ipe_header.html</font></tt></a><tt><font size=2><br>
> >> In this case, the smallest size IPE header is 8 bits, but
it has a<br>
> >> multiple octet extension capability beyond 1 octet.<br>
> >><br>
> >> USLP currently in draft form, has defined the PID to be 5
bits long,<br>
> >> followed by an optional Protocol Extension Field of 8 bits
for a total of 13<br>
> bits.<br>
> >> Below is an approach from Ed Greenberg, that shows that the<br>
> >> Encapsulation PIDs can indeed be a subset of the USLP PIDs.
See email<br>
> message below.<br>
> >><br>
> >> Question - What does CCSDS, from an organization point of
view,<br>
> >> envision a need to define PIDs across all of CCSDS not just
USLP or<br>
> >> Encap service ? Or is it appropriate for USLP to define the
term,<br>
> >> Protocol ID and have it apply locally I.e., only to the USLP
links ?<br>
> >> In the review of USLP, we will address questions like, "Is
a 13 bit<br>
> >> PID name space sufficient for all agency needs ?"<br>
> >><br>
> >> Your thoughts ?<br>
> >><br>
> >> Thanks!<br>
> >> Greg<br>
> >><br>
> >> From: "Greenberg, Edward (312B)"<br>
> >><br>
> <edward.greenberg@jpl.nasa.gov<</font></tt><a href=mailto:edward.greenberg@jpl.nasa.gov><tt><font size=2>mailto:edward.greenberg@jpl.nasa.gov</font></tt></a><tt><font size=2>>><br>
> >> Date: Tuesday, February 2, 2016 at 9:53 AM<br>
> >> To: "Kazz, Greg J (313B)"<br>
> >> <greg.j.kazz@jpl.nasa.gov<</font></tt><a href=mailto:greg.j.kazz@jpl.nasa.gov><tt><font size=2>mailto:greg.j.kazz@jpl.nasa.gov</font></tt></a><tt><font size=2>>><br>
> >> Subject: PIDs<br>
> >><br>
> >> Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits
+8 bits when<br>
> >> 5 bits =11111<br>
> >><br>
> >> Thus if we assume that the PIP space for Encap in 5 bit form
we get<br>
> >> 11xxx+xxxxxxxx<br>
> >><br>
> >><br>
> >> The only issue is that new PIDs for USLP that have their
first 2 bits<br>
> >> as 00, 01 or<br>
> >> 10 don't map to<br>
> >> Encap_______________________________________________<br>
> >> Sls-slp mailing list<br>
> >> Sls-slp@mailman.ccsds.org<</font></tt><a href="mailto:Sls-slp@mailman.ccsds.org"><tt><font size=2>mailto:Sls-slp@mailman.ccsds.org</font></tt></a><tt><font size=2>><br>
> >> </font></tt><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp"><tt><font size=2>http://mailman.ccsds.org/mailman/listinfo/sls-slp</font></tt></a><tt><font size=2><br>
> >><br>
> >> This message and any attachments are intended for the use
of the<br>
> >> addressee or addressees only.<br>
> >><br>
> >> The unauthorised disclosure, use, dissemination or copying
(either in<br>
> >> whole or in part) of its<br>
> >><br>
> >> content is not permitted.<br>
> >><br>
> >> If you received this message in error, please notify the
sender and<br>
> >> delete it from your system.<br>
> >><br>
> >> Emails can be altered and their integrity cannot be guaranteed
by the<br>
> sender.<br>
> >><br>
> >><br>
> >><br>
> >> Please consider the environment before printing this email.<br>
> ><br>
> ><br>
> >_______________________________________________<br>
> >Sls-slp mailing list<br>
> >Sls-slp@mailman.ccsds.org<br>
> ></font></tt><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp"><tt><font size=2>http://mailman.ccsds.org/mailman/listinfo/sls-slp</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br><PRE>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.
</PRE>