<html>
<body>
The GPM folks had worked out a solution to this that they were
comfortable with a few years ago. I believe the emergency commands
were the right combination of information in the IP header itself.
We at GSFC should be able to get what they planned to do and provide it
to the WG to discuss further.<br><br>
Dave<br><br>
At 10:49 AM 9/7/2005, Howard Weiss wrote:<br>
<blockquote type=cite class=cite cite="">
<font face="Helvetica, Helvetica" size=2>John,<br><br>
Exactly - and also that the short command be consumed by a hunk of
hardware that doesn't rely on the correct operation of the flight
computer, its software, and its protocol stack - all of which might be
slightly brain-damaged and incapable of acting on the emergency
command.<br><br>
Howie<br>
</font><br>
John Pietras wrote: <br>
<blockquote type=cite class=cite cite="">
<font face="Arial, Helvetica" size=2 color="#000080">In the tumbling S/C
scenario, a major concern was that the commands be short enough to allow
a complete one to be seen while the S/C is “looking” in the direction of
the antenna. This is where the difference in overhead between a CCSDS
packet and an IP header might make or break the recovery effort.<br>
<br>
John Pietras<br>
<br>
<div align="center"><br>
</font></div>
<font face="Tahoma" size=2><b>From:</b>
<a href="mailto:sis-csi-bounces@mailman.ccsds.org">
sis-csi-bounces@mailman.ccsds.org</a>
[<a href="mailto:sis-csi-bounces@mailman.ccsds.org" eudora="autourl">
mailto:sis-csi-bounces@mailman.ccsds.org</a>] <b>On Behalf Of </b>Howard
Weiss<br>
<b>Sent:</b> Wednesday, September 07, 2005 9:00 AM<br>
<b>To:</b> Keith Hogie<br>
<b>Cc:</b>
<a href="mailto:sis-csi@mailman.ccsds.org">sis-csi@mailman.ccsds.org</a>
<br>
<b>Subject:</b> Re: [Sis-csi] IP Header Compression<br>
</font><font face="Times New Roman, Times"> <br>
</font><font face="Helvetica, Helvetica" size=2>Keith,<br><br>
When we first started working on SCPS (way, way, way back in what seems
now like the stone ages) we were faced with this same dilemma - how to
allow emergency mode messages in w/o having to deal with the on-board
computer and the protocol stack. Honestly, this was something we
never looked at when we started researching the ways in which upper layer
protocols would be used in a spacecraft. I guess we were all
network weenies who figured that the CD&H would be just <i>like
</i>an IP router (or just an IP router if IP were used vs. NP) and all
would be good. So, the idea for hardware command decoders being
able to handle emergency-mode commanding (e.g., reset, safe-mode) came up
to bite us back in the mid-90s because of the kinds of heroic efforts
that the UKs STRV team used to recover a tumbling micro-sat by constantly
shooting CCSDS telecommands at it to cause it to go into safe-mode.
We realized at that time that if uppler layer protcols were to be used
aboard spacecraft that the command decoders would have to be able to
parse and handle these types of emergency mode commands outside of the
protocol stack. Security, however becomes paramount at the space
link if such hardware command decoding is employed.<br><br>
Howie Weiss<br>
</font><br>
Keith Hogie wrote: <br>
<font face="Times New Roman, Times">Chris,<br><br>
I agree we need to consider issues with small packets and low
rates, but how low do we need to go. In all of the missions I have
seen (non deep space), the lowest data rates are 125 bps. This is
over an order of magnitude difference from your 10 bps. <br><br>
For the Cislunar environment, we need to figure out what some of
our limits are. Do we really want to burden the Cislunar design
with issues that only relate to Deep Space?<br><br>
Also, for hardware decode commands like hardware reset, I'm not
sure if packet sizes or IP or CCSDS headers really matter. Isn't a
hardware decode command just a string of bits (hopefully long enough to
be unique) that get grabbed by hardware without any special packet
knowledge. That would mean that this bit string can be carried
inside any packet and the only length that matters is the length of the
hardware command bitstring.<br><br>
Keith Hogie<br><br>
Krupiarz, Christopher wrote:<br><br>
</font><font face="Arial, Helvetica" size=2>I was curious about thoughts
as to if and where we would address IP header compression in the Green
Book. On some our missions (and I think this is typical at least in
deep space), if we have a reset of the system, the spacecraft may come up
in an emergency mode of receiving 10 bps. Hence, every bit is quite
valuable at this point. With a CCSDS header, we're looking at 6
bytes (plus a couple of bytes if a secondary header is used). If we
move to IPv6, this becomes 40. At 10 bps, that's an additional
uplink time of 25-26 seconds before a command can be received which is
long enough to envision some nightmare scenarios. Clearly IP header
compression would alleviate this concern but I'm not sure where it fits
or if it is needed in this doc (I hope I didn't miss it somewhere).<br>
</font><br>
<font face="Arial, Helvetica" size=2>Chris</font>
</blockquote></blockquote></body>
</html>