[Sls-slp] Call for Use Cases of Space Packet Protocol

[Greenberg, Edward (312B)]

The information that probably is necessary source.  The APID can ID the location on the source but if the packet transfer through a network then you need a source.  Time etc is covered in current secondary header.  But there are constructs that might be interesting for local distribution if they are not using AMS.

From: Shames, Peter M (312B)
Sent: Monday, April 23, 2018 3:49 PM
To: Burleigh, Scott C (312B) <Scott.C.Burleigh at jpl.nasa.gov>; Greenberg, Edward (312B) <Edward.Greenberg at jpl.nasa.gov>; sls-slp at mailman.ccsds.org; Jonathan.J.Wilmot at NASA.gov
Cc: Lee Pitts <robert.l.pitts at nasa.gov>
Subject: Re: [Sls-slp] Call for Use Cases of Space Packet Protocol

The DEM was indeed Constellation's locally grown variant on the SPP, with added features similar to PUS.  But please keep in mind that Constellation intended to use TCP/IP as a network and transport protocol, and the DEM was to be used on top of those layers.  Because of this it had no need to provide it's own routing and network functions, it just had to accommodate application layer exchanges, operations, and message topics.

They could equally easily used SPP with secondary header extensions for the same purpose.  I think we really must be careful to not overload this extensible application layer data structure with features that really belong at other layers in the protocol stack.   We have a rich set of protocols, starting from physical layer of the ISO stack, including data link, network/transport, messages & files, and these application layer data structures.

Let's not get them confused any more than they already are.

Peter


From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>> on behalf of Scott Burleigh <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>
Date: Monday, April 23, 2018 at 9:08 AM
To: "Greenberg, Edward" <edward.greenberg at jpl.nasa.gov<mailto:edward.greenberg at jpl.nasa.gov>>, "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>, "Wilmot, Jonathan J. (GSFC-5820)" <Jonathan.J.Wilmot at NASA.gov<mailto:Jonathan.J.Wilmot at NASA.gov>>
Cc: Lee Pitts <robert.l.pitts at nasa.gov<mailto:robert.l.pitts at nasa.gov>>
Subject: Re: [Sls-slp] Call for Use Cases of Space Packet Protocol

Ed, I think of the Space Packet as being the thing that the old Constellation project called a Data Exchange Message (DEM).  I think it performs the same function in the stack, and I suspect that it could easily carry all the same metadata that the DEM was supposed to carry.

Scott

From: Greenberg, Edward (312B)
Sent: Sunday, April 22, 2018 7:37 AM
To: sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>; Jonathan.J.Wilmot at NASA.gov<mailto:Jonathan.J.Wilmot at NASA.gov>
Cc: Lee Pitts <robert.l.pitts at nasa.gov<mailto:robert.l.pitts at nasa.gov>>
Subject: Call for Use Cases of Space Packet Protocol

There seems to be lots of new Use Cases for Space Packets then were considered in the original specification. For example:
·       ESA has PUS
·       Space Station has its own secondary header
·       Orion is looking for a secondary header
Originally the Space Packet was an envelope for data transferred over single link (includes tunneling), now the packet is being looked at for network data transfer, local onboard data transfer (including measurement broadcasting).
It is possible that the role of the packet might change with the use of DTN bundles.
Just to take the broadest view: We currently have two forms of packets, should there be more or should even these be examined to determine if they should be blended  into a new packet design.
Can we get each of you to send in your present and possibly desired Use Cases for our beloved Space Packet so that we could determine its future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180423/4ee00d80/attachment.html>