[Sis-dtn] First draft LTP protocol element naming

Tue Nov 16 20:07:46 UTC 2021

My view on your open items:

  *   Wrap checkpoint_serial_number and report_serial_number? Keep it consistent with rest of CCSDS. If wrapping is allowed for transfer frames, then I don't see why LTP would need to be more constrained.
  *   I would rather do indexing at the reception_claim level to avoid having to do implicit association of indexes between claims, offsets and lengths.

Thanks,
-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net
Telecommunications Engineer
Jet Propulsion Laboratory
Office: (818) 354-1650<tel:(818)%20393-5840> | Email: marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>
-----------------------------------------------------------------------------------------------------------------------

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L Scott
Sent: Wednesday, November 10, 2021 6:02 AM
To: sis-dtn at mailman.ccsds.org
Cc: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Subject: [EXTERNAL] [Sis-dtn] First draft LTP protocol element naming

OK, I took a cut at a hierarchical LTP protocol naming (this is really just lifted from the Draft Red Book).  I specifically stayed away from specifying on-the-wire encoding (field lengths) for this.

I have a bit of a question around report segment reception claims, whether it's better to do array indexing at the reception_claim level or the offset/length level.

It would seem, except for the complexity of indexing off the field_length_identifer to determine all the relevant field lengths, that this could be expressed in TSN.1 pretty easily.

Thoughts?

                                --keith

Term

Data Type

Units

Range

Description

segment_header

version_number

unsigned integer

N/A

0-15

ltp.segment_header.version_number

type_control

flag

N/A

[0|1]

ltp.segment_header.type_control

type_exc

flag

N/A

[0|1]

ltp.segment_header.type_exc

type_flag1

flag

N/A

[0|1]

ltp.segment_header.type_flag1

type_flag0

flag

N/A

[0|1]

ltp.segment_header.type_flag0

type_code

flag

N/A

[0|1]

ltp.segment_header.type_code

field_length_identifier

unsigned integer

N/A

0-255

ltp.segment_header.field_length_identifier

session_originator

unsigned integer

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.segment_header.session_originator

session_number

unsigned integer

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.segment_header.session_number

data_segment

client_service_id

unsigned integer

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.data_segment.client_service_id

offset

unsigned integer

bytes

Determined by ltp.segment_header.field_length_identifier

ltp.data_segment.offset

length

unsigned integer

bytes

Determined by ltp.segment_header.field_length_identifier

ltp.data_segment.length

checkpoint_serial_number

unsigned integer

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.data_segment.checkpoint_serial_number

Should we specify that these wrap at the end?  I think the current spec says to abort if you run out of sequence space.

report_serial_number

unsigned integer

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.data_segment.report_serial_number

Should we specify that these wrap at the end?  I think the current spec says to abort if you run out of sequence space.

client_service_data

 Blob of octets

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.data_segment.client_service_data

report_segment

report_serial_number

unsigned integer

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.report_segment.report_serial_number

Should we specify that these wrap at the end?  I think the current spec says to abort if you run out of sequence space.

checkpoint_serial_number

unsigned integer

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.report_segment.checkpoint_serial_number

Should we specify that these wrap at the end?  I think the current spec says to abort if you run out of sequence space.

upper_bound

unsigned integer

bytes

Determined by ltp.segment_header.field_length_identifier

ltp.report_segment.upper_bound

lower_bound

unsigned integer

bytes

Determined by ltp.segment_header.field_length_identifier

ltp.report_segment.lower_bound

reception_claim_count

unsigned integer

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.report_segment.reception_claim_count

    reception_claim_offset

unsigned integer

bytes

Determined by ltp.segment_header.field_length_identifier

ltp.report_segment.reception_claim_offset[x]

What's the right way to deal with arrays?  We could do ltp.report_segment.reception_claim[x].[offset, count] instead.

    reception_claim_length

unsigned integer

bytes

Determined by ltp.segment_header.field_length_identifier

ltp.report_segment.reception_claim_length[x]

What's the right way to deal with arrays?  We could do ltp.report_segment.reception_claim[x].[offset, count] instead.

report_acknowledgement_segment

report_serial_number

unsigned integer

N/A

Determined by ltp.segment_header.field_length_identifier

ltp.report_acknowledgement_segment.report_serial_number

cancel_segment

reason_code

unsigned integer

 N/A

0-255

ltp.cancel_segment.reason_code

cancel_acknowledgement_segment

<no payload>

ltp.cancel_acknowledgement_segment

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20211116/12c123d9/attachment-0001.htm>