<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";
color:black;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
p.StyleParagraph4Kernat14pt, li.StyleParagraph4Kernat14pt, div.StyleParagraph4Kernat14pt
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
text-align:justify;
line-height:14.0pt;
font-size:12.0pt;
font-family:"Times New Roman";
color:black;}
p.styleparagraph4kernat14pt0, li.styleparagraph4kernat14pt0, div.styleparagraph4kernat14pt0
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
text-align:justify;
line-height:14.0pt;
font-size:12.0pt;
font-family:"Times New Roman";
color:black;}
span.emailstyle18
{font-family:Arial;
color:windowtext;}
span.EmailStyle20
{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;}
/* List Definitions */
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
</head>
<body bgcolor=white 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'>Scott,</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'>Ok. I think I understand your
idea. What follows is an attempt to describe it in my own words (boy, it’s
much easier to implement something than to specify it!).</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'>With regard to the heartbeat cycle, a node
can be thought of as having 3 states:</span></font></p>
<ul style='margin-top:0in' type=disc>
<li class=MsoNormal style='color:navy'><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial'>Registered – For each
heartbeat-cycle, the node sends a heartbeat and checks to see if a
heartbeat was received. If the incoming heartbeat is missed for N6
consecutive heartbeat-cycles, then the registrar’s death is imputed
and the state changes to ‘reconnecting’.</span></font></li>
<li class=MsoNormal style='color:navy'><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial'>Reconnecting – For each
heartbeat-cycle, the node initiates a sequence of message exchanges (AMS
devotees know the details here – for example, send a ‘registrar-query’
to the server, receive a ‘cell-spec’ from the server, send a ‘reconnect’
to the restarted registrar, ...) with outcomes that fall into 3 categories.
First, if “fully successful”, the node will receive a ‘reconnected’
response from the restarted registrar (and change state to ‘registered’).
Second, if “fully unsuccessful”, the node will receive a ‘you-are-dead’
response from the registrar, and change state to ‘unregistered’.
Third, all other possible outcomes result in no change – i.e the ‘reconnect’
sequence will be initiated again during the following hearbeat cycle.</span></font></li>
<li class=MsoNormal style='color:navy'><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial'>Unregistered – This state
applies whenever the node is neither ‘registered’ nor ‘reconnecting’.
We can either say that there is no heartbeat-cycle while in this state, or
that there is a heartbeat cycle but no action is taken.</span></font></li>
</ul>
<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'>How does this line up with your thinking?</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Tim</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'> </span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
color=black face="Times New Roman"><span style='font-size:12.0pt;color:windowtext'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 color=black face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight:bold'>From:</span></font></b><font
size=2 color=black face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma;
color:windowtext'> sis-ams-bounces@mailman.ccsds.org
[mailto:sis-ams-bounces@mailman.ccsds.org] <b><span style='font-weight:bold'>On
Behalf Of </span></b>Scott Burleigh<br>
<b><span style='font-weight:bold'>Sent:</span></b> Monday, August 25, 2008 1:57
PM<br>
<b><span style='font-weight:bold'>To:</span></b> sis-ams@mailman.ccsds.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [Sis-ams] 'reconnect'
timer?</span></font></p>
</div>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>Ray, Timothy J. (GSFC-583.0) wrote: </span></font></p>
<p class=MsoNormal><font size=2 color=black face=Arial><span style='font-size:
10.0pt;font-family:Arial'>Dear WG members,</span></font></p>
<p class=MsoNormal><font size=2 color=black face=Arial><span style='font-size:
10.0pt;font-family:Arial'> </span></font></p>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>4.2.7.4.2 specifies that a node shall (in
response to imputing the death of its registrar) query the configuration server
to determine the network location of the restarted registrar, and then send a
‘reconnect’ message to the new registrar (and the registrar shall
respond with either a ‘reconnected’ or
‘you-are-dead’). Good so far. But what if the node does
not receive a response from the registrar? I don’t think our spec
covers this situation.</span></font></p>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>In my opinion, AMS should require the node to start a
timer when it sends the ‘reconnect’ message. AMS should also
specify the action to be taken if the timer expires.</span></font></p>
<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>Tim, good point; the spec is not as clear on this as
it should be. The intent is that:<br>
<br>
a) The immediate response of a node to the imputed death of a
registrar should be simply to note that the registrar is no longer running,
nothing more. (The same is true, really, of the effect on a registrar of
the imputed death of a configuration server.)<br>
<br>
b) At the expiration of any heartbeat period, the node is supposed
to send a heartbeat to the registrar. If it knows that the registrar is
running (at a known network location), great. If not, the node is
supposed to try to determine the new location of the restarted registrar, by
interrogating the configuration server, and then -- if that attempt was
successful -- send a reconnect message to the restarted registrar at its new
location.<br>
<br>
c) If there's no response (reconnected or you_are_dead) to the
reconnect message, no problem. At the expiration of the next heartbeat
period, the node will do step (b) again and this will result in (at most)
transmission of another reconnect.<br>
<br>
That is, the reconnect cycle is "soft state"; in effect, the heartbeat
cycle functions as the timer on reconnect messages.<br>
<br>
I like this approach, as it is pretty simple and at this point I think we want
to avoid introducing any more complexity (such as another timer) into the spec
if we can possibly help it. But what I have written here is really hard
to infer from the current text of 4.2.7, so I need to do some serious reworking
of this text. I'll try to do that this week, unless we don't agree that
this approach is okay. What do you think?<br>
<br>
Scott </span></font></p>
</div>
</body>
</html>