[Sls-slp] Re: Improving CCSDS 130.0-G and Proximity-1 Services
Kazz, Greg J (313B)
greg.j.kazz at jpl.nasa.gov
Mon Mar 25 19:15:08 UTC 2013
Dear Marjorie and G.P.,
I recommend we adjust the NOTE under Section 3.2.3 in CCSDS 130.0-G to
say: (identified between ** ** below)
NOTE The Proximity-1 Space Link Protocol is not
included in this table because no formal service definition is given in the
current Recommended Standards (references ,
and ). ** In spite of not having a formal service definition,
Proximity-1 can deliver the
same SDUs delivered by the Packet Service, Encapsulation Service and the
My concern is the classic mixing of "apples and oranges together". Yes,
they are both fruit but they are not the same. So in TM, AOS, TC we have
well defined and understood services. In Prox-1 we do not have defined
services and we call them services. Better not to confuse the user in this
Green book by putting all of these so called services together in this
table. Better, I believe to acknowledge that Prox-1 is very similar to TC
in terms of the SDUs it can transfer but better to see the details in the
Prox-1 DLL book.
To be discussed further in Bordeaux.
On 3/22/13 1:40 AM, "Marjorie de Lande Long" <marjorie at delandelong.com>
>Dear Gian Paolo,
>I fully agree with what you say. The note could be mitigated as you
>suggest. Or perhaps the Prox-1 services could be added to Table 3-2, and
>the note could be changed to say that they have been included, even
>though they do not have the same kind of formal definitions as the
>services of TM, TC and AOS?
>On Tue, 2013-03-19 at 15:59 +0100, Gian.Paolo.Calzolari at esa.int wrote:
>> Dear Marjorie,
>> Dear Greg,
>> CCSDS 130.0-G-2 (and the version under editing) states:
>> Table 3-2 shows a summary of the services provided by the TM/TC/AOS
>> Space Data Link Protocols categorized by the types of data transferred
>> by the services. For complete definition of these services, refer to
>> references , , and .
>> NOTE The Proximity-1 Space Link Protocol is not included in this
>> table because no service definition is given in the current
>> Recommended Standards (references ,  and ).
>> From a certain point of view is true that Proximity-1 does not include
>> a <formal definition of services> but at the same time looking at the
>> following table 3-2 and considering that (see Proximity 1 DLL section
>> 2.1.1) the Proximity-1 Data Link Layer delivers received service data
>> units to the usersI wondered whether could (at least) mitigate that
>> remark stating e.g. that Proximity 1 in spite of not having a formal
>> service definition can deliver the same SDU's delivered by Packet
>> Service, Encapsulation Service and TC VCA Service (i.e. in the order
>> Space Packets, Encapsulation Packets and Variable length private data
>> = Frame Data fields).
>> Of course this should be somehow corroborated by some related/relevant
>> text in Proximity-1 Data Link Layer Book even if this would not a
>> formal service definition.
>> I just note that in CCSDS 211.0-P-4.1 (i.e. the pink book that has
>> undergone Agency Review) we find the following statements:
>> * On the send side, it accepts user data consisting of Service
>> Data Units (SDUs) and associated routing information. On the
>> receive side it delivers SDUs to the users via frame
>> designated Port IDs. (22.214.171.124 Input/Output Sublayer)
>> * 126.96.36.199 Service Data Units /SDUs carry user data from
>> applications in the sending node to applications in the
>> receiving node. A frame with SDU data in its data field is
>> called a user frame (U-frame). The data field of a U-frame can
>> contain an integer number of unsegmented packets, a single
>> packet segment, or a collection of user-provided octets.
>> * 2.1.7 PROTOCOL DESCRIPTION /The Proximity-1 protocol is
>> described in terms of: a) the services provided to the users
>> (transfer of SDUs); b) the ................
>> * Proximity-1 provides users with data transfer services known
>> as Space Data Link Proximity-1 services. When a user, such as
>> the spacecraft vehicle controller, supplies an SDU for
>> transfer, the user (2.2.1 COMMON FEATURES OF SERVICES)
>> * The Proximity-1 protocol provides data transfer services and
>> timing services. There are two data transfer services: the
>> first accepts and delivers packets, while the second accepts
>> and delivers user-defined data. (188.8.131.52 General)
>> * 184.108.40.206 CCSDS Packet Delivery Service
>> * 220.127.116.11 User Defined Data Delivery Service
>> If the statement above are not sufficient to justify modifying the
>> NOTE in 130.0-G, which simple additions/modifications could we
>> Your comments are much more than welcome!
>> Gian Paolo
>> PS I see that 18.104.22.168 opposite to 22.214.171.124 never mentions the term SDU.
>> I think that a text addition in such a sense would be good.
>> 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 --------------
A non-text attachment was scrubbed...
Size: 3222 bytes
More information about the SLS-SLP