[Sis-csi] IP Header Compression

Wed Sep 7 10:49:27 EDT 2005

John,

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.

Howie

John Pietras wrote:

> 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.
>
>  
>
> John Pietras
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* sis-csi-bounces at mailman.ccsds.org 
> [mailto:sis-csi-bounces at mailman.ccsds.org] *On Behalf Of *Howard Weiss
> *Sent:* Wednesday, September 07, 2005 9:00 AM
> *To:* Keith Hogie
> *Cc:* sis-csi at mailman.ccsds.org
> *Subject:* Re: [Sis-csi] IP Header Compression
>
>  
>
> Keith,
>
> 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 /like 
> /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.
>
> Howie Weiss
>
> Keith Hogie wrote:
>
> Chris,
>
>   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. 
>
>   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?
>
>   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.
>
> Keith Hogie
>
> Krupiarz, Christopher wrote:
>
> 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).
>
> Chris
>
>
>
>------------------------------------------------------------------------
>
>
> 
>
>_______________________________________________
>
>Sis-CSI mailing list
>
>Sis-CSI at mailman.ccsds.org <mailto:Sis-CSI at mailman.ccsds.org>
>
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi 
>
>  
>
>----------------------------------------------------------------------
>
>  Keith Hogie                   e-mail: Keith.Hogie at gsfc.nasa.gov <mailto:Keith.Hogie at gsfc.nasa.gov>
>
>  Computer Sciences Corp.       office: 301-794-2999  fax: 301-794-9480
>
>  7700 Hubble Dr.
>
>  Lanham-Seabrook, MD 20706  USA        301-286-3203 @ NASA/Goddard
>
>---------------------------------------------------------------------- 
>
> 
>
>
>
>------------------------------------------------------------------------
>
>
> 
>
>_______________________________________________
>
>Sis-CSI mailing list
>
>Sis-CSI at mailman.ccsds.org <mailto:Sis-CSI at mailman.ccsds.org>
>
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>
>  
>
>
>
>-- 
>
> 
>
>Howard Weiss
>
>SPARTA, Inc.
>
>7075 Samuel Morse Drive
>
>Columbia, MD 21046
>
>410.872.1515 x201 || 410.872.8079 (fax)
>
> 
>
>Mike Nichols: "Cheer up, life isn't everything!"
>

-- 

Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201 || 410.872.8079 (fax)

Mike Nichols: "Cheer up, life isn't everything!"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20050907/f2c50d3d/attachment.html