[Sis-csi] IP Header Compression

[Scott,Keith L.]

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.
 
        --keith


________________________________

	From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Dave Israel
	Sent: Wednesday, September 07, 2005 11:01 AM
	To: Howard Weiss; John Pietras
	Cc: Keith Hogie; sis-csi at mailman.ccsds.org
	Subject: Re: [Sis-csi] IP Header Compression
	
	
	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.
	
	Dave
	
	At 10:49 AM 9/7/2005, Howard Weiss wrote:
	

		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
<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 

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