[Sis-csi] IP Header Compression

Fri Sep 30 11:33:42 EDT 2005

With the hardware command... I agree with Keith S.

That being said, the hardware will simply match a bit pattern.  That
could be an entire packet, or a part of a packet.  The hardware pattern
detector does not care what comes before or after the command sequence.
So, you could either:

1. Send the HW command as the "payload" of a whole packet in which case
the bit pattern will match (throwing away the rest of the packet).  The
problem here is that you will need to keep sending the whole packet out,
so you have more overhead to get into that small window while the s/c is
tumbling.

2. Or, In an emergeny, just transmit the HW command sequence over and
over (like Keith's example) and bypass all overhead and formatting at
the ground system (we're talking spacecraft emergency, here... not prime
ops)  If the command receiver is designed not to interpret a packet (and
it should not have to be) then all that it needs to see is the command
sequence shifting by...

- Jason

____________________________________________
"It's kind of fun to do the impossible." - Walt Disney

Jason A. Soloff
Chief Systems Engineer
Exploration Communication & Navigation Systems
Constellation Systems

NASA / Goddard Space Flight Center
Code 567 / B19 / S046
Greenbelt, MD 20771

Phone: (301)286-1368
Blackberry: (301)356-3708
Fax: (301)286-1750
E-Mail: Jason.A.Soloff at nasa.gov

________________________________

	From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Scott, Keith L.
	Sent: Friday, September 30, 2005 10:13 AM
	To: Krupiarz, Christopher; Keith Hogie;
sis-csi at mailman.ccsds.org
	Subject: RE: [Sis-csi] IP Header Compression

	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/5a9e471f/attachment-0001.html