[Sis-dtn] LTP Service Data Aggregation

[Felix.Flentge at esa.int]

Dear All,

I have had a detailed look into LTP Service Data Aggregation and this is 
my assessment:

Service Data Aggregation receives Transmission requests from clients and 
aggregates the data from those requests together with the LTP client 
service IDs into single LTP transmission requests. This means that the 
resulting LTP Block has the following format:

Client Request 1 Client Service ID, Client Request 1 Client Service data, 
Client Request 2 Client Service ID, Client Request 2 Client Service data, 
..., Client Request n Client Service ID, Client Request n Client Service 
data, 

The receiving LTP entity SDA is expected to parse this block and generate 
n RedPartReception.indications to the indicated clients containing the 
respective client service data.

This is problematic as the SDA of the receiving LTP entity needs to 
a) know the mapping from Client Service ID to the protocol used for the 
Client Service Data (eg, BP, Space Packets, Encapsulation Packets, ...)
b) be able to unambiguously determine the length of each client service 
data (to find the start of the next SDA client data capsule). That means 
that the SDA implementation needs be able to process all supported 
protocols at least partially (unless fixed client data length are agreed 
for a client service ID). Eg, for BPv7, the implementation needs to parse 
the Bundle CBOR array, for space packets length information needs to be 
read,  other protocols may use specific stop sequences, ...

While a) could be worked out by defining client service IDs for specific 
protocols or by configuration, b) seems more severe as it requires some 
implementation and processing effort (part of the processing will even be 
repeated in the upper protocol layers).

Therefore, we agreed (I think, TBC) for LTPv2 to remove LTP SDA and 
standardise how to put PDU of an upper layer protocol into LTP blocks 
(aggregated or not) per supported protocol, eg:
- BP LTP Convergence Layer: each LTP block shall contain one or several 
complete BP bundles (the BP CL needs to be able to deal with several BP 
bundles per block)
- Space / Encapsulation Packets: each LTP block shall contain one or 
several complete (space  | encapsulation) packets 

With this approach we would loose some flexibility as we will not be able 
to mix PDU of different protocols in an LTP block. I think that's not a 
big limitation as we could have different LTP sessions on-going in 
parallel if we really want to support different protocols at the same 
time.

The question what to do for LTPv1 remains. IMHO, we should avoid SDA being 
implemented / used as it is more complex in terms of implementation and it 
will make a transition towards LTPv2 more difficult.

So, as part of the LTPv1 revision, we could remove Section 7 - Client 
Operation form the standard or at least add a statement that SDA is 
considered deprecated and should not be used.

(At the same time we may also want to add a statement regarding mixed 
red/green sessions as these should probably be avoided as well.)

Regards,
Felix

_________________________________________
ESA - European Space Agency 
Dr. Felix Flentge
Software Engineer, OPS-GSB
Ground Systems Engineering Department
Directorate of Operations
ESA - ESOC
Robert-Bosch-Str.5, D-64293 Darmstadt, Germany
Phone: +49 6151 90 4075 | Email: Felix.Flentge at esa.int



Disclaimer
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or protected content. Any unauthorised 
disclosure, use, retention or dissemination is prohibited. If you have 
received this e-mail in error, please notify the sender immediately. ESA 
applies appropriate organisational measures to protect personal data, in 
case of data privacy queries, please contact the ESA Data Protection 
Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220110/c8c75d43/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220110/c8c75d43/attachment-0001.bin>