<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>No contest that if all MCC requirements
and concepts are known at the outset of the program, we wouldn’t need any
flexibility. That never happens, though. This time the issue was
backup MCC. The next time it may be a new requirement to shift operations
to control centers around the globe with daylight hours to reduce night shift
costs. I know that latter one looks ludicrous to some, but before last
year, the thought that a hurricane might shut down MCC-H looked ludicrous to
some, too. So what they’re grabbing for is not solving a specific
problem, but more general flexibility for unanticipated requirements. Having
said that, fully half the camp is still squarely in the “only build to
known requirements” camp, and if that camp wins, flexibility can go out
the window as a criterion. </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>On what’s trivial… The
decision at connecting at link or network layers is hard-wired in years in
advance. The “operational state” data for Hurricane Rita
turned out to be shipping some database parameters from Houston to MSFC, and we
immediately enabled remote operations infrastructure that allowed telemetry
display on hotel room laptops in the Texas hill country for evacuated MCC
flight controllers. No significant issues for transfer of operational
state. But we could only do that for the downlink, not the uplink,
because of the way the uplink was hard-wired to originate only from MCC-H.
So control of the US segment stayed in Moscow (via the Russian uplink), not with
NASA. So if we’re talking apples to apples here (not sure of that)
then no, the long-lead decision on ground station wiring is not trivial
compared to transferring the operational state. It was the wiring that unfortunately
drove the ops concept, rather than vice-versa. Hence the interest in
making the “wiring” reconfigurable with routing protocols farther
upstream. </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I agree that there are some issues as
important as protocols (</span></font>implementation, operational culture, cost
and risk<font size=2 color=navy face=Arial><span style='font-size:10.0pt;
font-family:Arial;color:navy'>), and they bear investigation. But the way
those issues swing decisions is usually more subjective and less predictable,
depending on who’s in management at the time. Once again: I’m
telling the devil’s advocate story, for those that may not have heard this
background. I don’t consider the answer cut-and-dried. </span></font></p>
<div>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> -=- Mike</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Mike Kearney</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>NASA MSFC EO-01</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>256-544-2029</span></font></p>
</div>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
sis-csi-bounces@mailman.ccsds.org [mailto:sis-csi-bounces@mailman.ccsds.org] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Adrian J. Hooke<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, September 07, 2006
12:05 PM<br>
<b><span style='font-weight:bold'>To:</span></b> Cislunar Space Internetworking<br>
<b><span style='font-weight:bold'>Subject:</span></b> [Sis-csi] Handovers (was:
RE: CCSDS Cislunar Telecon)</span></font></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 color=blue face="Times New Roman"><span
style='font-size:12.0pt;color:blue'>At 07:37 AM 9/7/2006, Kearney, Mike wrote:<br>
<br>
</span></font></p>
<p class=MsoNormal><font size=3 color=blue face="Times New Roman"><span
style='font-size:12.0pt;color:blue'>On the topic of all traffic passing the MOC
(MCC or whatever)... After the ISS experience, there is a stronger desire
in the manned operations community to allow multiple facilities to connect
through the ground station to the spacecraft. There were major
constraints on operations capabilities (especially during Hurricane Rita) that
would have been alleviated if WSGT could have been reconfigured easily to connect
to a US-based backup MCC. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
Mike: if there had been a program requirement in place to be able to rapidly
switch to a backup control center, then wouldn't this handover capability have
been implemented and tested in the ISS operational systems? Presumably, there
wasn't such a requirement and so neither WSGT nor MCC Houston were designed to
support it. The lack of the capability probably had nothing to do with
protocols - as you note, the AOS architecture that has been in place since 1990
was designed to easily support such a transfer - and everything to do with
programmatics and implementation choices.<br>
<br>
<br>
</span></font></p>
<p class=MsoNormal><font size=3 color=blue face="Times New Roman"><span
style='font-size:12.0pt;color:blue'>I know that there are traditional ways to
do that (AOS VCs) without placing a router/IP gateway at the ground
station. But there is a perception in some corridors that going IP based
from the ground station out gives a needed capability to deal with
contingencies, and allows low-cost reconfigurations when ops concepts change.</span></font>
</p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
Isn't whether or not such a handover is done by connecting at the Link or
Network layer an absolutely trivial and insignificant level of detail and
complexity compared with the staggering amount of vehicle operational state
that has to be handed-off between the primary and backup control centers? <br>
<br>
This topic seems like a red herring. Protocol geeks should be very wary about
fostering "perceptions" that this or that protocol can solve the
world's problems. There are much larger issues at play here, and they all have
to do with implementation, operational culture, cost and risk.<br>
<br>
///adrian</span></font></p>
</div>
</body>
<br>
</html>