[Sls-slp] Fwd: Re: RIDs to Encapsulation Service Red Book

[Greg Kazz]

Marjorie & SLS-SLP members,

Thank you for your expanded comments.
I forgot about the existing definitions in the soon to be converted to 
Silver:Historical Status books which include: TM, TC, and AOS (Annex C). 
Thanks for pointing this out.
I am not aware of any space agencies including NASA that use the 
Encapsulation Packet. Nevertheless, I agree that it makes sense to add the 
comments you suggested to both the Encapsulation Service Red Book pink 
sheets as well as table 7-6 in the Space Link Identifiers book - making the 
user aware of the differences between the old encapsulation packet header 
format and the new format (if approved).

best regards,

Greg

>Date: Tue, 23 Aug 2005 14:59:45 +0200
>From: Marjorie de Lande Long <marjorie at delandelong.com>
>Subject: Re: RIDs to Encapsulation Service Red Book
>To: Greg Kazz <Greg.J.Kazz at jpl.nasa.gov>
>Cc: Gian.Paolo.Calzolari at esa.int, Enrico.Vassallo at esa.int,
>  Gilles.Moury at cnes.fr, Jean-Luc.Gerner at esa.int, pen-shu.yeh at gsfc.nasa.gov
>Reply-to: marjorie at delandelong.com
>User-Agent: KMail/1.6.1
>X-Source-IP: plus44.host4u.net [69.94.105.172] (may be forged)
>X-Source-Sender: marjorie at delandelong.com
>X-JPL-spam-score: 0.00%
>Original-recipient: rfc822;gkazz at mail.jpl.nasa.gov
>
>Greg,
>
>With reference to the RID for 133.1-R-3 (Encapsulation Service), here is an
>explanation of what I meant by "incompatible".
>
>Consider the receiving end of the Packet Service of the TM Space Data Link
>Protocol (132.0-B-1):
>- the First Header Pointer indicates the start of a Packet
>- the first 3 bits are the PVN
>- if the PVN contains '111', this is an Encapsulation Packet
>- look at the 2 bits of the Length of Length field
>- if the Length of Length contains the value '10', then
>         * by the definition in 102.0-B-5, the length field for the packet 
> is in
>octets 1 and 2 of the packet
>         * by the definition in 133.1-R-3, the length field for the packet 
> is in
>octets 2 and 3 of the packet
>- if the Length of Length contains the value '11', then
>         * by the definition in 102.0-B-5, the length field for the packet 
> is in
>octets 1 to 5 of the packet
>         * by the definition in 133.1-R-3, the length field for the packet 
> is in
>octets 4 to 7 of the packet
>
>The receiving end of the Packet Service needs the length field of a packet in
>order to determine how much data belongs to the packet, and in order to find
>the start of the packet header for the next packet.  When the Packet Service
>at the receiving end finds a packet with PVN of '111', the position of the
>length field is uncertain.  Thus the definitions in 102.0-B-5 and 133.1-R-3
>are incompatible.
>
>(Note that the problem is not confined to the Packet Service of the TM Space
>Data Link Protocol. The TC Space Data Link Protocol is affected too, if
>blocking is in use. Also, an implementation of a protocol service in a higher
>layer, which extracts the Encapsulated Data Unit from an Encapsulation
>Packet, is likely to have similar difficulty with finding the length field
>and the start of the Encapsulated Data Unit.)
>
>As a result of the incompatible definitions, an implementation of the Packet
>Service at the receiving end needs to "know" which definition applies for a
>particular virtual channel.  So a solution to the problem exists, as long as
>people are aware that the problem exists.  But it is not difficult to imagine
>a cross-support situation where both parties correctly claim to support
>packets with PVN '111', but they are unaware that there are using the
>different definitions.
>
>The definition in 102.0-B-5 has the status which comes from being part of a
>CCSDS Blue Book since 2000, and it is (was?) also an ISO standard (ISO
>13419).  Even if the Blue Book is withdrawn by being converted to historical
>status, there may be existing systems, implementations, designs, etc. which
>follow the definition. (On the CCSDS website today (23. August) 102.0-B-5 is
>still listed as a Blue Book.  There is also an Encapsulation Packet
>definition in 203.0-B-2 (ISO 12174) which is still listed as a Blue Book - it
>is the same as the definition in 102.0-B-5.)
>
>Clearly, CCSDS can change the definition of the Encapsulation Packet to the
>new format in 133.1-R-3,  but people need to have the change drawn to their
>attention.  This is what I am suggesting in the RID.  I think it would be
>helpful for the new Encapsulation Service book to contain statements that:
>  1) there is a difference in the definition which is, from the point of view
>of implementations, incompatible with the earlier definition, and
>2) the new definition replaces the old definition, making the old definition
>obsolete.
>
>It would also be helpful if:
>- a note could be added to table 7-6 of 135.0-B-1 (Space Link 
>Identifiers), to
>explain that the packets with PVN '111' exclude the old definition in
>102.0-B-5 and 203.0-B-2.
>- when 102.0-B-5 and 203.0-B-2 are moved to Silver status on the CCSDS
>website, a mention of the different definition could be added to their
>website entries.
>
>Best regards,
>Marjorie