[Sls-slp] Extending USLP SCID - more generic approach - reusing TM Transfer Frame Secondary Header but signaling it with 'all ones' SCID

[Leclerc Clement]

Hi,

I have some comments but no solution yet on how to specifiy.

I think, having the source and the destination ID on the same frame is a good idea.

Adding a secondary header is also a good idea but I have some difficulties with the definition :

  1.  As the SCID is all ones the extended one is mandatory on each secondary header version
     *   To be clear it may be left from the datafield
     *   Do we want to enforce the use of the source and destination ID on each secondary header version ? the secondary header version 1 as a 0 length datafield
  2.  Why limit ourselves to 4 secondary header versions ?
     *   I suggest to use a full octet field for the version so a full octet for the length also
  3.  I want to draw the attention on the fact that only the 48 most significant bytes could be use for the extended SCID to avoid conflicts between the existing 16 bits SCID it must be enforce by SANA
  4.  There is a need to define how an existing 16-bits SCID is push into the 64-bits extended ones. I propose a left-zero padding. So when it is transform into integer it will be the same value as most implementations are big-endian.

We need to ask CSS area guys if it is compatible with SLE. I think so but it's better to check.

Regards,
Clément

________________________________
De : KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>
Envoyé : jeudi 22 octobre 2026 04:58:32
À : SLP_Mail_List; Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC]; Clemens Heese; Nicola Maturo; Stefano Petri; Rodriguez, Shannon (GSFC-5240); Leclerc Clement
Objet : Extending USLP SCID - more generic approach - reusing TM Transfer Frame Secondary Header but signaling it with 'all ones' SCID

EMAIL EXTERNE : Cet e-mail provient d'un expéditeur externe. Faites preuve de vigilance avant de cliquer sur un lien ou d'ouvrir une pièce jointe. Vérifiez que l'expediteur et le contenu du message sont légitimes.


Dear SLP WG and others,



Yesterday, Oct 21 in the SLS joint meeting, we reached consensus on extending the USLP (Version-4) SCID to 64 bits.

We need to make the existing USLP (732.1-B-3) backward compatible with the future B-4 book that will contain this option.



I propose we reuse the Transfer Frame Secondary Header concept from TM (132.0-B-3). The format of the USLP TF secondary header will then appear in Section 4 of the USLP BB. This will provide us with more than one way to extend the USLP protocol for the future.



The TM Secondary header provides up to 4 versions of the TF Secondary Header. Similarly, using the same format, we can define TF 2nd Hdr Version 1 (‘00’) for the “Extended SCID”. That leaves us with up to 3 additional undefined versions for the future. Like in TM, this 2nd header would be optional, to make it backward compatible with existing USLP implementations.



The Transfer Frame Secondary Header is optional; its presence or absence shall be signaled by the value of the SCID field set to ‘All ones’ in the Transfer Frame Primary Header (see TBD). (So unlike TM, there will be no 2nd header flag in the USLP Primary TF header).

NOTE – This field applies to both Truncated and Non-truncated USLP Primary Headers.



In a new TBD USLP Annex, the format of the Version 1 USLP Transfer Frame Secondary Header is specified:



#1) It will consist of two 64-bit fields:

  1.  Source SCID – 64 bits;
  2.  Destination SCID – 64 bits.

#2) In addition, the Source/Destination Flag in the Transfer Frame Primary Header shall be ignored.



Please see the format of the USLP Transfer Frame Secondary Header in the attached word file.



Your comments are most welcome.



Regards,

Greg








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20261022/282a5f84/attachment.htm>