[Sls-slp] [BULK] Re: [EXTERNAL] Re: Broadcast/Multicast in 235.1 - decision yet to be taken - resolve at SLS Plenary Today

Sat Oct 24 23:09:59 EDT 2026

For several reasons, I think CCSDS should recommend the use of USLP Version 4 frames and not Proximity-1 Version 3 frames for Lunar. That can be reinforced in both 235.1 and the 235.1 GB.
Maybe also in some policy statement by CCSDS.

Regards,
Greg
From: Stefano Petri <Stefano.Petri at esa.int>
Sent: Friday, October 23, 2026 6:23 AM
To: Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] <brent.r.andres at nasa.gov>; KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>; SLP_Mail_List <sls-slp at mailman.ccsds.org>; Clemens Heese <Clemens.Heese at esa.int>; Nicola Maturo <Nicola.Maturo at esa.int>; Andrews, Kenneth S (JPL-361A)[JPL Employee] <kenneth.s.andrews at jpl.nasa.gov>; Matt Cosby <matt.cosby at goonhilly.org>; Issler Jean-Luc <jean-luc.issler at cnes.fr>; Lee, Dennis K (JPL-4200)[JPL Employee] <dennis.k.lee at jpl.nasa.gov>; Rodriguez, Shannon (GSFC-5240) <shannon.rodriguez-1 at nasa.gov>
Subject: Re: [BULK] Re: [Sls-slp] [EXTERNAL] Re: Broadcast/Multicast in 235.1 - decision yet to be taken - resolve at SLS Plenary Today

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.

Thanks Brent,

Yes I agree that would be the natural way of handling this, we may even wonder if this needs to be in the blue book or if this is green book material or a conops decision since the protocol already allows this way of working.

Greg,
About supporting multicast, broadcast and UIS with proximity-1 v3 transfer frames, maybe we don't want to do that in order to encourage the transition to USLP?
(like when we decided to not allow 235.1 P frames over AOS and to not create a padding directive)

Best regards
Stefano

________________________________
Da: Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] <brent.r.andres at nasa.gov>
Inviato: Venerdì, Ottobre 23, 2026 3:05:25 PM
A: Andres, Brent (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <brent.r.andres at nasa.gov>; KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>; Stefano Petri <Stefano.Petri at esa.int>; SLP_Mail_List <sls-slp at mailman.ccsds.org>; Clemens Heese <Clemens.Heese at esa.int>; Nicola Maturo <Nicola.Maturo at esa.int>; Andrews, Kenneth S (US 361A) <kenneth.s.andrews at jpl.nasa.gov>; Matt Cosby <matt.cosby at goonhilly.org>; Issler Jean-Luc <jean-luc.issler at cnes.fr>; Lee, Dennis K (US 332G) <dennis.k.lee at jpl.nasa.gov>; Rodriguez, Shannon (GSFC-5670) <shannon.rodriguez-1 at nasa.gov>
Oggetto: RE: [BULK] Re: [Sls-slp] [EXTERNAL] Re: Broadcast/Multicast in 235.1 - decision yet to be taken - resolve at SLS Plenary Today

For example, the relay could accept all of the other parameters from the UIS hail but change the working channel in its response.

[cid:image001.png at 01DD63F3.8A3736E0]

Brent Andres
Chief Staff Engineer 4
Columbus Technologies and Services, Inc.
NASA GSFC B23/W124
c: (540) 385-1910
brent.r.andres at nasa.gov<mailto:brent.r.andres at nasa.gov>

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> On Behalf Of Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] via SLS-SLP
Sent: Friday, October 23, 2026 9:00 AM
To: KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>; Stefano Petri <Stefano.Petri at esa.int>; SLP_Mail_List <sls-slp at mailman.ccsds.org>; Clemens Heese <Clemens.Heese at esa.int>; Nicola Maturo <Nicola.Maturo at esa.int>; Andrews, Kenneth S (JPL-361A)[JPL Employee] <kenneth.s.andrews at jpl.nasa.gov>; Matt Cosby <matt.cosby at goonhilly.org>; Issler Jean-Luc <jean-luc.issler at cnes.fr>; Lee, Dennis K (JPL-4200)[JPL Employee] <dennis.k.lee at jpl.nasa.gov>; Rodriguez, Shannon (GSFC-5240) <shannon.rodriguez-1 at nasa.gov>
Subject: [BULK] Re: [Sls-slp] [EXTERNAL] Re: Broadcast/Multicast in 235.1 - decision yet to be taken - resolve at SLS Plenary Today

Hi Stefano,

About the conops of UIS, I believe there should be some extra thinking on how it will play out. Even if the user hails the relay, it may be more appropriate for the relay to maintain the role of master/caller of the session (since it is the relay that will have the knowledge of e.g. usage of the channels).

My suggestion for this was to restrict UIS hailing to negotiated hailing only (no demand hail on the user side).  This would allow the user to state it's preference for the RF parameters in the initial hail to the relay but give the relay the authority to reject it and counter-propose.

Brent

[cid:image001.png at 01DD63F3.8A3736E0]

Brent Andres
Chief Staff Engineer 4
Columbus Technologies and Services, Inc.
NASA GSFC B23/W124
c: (540) 385-1910
brent.r.andres at nasa.gov<mailto:brent.r.andres at nasa.gov>

