<!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.&nbsp; You can in fact get a few bytes 
of information into an IP header ('special' source and destination ports, 
ipproto, maybe even IP options).&nbsp; 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>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN 
class=173592615-07092005>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <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.&nbsp; I believe the emergency commands were 
  the right combination of information in the IP header itself.&nbsp; 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 &#8220;looking&#8221; 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>&nbsp;<BR>John Pietras<BR>&nbsp;<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">&nbsp;<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.&nbsp; 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.&nbsp; I guess we were all network weenies who figured 
      that the CD&amp;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.&nbsp; 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.&nbsp; 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.&nbsp; 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>&nbsp; I agree we 
      need to consider issues with small packets and low rates, but how low do 
      we need to go.&nbsp; In all of the missions I have seen (non deep space), 
      the lowest data rates are 125 bps.&nbsp; This is over an order of 
      magnitude difference from your 10 bps.&nbsp; <BR><BR>&nbsp; For the 
      Cislunar environment, we need to figure out what some of our limits 
      are.&nbsp; Do we really want to burden the Cislunar design with issues 
      that only relate to Deep Space?<BR><BR>&nbsp; Also, for hardware decode 
      commands like hardware reset, I'm not sure if packet sizes or IP or CCSDS 
      headers really matter.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; Hence, every bit is quite valuable at this 
      point.&nbsp; With a CCSDS header, we're looking at 6 bytes (plus a couple 
      of bytes if a secondary header is used).&nbsp; If we move to IPv6, this 
      becomes 40.&nbsp; 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.&nbsp; 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>