[Sls-slp] Call for Use Cases of Space Packet Protocol
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Fri Mar 1 16:01:03 UTC 2019
Peter,
I think we are both right.
My text referred to the modifications to the document; i.e. the only
change caused by this approach would be one sentence in the SPP book to
inform about the existence of a SANA Registry for secondary headers.
Your text is closer to the formal specification.
About using the present or the future for the verb tense, it is possible
that at book publication time the present tense will be more appropriate
(hopefully).
As you see, my accent was on a change in the book that requires no change
to PUS.
I hope we are aligned now.
Ciao
Gippo
From: "Shames, Peter M (312B)" <Peter.M.Shames at jpl.nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>,
"SLS-SLP Mailing List" <sls-slp at mailman.ccsds.org>
Cc: "Greenberg, Edward (312B)" <Edward.Greenberg at jpl.nasa.gov>,
"Jonathan Wilmot" <Jonathan.J.Wilmot at NASA.gov>, Lee Pitts
<robert.l.pitts at nasa.gov>, "Burleigh, Scott C (312B)"
<Scott.C.Burleigh at jpl.nasa.gov>
Date: 01-03-19 16:27
Subject: Re: [Sls-slp] Call for Use Cases of Space Packet Protocol
Hi Gippo,
At the risk of having us not (quite) agree on this, I think you stated
something different in your item A) than what I intended. You said:
A. The secondary header section is SPP will inform that a number of
secondary-header-types are registered with SANA and the actual contents of
the secondary header are (somehow) "managed" at SPP service user level
(Note 1)
If we are not going to break existing uses or the SPP secondary header,
then I think this statement must read like this:
A) The secondary header flag in SPP will inform that a secondary header is
in use. A number of secondary-header-types will be registered with SANA
and the actual contents of the secondary header are (somehow) "managed" at
SPP service user level (Note 1)
Your wording suggested that the secondary header section itself would
signal that there are a number of secondary header types. In order to do
that we would have to all adopt some new secondary header format that had
such an "I am using secondary header type = 3" field. Right now the SPP
itself, and the current users of SPP do not include such a field. So this
would "break" those uses, including the SPP nominal one, the PUS, and the
JPL uses.
I suggested that we could potentially create a new "standard" SPP
secondary header that had such a field, but was not proposing that we
force this change on existing users.
Can you accept that? As one of the ESA members I would be surprised if
you would accept a change that required a modification of PUS.
Regards, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Friday, March 1, 2019 at 3:21 AM
To: SLS-SLP Mailing List <sls-slp at mailman.ccsds.org>
Cc: "Greenberg, Edward" <Edward.Greenberg at jpl.nasa.gov>, "Wilmot, Jonathan
J. (GSFC-5820)" <Jonathan.J.Wilmot at NASA.gov>, Lee Pitts
<robert.l.pitts at nasa.gov>, Scott Burleigh <Scott.C.Burleigh at jpl.nasa.gov>,
Peter Shames <Peter.M.Shames at jpl.nasa.gov>
Subject: Re: [Sls-slp] Call for Use Cases of Space Packet Protocol
Dear,
after so many e-mail I would like to make the point of the
situation (as far as I understand it) with the caveat that there shall be
something wrong in this story as it looks that Peter and I agree on
something. :o)
The envisaged approach by Peter is that
A) The secondary header section is SPP will inform that a number of
secondary-header-types are registered with SANA and the actual contents of
the secondary header are (somehow) "managed" at SPP service user level
(Note 1)
B) Secondary Header Types will be registered in SANA with a two level
approach :
1. A registry for each SPP secondary header that is registered, with
org, contact person, name of the project, and a pointer to the
documentation
2. An XML schema (or JSON, your choice) that formalizes the
secondary header structure, field names, data types, sizes, and
definitions
Is this the common understanding for everybody?
Best regards and have a nice week end
Gian Paolo
Note1: In fact the service user of the SPP Packet Service provides the SPP
service provider with a "pre cooked" space packet in the PACKET.request
while the service user of the SPP Octet String Service provides the SPP
service provider with a "pre cooked" space packet data field and a
Secondary Header Indicator in the OCTET_STRING.request
From: "Shames, Peter M \(312B\) via SLS-SLP"
<sls-slp at mailman.ccsds.org>
To: Jonathan Wilmot <Jonathan.J.Wilmot at NASA.gov>, "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"
<sls-slp at mailman.ccsds.org>
Cc: Lee Pitts <robert.l.pitts at nasa.gov>
Date: 28-02-19 17:13
Subject: Re: [Sls-slp] Call for Use Cases of Space Packet Protocol
Sent by: "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>
Hi Jonathan,
I think you missed my point. There are existing SPP secondary header
formats that are already in use. The ESA has PUS, the CCSDS MAL has
theirs (not in wide use, but defined), and JPL has "standard" ways of
using the SPP secondary header to transmit time codes. This last is a
sort of "CCSDS standard" in that it is recommended, but not required, in
the SPP spec.
4.1.3.2.1.5 If present, the Packet Secondary Header shall consist of
either:
a) a Time Code Field (variable length) only;
b) an Ancillary Data Field (variable length) only; or
c) a Time Code Field followed by an Ancillary Data Field.
I believe you must accept this, and suggest that trying to change it at
this point will doom you to failure. There will surely be ESA feedback.
I will point out, however, that ESA effectively adopted option b) for the
MAL SPP mapping, and that contains a "Version Number" in the first field
of the Secondary Header. I have not looked to see if that is sufficiently
general that it could be co-opted for this purpose.
Peter
From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of Jonathan
Wilmot via SLS-SLP <sls-slp at mailman.ccsds.org>
Reply-To: "Wilmot, Jonathan J. (GSFC-5820)" <Jonathan.J.Wilmot at NASA.gov>
Date: Thursday, February 28, 2019 at 8:00 AM
To: Peter Shames <Peter.M.Shames at jpl.nasa.gov>, Scott Burleigh
<Scott.C.Burleigh at jpl.nasa.gov>, "Greenberg, Edward"
<Edward.Greenberg at jpl.nasa.gov>, "sls-slp at mailman.ccsds.org"
<sls-slp at mailman.ccsds.org>
Cc: Lee Pitts <robert.l.pitts at nasa.gov>
Subject: Re: [Sls-slp] Call for Use Cases of Space Packet Protocol
Peter,
I understand that "managed" will be the initial approach similar to the
compromise for spacecraft ID's being only unique within an assigned
spectrum. Something we can do now is maybe have a version indication in
the first byte(s) of the secondary header. And although I hate to say it,
maybe even use an SDNV?
Kind regards,
Jonathan
On 2/28/2019 10:51 AM, Shames, Peter M (312B) wrote:
Hi Jonathan,
I get that you would like this, but that would mean changing all of the
existing header structures that are already in wide use. I think what we
should do it to treat this like a "managed parameter" where you have to
know which of the formats you are processing.
That said, for any new / future formats you could certainly include some
sort of standard "secondary header type" flag, but for current ones I
think you must accept the "managed" approach. Otherwise this will never
get off the ground.
Peter
From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of Jonathan
Wilmot via SLS-SLP <sls-slp at mailman.ccsds.org>
Reply-To: "Wilmot, Jonathan J. (GSFC-5820)" <Jonathan.J.Wilmot at NASA.gov>
Date: Thursday, February 28, 2019 at 7:43 AM
To: Peter Shames <Peter.M.Shames at jpl.nasa.gov>, Scott Burleigh
<Scott.C.Burleigh at jpl.nasa.gov>, "Greenberg, Edward"
<Edward.Greenberg at jpl.nasa.gov>, "sls-slp at mailman.ccsds.org"
<sls-slp at mailman.ccsds.org>
Cc: Lee Pitts <robert.l.pitts at nasa.gov>
Subject: Re: [Sls-slp] Call for Use Cases of Space Packet Protocol
Peter,
If we have agreement I will start rapidly moving in that direction. The
schema will be the SOIS EDS and SOIS DoT. For true interoperability I
think we need something in the headers that indicate which one of the
secondary headers is being used so it can be parsed at run-time.
Kind regards,
Jonathan
On 2/28/2019 10:36 AM, Shames, Peter M (312B) wrote:
Hi Jonathan,
If there is a DEM to SPP mapping that uses the standard SPP headers and
adds the DEM as a packet secondary header that would be entirely suitable.
I'd like to encourage something like a two level approach to this:
1. A registry for each SPP secondary header that is registered, with
org, contact person, name of the project, and a pointer to the
documentation
2. An XML schema (or JSON, your choice) that formalizes the
secondary header structure, field names, data types, sizes, and
definitions
That way people can look it up, understand it, know where to find more
info, etc. And, as I suggested, using the DoT would lend a certain
regularity to the typing of the data.
Does his make sense to you guys?
Thanks, Peter
From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of Jonathan
Wilmot via SLS-SLP <sls-slp at mailman.ccsds.org>
Reply-To: "Wilmot, Jonathan J. (GSFC-5820)" <Jonathan.J.Wilmot at NASA.gov>
Date: Thursday, February 28, 2019 at 7:28 AM
To: Peter Shames <Peter.M.Shames at jpl.nasa.gov>, Scott Burleigh
<Scott.C.Burleigh at jpl.nasa.gov>, "Greenberg, Edward"
<Edward.Greenberg at jpl.nasa.gov>, "sls-slp at mailman.ccsds.org"
<sls-slp at mailman.ccsds.org>
Cc: Lee Pitts <robert.l.pitts at nasa.gov>
Subject: Re: [Sls-slp] Call for Use Cases of Space Packet Protocol
Peter and folks
I agree with Peter's approach and would welcome moving forward with
this. Hopefully before the missions finalize their implementation.
As I remember, the DEM did not adopt the SPP format but they did contain
the same type of meta data that ECSS-PUS and the SPP proposal contain. The
mapping between the Orion DEM and the SPP proposal format has been done
and is in use at JSC for the LOP-G prototyping efforts.
Kind regards,
Jonathan
On 2/28/2019 10:14 AM, Shames, Peter M (312B) wrote:
Folks,
What we have proposed in the SPP revision is to create a SANA registry for
local, agency, or even multi-agency packet secondary headers. This could
include PUS, MAL packet mapping, Jonathan's LOP-G headers, and others.
There is a proposal for a simple registry structure in the draft SPP doc
that would allow all of these to be registered. I suggest that you look
at this and propose any needed metadata for the registry. You could try
and engage in some sort of "normalization" effort for the field names,
structures, and contents, or at least try and do some sort of evaluation
of the kinds of data and the different ways they are named and
represented. I'll bet you will find that they are all over the map.
By the way, the SOIS Dictionary of Terms (DoT) may prove to be useful as a
source of standardized terms.
Lastly, as I recall the Constellation DEM did not adhere to the SPP at
all. I may be mis-remembering.
Cheers, Peter
From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of Jonathan
Wilmot via SLS-SLP <sls-slp at mailman.ccsds.org>
Reply-To: "Wilmot, Jonathan J. (GSFC-5820)" <Jonathan.J.Wilmot at NASA.gov>
Date: Thursday, February 28, 2019 at 7:03 AM
To: Scott Burleigh <Scott.C.Burleigh at jpl.nasa.gov>, "Greenberg, Edward"
<Edward.Greenberg at jpl.nasa.gov>, "sls-slp at mailman.ccsds.org"
<sls-slp at mailman.ccsds.org>
Cc: Peter Shames <Peter.M.Shames at jpl.nasa.gov>, Lee Pitts
<robert.l.pitts at nasa.gov>
Subject: Re: [Sls-slp] Call for Use Cases of Space Packet Protocol
Ed, Scott,
The CCSDS Space Packet is being used at NASA, ESA and CAST as end user
application command and telemetry message. It contains information in the
primary and secondary headers to allow end user applications to identify
the data content and format, and also allow mission architecture specific
lower layers to transport user application data within a subnetworks or
across networks.
As part of this discussion I would like to re-submit a proposal to
create a secondary header that could be included as an optional header in
the SPP Blue book or registered in SANA as a standard SPP secondary header
type. (ECSS-PUS headers should also be registered)
Note: The LOP-G program, and other missions at JSC, GSFC, and ARC, are
currently using the format in the attached proposal. This is an
opportunity for CCSDS to improve mission interoperability by supporting
the SPP uses cases that missions require.
Kind Regards,
Jonathan
Jonathan Wilmot
NASA/GSFC
CCSDS SOIS Area Director
On 4/22/2018 12:16 PM, Burleigh, Scott C (312B) wrote:
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; Jonathan.J.Wilmot at NASA.gov
Cc: Lee Pitts <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.
_______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp
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/20190301/1b31893a/attachment-0001.html>
More information about the SLS-SLP
mailing list