<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=173592615-07092005><FONT face=Arial
color=#0000ff size=2>I'd appreciate that. You can in fact get a few bytes
of information into an IP header ('special' source and destination ports,
ipproto, maybe even IP options). It'd be interesting to know what GPM
thought.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=173592615-07092005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN
class=173592615-07092005> <FONT
face=Arial color=#0000ff size=2>--keith</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org] <B>On Behalf Of </B>Dave
Israel<BR><B>Sent:</B> Wednesday, September 07, 2005 11:01 AM<BR><B>To:</B>
Howard Weiss; John Pietras<BR><B>Cc:</B> Keith Hogie;
sis-csi@mailman.ccsds.org<BR><B>Subject:</B> Re: [Sis-csi] IP Header
Compression<BR></FONT><BR></DIV>
<DIV></DIV>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 class=cite cite="" type="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 class=cite cite="" type="cite"><FONT face="Arial, Helvetica"
color=#000080 size=2>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></BLOCKQUOTE></BODY></HTML>