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

Thu Oct 22 12:00:43 EDT 2026

For my first point, I will see the following secondary header instead of the one you presented, in order to be clear that both Source and destination extended SCID are mandatory:

[cid:0c051a88-6fa3-4c86-b6f2-3be52b35734e]

If it is accepted the transfer Frame Secondary header data field is not used for this version.

For my third point, we need to ensure no collision nor ambiguity between 16bits SCID and 64 bit SCID. The easiest way is to ensure the 16 first bits of the 64bit SCID are always all-ones. So the extension gives 2^48 new values.

The SANA procedures should take into account that some values are prohibited to be distributed for example as the value 0x0001 is already given the value 0x1000000000000001 is forbidden. All 64bits SCID must look like: 0xHHHHHHHHHHHH1111, H being any hexadecimal character.

Regards,
Clément

________________________________
De : KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>
Envoyé : jeudi 22 octobre 2026 16:56
À : Leclerc Clement; SLP_Mail_List; Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC]; Clemens Heese; Nicola Maturo; Stefano Petri; Rodriguez, Shannon (GSFC-5240)
Objet : RE: [EXTERNAL] RE: 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.

Thanks for your comments, Clement. My answers below in between **….**

Greg

From: Leclerc Clement <Clement.Leclerc at cnes.fr>
Sent: Thursday, October 22, 2026 7:13 AM
To: KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>; SLP_Mail_List <sls-slp at mailman.ccsds.org>; Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] <brent.r.andres at nasa.gov>; Clemens Heese <clemens.heese at esa.int>; Nicola Maturo <nicola.maturo at esa.int>; Stefano Petri <stefano.petri at esa.int>; Rodriguez, Shannon (GSFC-5240) <shannon.rodriguez-1 at nasa.gov>
Subject: [EXTERNAL] RE: Extending USLP SCID - more generic approach - reusing TM Transfer Frame Secondary Header but signaling it with 'all ones' SCID

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

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 ** Agreed, all TF Secondary Headers would need to start with the source SCID and destination SCID. **

     *   To be clear it may be left from the datafield ** not sure what you mean here ? **
     *   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 ** yes on each version. I don’t understand your second point here **

  1.  Why limit ourselves to 4 secondary header versions ?  ** I struggled with how many bits to allocate here. I like your suggestion better than the 2 bits for version and 6 bits for length, so let’s go with one octet for each. **

     *   I suggest to use a full octet field for the version so a full octet for the length also **OK**

  1.  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 **But there are very few V-4 SCID already assigned by SANA, so practically speaking there are only a few e.g., on the order of 10 and less than 100 USLP SCIDs assigned, so CCSDS must recommend future missions not to use the 16-bit SCID but go to the 64-bit (or whatever final bit size is agreed to). There are many more than 48 most significant bytes actually available. **
  2.  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. **Big-endian is the CCSDS standard, so yes I agree with you here. **

We need to ask CSS area guys if it is compatible with SLE. I think so but it's better to check. ** yes, I asked Holger Dreihahn and Erik Barkley to investigate before these meetings, and they reported that the impact is very small and manageable .**

Regards,
Clément ** Merci, Clement – Greg **

________________________________

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/46820514/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 51720 bytes
Desc: pastedImage.png
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20261022/46820514/attachment-0001.png>