[Sis-csi] IP Header Compression

[Scott, Keith L.]

While we're pushing to get as much data as possible over IP, there will
probably still be for a long time some data that wants to sit directly
on top of the space link.  These could be legacy applications that run
directly over space data packets and don't want to move (and know that
they will not need to go multi-hop), or 'special' commands that just
can't deal with the overhead of IP.  The canonical example of the
latter is the 'tumbling spacecraft' problem, where the spacecraft is
spinning and it won't hold still long enough to point its antenna at
Earth to receive the 'stop that' command.  This actually occurred, and
the saving grace was being able to transmit (over and over and over) a
very short 'safe the spacecraft' command that was hardware decoded.
While you're right that one might look for a particular bit stream that
happens to be an IP packet in the hardware decoder, there might be
advantage to being able to do it in fewer bits.  Then again, there's
security, which would seem to be sort of mutually exclusive with 'short
command that causes the spacecraft to do something sort of drastic
(like safe mode).'
 
All that said, the way I can see bit rate playing into this is that
we're really interested in how many bits are needed for emergency
command, and how many bits we can inject into the spacecraft before it
goes off and does something else (spins, reboots again, ...).  We may
need to have two answers, one for people who absolutely require
security (may as well use IP and IPSEC here) and one for people who
don't (allows very short commands but requires a direct data link
connection to the thing doing the resetting)?
 
        --keith


________________________________

	From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Krupiarz,
Christopher
	Sent: Wednesday, September 07, 2005 11:12 AM
	To: Keith Hogie; sis-csi at mailman.ccsds.org
	Subject: RE: [Sis-csi] IP Header Compression
	
	
	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/0b2766a5/attachment.html