<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Keith,<br>
<br>
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.&nbsp; 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.&nbsp; I guess we were all network
weenies who figured that the CD&amp;H would be just <i>like </i>an IP
router (or just an IP router if IP were used vs. NP) and all would be
good.&nbsp; 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.&nbsp; 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.&nbsp; Security, however becomes paramount at the space link if such
hardware command decoding is employed.<br>
<br>
Howie Weiss<br>
</font></font><br>
Keith Hogie wrote:
<blockquote cite="mid431DFEA8.2080802@gsfc.nasa.gov" type="cite">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
Chris,<br>
  <br>
&nbsp; I agree we need to consider issues with small packets and low rates,
but how low do we need to go.&nbsp; In all of the missions I have seen (non
deep space), the lowest data rates are 125 bps.&nbsp; This is over an order
of magnitude difference from your 10 bps.&nbsp; <br>
  <br>
&nbsp; For the Cislunar environment, we need to figure out what some of our
limits are.&nbsp; Do we really want to burden the Cislunar design with
issues that only relate to Deep Space?<br>
  <br>
&nbsp; Also, for hardware decode commands like hardware reset, I'm not sure
if packet sizes or IP or CCSDS headers really matter.&nbsp; 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.&nbsp; 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>
Keith Hogie<br>
  <br>
Krupiarz, Christopher wrote:<br>
  <blockquote
 cite="mid7E1D82EADE01E542AA57E940D38FD78D043958C3@aplesliberty.dom1.jhuapl.edu"
 type="cite">
    <meta http-equiv="Content-Type" content="text/html; ">
    <meta name="Generator"
 content="MS Exchange Server version 6.5.7232.68">
    <title>IP Header Compression</title>
<!-- Converted from text/rtf format -->
    <p><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.&nbsp; 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.&nbsp; Hence, every bit is quite valuable
at this point.&nbsp; With a CCSDS header, we're looking at 6 bytes (plus a
couple of bytes if a secondary header is used).&nbsp; If we move to IPv6,
this becomes 40.&nbsp; 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.&nbsp; 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).</font></p>
    <p><font face="Arial" size="2">Chris</font> </p>
    <pre wrap=""><hr size="4" width="90%">
_______________________________________________
Sis-CSI mailing list
<a class="moz-txt-link-abbreviated"
 href="mailto:Sis-CSI@mailman.ccsds.org">Sis-CSI@mailman.ccsds.org</a>
<a class="moz-txt-link-freetext"
 href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</a> 
  </pre>
  </blockquote>
  <pre class="moz-signature" cols="72">----------------------------------------------------------------------
  Keith Hogie                   e-mail: <a
 class="moz-txt-link-abbreviated"
 href="mailto:Keith.Hogie@gsfc.nasa.gov">Keith.Hogie@gsfc.nasa.gov</a>
  Computer Sciences Corp.       office: 301-794-2999  fax: 301-794-9480
  7700 Hubble Dr.
  Lanham-Seabrook, MD 20706  USA        301-286-3203 @ NASA/Goddard
---------------------------------------------------------------------- </pre>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Sis-CSI mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sis-CSI@mailman.ccsds.org">Sis-CSI@mailman.ccsds.org</a>
<a class="moz-txt-link-freetext" href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</a>
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 

Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201 || 410.872.8079 (fax)

Mike Nichols: "Cheer up, life isn't everything!"</pre>
</body>
</html>