[Sis-csi] IP Header Compression

[Krupiarz, Christopher]

Keith,
 
I do not have extensive R/F knowledge and, therefore, can't really give
you an answer regarding what we would see at the Moon.   However, part
of the Cislunar charter is to extend, where possible, the architecture
to Mars where missions currently do have that low of a bit rate.  The
answer may be whether this falls into the "where possible" category or
not and your concern is very valid.  If there is someone with greater
R/F experience than I have on this list who could chime in (in
particular,thoughts on rates on the Moon), that would be very helpful.
 
As for your second point, I'm not sure I follow.  Could you elaborate a
bit on how you would see commanding done in an emergency situation
without using an IP packet?  I probably got lost along the way, but I
made the assumption that in this architecture all packets that a
spacecraft received would be an IP packet.  The hardware decode command
(I think equivalent to our critical commands here) would just be a bit
string, but it would still be in an IP packet.
 
BTW, I'll have to double check (well, I guess this would be triple check
now ;), but I may have swapped emergency commanding with emergency
telemetry rates.  Emergency commanding is ~7.8 bps versus emergency
telemetry at 10 bps.
 
Chris

	-----Original Message-----
	From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Keith Hogie
	Sent: Tuesday, September 06, 2005 4:40 PM
	To: sis-csi at mailman.ccsds.org
	Subject: Re: [Sis-csi] IP Header Compression
	
	
	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
	
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi 
		  

	
----------------------------------------------------------------------
	  Keith Hogie                   e-mail:
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
	
---------------------------------------------------------------------- 

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