<html>
<body>
I believe we should be pursuing a solution that is routable until maybe
the last hop. For example, if the number of bits including IP
headers is too many, the router at the last hop before transmission to
the destination would remove all headers and only transmit the required
command sequence. This could be indicated by using a port number or
known emergency command IP address or some other method like that.
I know this is not typical router behavior, so it could be either
incorporated into the router or be in some other gateway-type application
at the router.<br><br>
I believe that routability of emergency commands is a requirement,
because the requirements for relays will be based on
emergency/contingency communications requirements. If a method to
automate routing at the space link layer is possible, then that is
another possible method.<br><br>
Dave<br><br>
<br>
At 11:33 AM 9/30/2005, Jason A. Soloff wrote:<br>
<blockquote type=cite class=cite cite="">Content-class:
urn:content-classes:message<br>
Content-Type: multipart/alternative;<br>
<x-tab> </x-tab>
boundary="----_=_NextPart_001_01C5C5D4.3619E21A"<br><br>
<font face="arial" size=2 color="#0000FF">With the hardware command... I
agree with Keith S.<br>
</font> <br>
<font face="arial" size=2 color="#0000FF">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:<br>
</font> <br>
<font face="arial" size=2 color="#0000FF">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.<br>
</font> <br>
<font face="arial" size=2 color="#0000FF">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...<br>
</font> <br>
<font face="arial" size=2 color="#0000FF">- Jason<br>
</font> <br>
<font face="arial" size=2>____________________________________________<br>
"It's kind of fun to do the impossible." - Walt Disney<br>
</font> <br>
<font face="arial" size=2>Jason A. Soloff<br>
Chief Systems Engineer<br>
Exploration Communication & Navigation Systems<br>
Constellation Systems<br>
</font> <br>
<font face="arial" size=2>NASA / Goddard Space Flight Center<br>
Code 567 / B19 / S046<br>
Greenbelt, MD 20771<br>
</font> <br>
<font face="arial" size=2>Phone: (301)286-1368<br>
Blackberry: (301)356-3708<br>
Fax: (301)286-1750<br>
E-Mail:
<a href="mailto:Jason.A.Soloff@nasa.gov">Jason.A.Soloff@nasa.gov</a><br>
</font> <br>
<br><br>
<dl><hr>
<dd><font face="tahoma" size=2>From:</b>
sis-csi-bounces@mailman.ccsds.org
[<a href="mailto:sis-csi-bounces@mailman.ccsds.org" eudora="autourl">
mailto:sis-csi-bounces@mailman.ccsds.org</a>] On Behalf Of </b>Scott,
Keith L.<br>
<dd>Sent:</b> Friday, September 30, 2005 10:13 AM<br>
<dd>To:</b> Krupiarz, Christopher; Keith Hogie;
sis-csi@mailman.ccsds.org<br>
<dd>Subject:</b> RE: [Sis-csi] IP Header Compression<br>
</font><br>
<dd><font face="arial" size=2 color="#0000FF">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).'<br>
</font>
<dd> <br>
<dd><font face="arial" size=2 color="#0000FF">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)?<br>
</font>
<dd> <br>
<dd>
<font face="arial" size=2 color="#0000FF">--keith<br>
</font><br>
<dl><hr>
<dd><font face="tahoma" size=2>From:</b>
sis-csi-bounces@mailman.ccsds.org
[<a href="mailto:sis-csi-bounces@mailman.ccsds.org" eudora="autourl">
mailto:sis-csi-bounces@mailman.ccsds.org</a>] On Behalf Of </b>Krupiarz,
Christopher<br>
<dd>Sent:</b> Wednesday, September 07, 2005 11:12 AM<br>
<dd>To:</b> Keith Hogie; sis-csi@mailman.ccsds.org<br>
<dd>Subject:</b> RE: [Sis-csi] IP Header Compression<br>
</font><br>
<dd><font face="arial" size=2 color="#0000FF">Keith,<br>
</font>
<dd> <br>
<dd><font face="arial" size=2 color="#0000FF">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.<br>
</font>
<dd> <br>
<dd><font face="arial" size=2 color="#0000FF">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.<br>
</font>
<dd> <br>
<dd><font face="arial" size=2 color="#0000FF">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.<br>
</font>
<dd> <br>
<dd><font face="arial" size=2 color="#0000FF">Chris<br>
</font>
<dl>
<dd><font face="tahoma" size=2>-----Original Message-----<br>
<dd>From:</b> sis-csi-bounces@mailman.ccsds.org
[<a href="mailto:sis-csi-bounces@mailman.ccsds.org" eudora="autourl">
mailto:sis-csi-bounces@mailman.ccsds.org</a>] On Behalf Of </b>Keith
Hogie<br>
<dd>Sent:</b> Tuesday, September 06, 2005 4:40 PM<br>
<dd>To:</b> sis-csi@mailman.ccsds.org<br>
<dd>Subject:</b> Re: [Sis-csi] IP Header Compression<br><br>
</font>
<dd>Chris,<br><br>
<dd> 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. <br><br>
<dd> 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?<br><br>
<dd> 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.<br><br>
<dd>Keith Hogie<br><br>
<dd>Krupiarz, Christopher wrote:<br>
<blockquote type=cite class=cite cite=""><br>
<dd><font face="arial" size=2>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).<br>
</font><br>
<dd><font face="arial" size=2>Chris</font> <br><br>
<br>
<pre>
<dd>_______________________________________________
<dd>Sis-CSI mailing list
<dd><a href="mailto:Sis-CSI@mailman.ccsds.org">
Sis-CSI@mailman.ccsds.org</a>
<dd>
<a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi" eudora="autourl">
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</a>
<dd>
</pre><font face="Courier New, Courier"></font></blockquote><br>
<dd><pre>
----------------------------------------------------------------------
<dd> Keith
Hogie
e-mail:
<a href="mailto:Keith.Hogie@gsfc.nasa.gov">Keith.Hogie@gsfc.nasa.gov</a>
<dd> Computer Sciences Corp.
office: 301-794-2999 fax: 301-794-9480
<dd> 7700 Hubble Dr.
<dd> Lanham-Seabrook, MD 20706
USA 301-286-3203 @
NASA/Goddard
<dd>
----------------------------------------------------------------------
</pre><font face="Courier New, Courier"></font><br>
</dl>
</dl>
</dl>_______________________________________________<br>
Sis-CSI mailing list<br>
Sis-CSI@mailman.ccsds.org<br>
<a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi" eudora="autourl">
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</a></blockquote>
<x-sigsep><p></x-sigsep>
______________________________________________________________<br>
Dave Israel<br>
Leader, Advanced Technology Development Group<br>
Microwave & Communication Systems Branch<br>
NASA Goddard Space Flight Center Code 567.3<br>
Greenbelt, MD 20771<br>
Phone: (301) 286-5294 Fax:
(301) 286-1769<br>
E-mail: dave.israel@nasa.gov<br><br>
"Without deviation from the norm, progress is not
possible." -Frank Zappa</body>
</html>