From: KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>
Sent: Friday, October 23, 2026 2:50 AM
To: Stefano Petri <Stefano.Petri at esa.int>; SLP_Mail_List <sls-slp at mailman.ccsds.org>; Clemens Heese <Clemens.Heese at esa.int>; Nicola Maturo <Nicola.Maturo at esa.int>; Andrews, Kenneth S (JPL-361A)[JPL Employee] <kenneth.s.andrews at jpl.nasa.gov>; Matt Cosby <matt.cosby at goonhilly.org>; Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] <brent.r.andres at nasa.gov>; Issler Jean-Luc <jean-luc.issler at cnes.fr>; Lee, Dennis K (JPL-4200)[JPL Employee] <dennis.k.lee at jpl.nasa.gov>; Rodriguez, Shannon (GSFC-5240) <shannon.rodriguez-1 at nasa.gov>
Subject: RE: [EXTERNAL] Re: Broadcast/Multicast in 235.1 - decision yet to be taken - resolve at SLS Plenary Today

Thanks for your comments, Stefano. My answers are below in between **...**.

From: Stefano Petri <Stefano.Petri at esa.int>
Sent: Thursday, October 22, 2026 11:30 PM
To: KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>; SLP_Mail_List <sls-slp at mailman.ccsds.org>; Clemens Heese <Clemens.Heese at esa.int>; Nicola Maturo <Nicola.Maturo at esa.int>; Andrews, Kenneth S (JPL-361A)[JPL Employee] <kenneth.s.andrews at jpl.nasa.gov>; Matt Cosby <matt.cosby at goonhilly.org>; Andres, Brent (GSFC-524.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] <brent.r.andres at nasa.gov>; Issler Jean-Luc <jean-luc.issler at cnes.fr>; Lee, Dennis K (JPL-4200)[JPL Employee] <dennis.k.lee at jpl.nasa.gov>; Rodriguez, Shannon (GSFC-5240) <shannon.rodriguez-1 at nasa.gov>
Subject: [EXTERNAL] Re: Broadcast/Multicast in 235.1 - decision yet to be taken - resolve at SLS Plenary Today

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.

Hello Greg,

I am sharing my thoughts here since I cannot attend the SLS plenary.

On the proposed workaround to manage the SCID with the report source SCID directive, now that we have a proposal for having both source and destination SCID in the TF header, couldn't we adopt instead this mechanism as a way of pushing for adoption of the proposed new USLP header? ** Certainly yes for USLP protocol but not for the Version 3 Proximity-1 (211.0) protocol. It will greatly simplify operations for USLP to have both Source and Destination in the Version 4 Transfer Frame Header **.

About the conops of UIS, I believe there should be some extra thinking on how it will play out. Even if the user hails the relay, it may be more appropriate for the relay to maintain the role of master/caller of the session (since it is the relay that will have the knowledge of e.g. usage of the channels). ** My concern is that if we soon publish the 4 related Prox-1  books, we need to support lunar operations for multicast/broadcast which is an inherent capability in 235.1 (we get it for free so to speak as long as group SCIDs are defined in SANA), so can we find a compromise in which we say in 235.1 that one can define group SCIDs in SANA to accomplish broadcast and multicast in lieu of specifically defining it now? In other words, state the inherent 235.1 capability only **

We would need this to be reviewed also by colleagues that are not participating in ccsds since this was added after the agency review. ** True, although they were discussed in the CCSDS meetings **

Thank you

Best regards
Stefano

________________________________
From: KAZZ, GREG J. (MSFC-HP27)[MOSSI2] <greg.j.kazz at nasa.gov>
Sent: Friday, 23 October 2026 06:04:29
To: SLP_Mail_List <sls-slp at mailman.ccsds.org>; Clemens Heese <Clemens.Heese at esa.int>; Nicola Maturo <Nicola.Maturo at esa.int>; Andrews, Kenneth S (US 361A) <kenneth.s.andrews at jpl.nasa.gov>; Matt Cosby <matt.cosby at goonhilly.org>; Stefano Petri <Stefano.Petri at esa.int>; Andres, Brent (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <brent.r.andres at nasa.gov>; Issler Jean-Luc <jean-luc.issler at cnes.fr>; Lee, Dennis K (US 332G) <dennis.k.lee at jpl.nasa.gov>; Rodriguez, Shannon (GSFC-5670) <shannon.rodriguez-1 at nasa.gov>
Subject: Broadcast/Multicast in 235.1 - decision yet to be taken - resolve at SLS Plenary Today

Dear All,

We forgot to resolve one pending issue on 235.1, Broadcast/Multicast and UIS Hailing capability.

My recollection was that at the last telecon in early September, ESA said they wanted to think about it a bit more and bring it up for final discussion in Matera.

See Sections 5.1.4 Broadcast/Multicast Session Establishment and 5.1.5 User-Initiated Hailing in the attached draft 235.1 document. (Same as presented in teleconference in early September ).

So let's try to resolve it in the SLS plenary or if we cannot due to time constraints schedule a telecon ASAP. I am optimistic that we can resolve today.

Thanks much,

Greg
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).

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/sls-slp/attachments/20261025/d9a292dd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5794 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20261025/d9a292dd/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 356 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20261025/d9a292dd/attachment-0003.png>