perfsonar development work

Author: swany
Date: 2007-12-13 15:49:10 -0500 (Thu, 13 Dec 2007)
New Revision: 306

Modified:
   trunk/nmwg/doc/dLS/dLS.xml
Log:
combine and clarify token mechanism for leader election and control.


Modified: trunk/nmwg/doc/dLS/dLS.xml
===================================================================
--- trunk/nmwg/doc/dLS/dLS.xml  2007-12-13 20:32:11 UTC (rev 305)
+++ trunk/nmwg/doc/dLS/dLS.xml  2007-12-13 20:49:10 UTC (rev 306)
@@ -366,7 +366,8 @@
      
      <t>When scopes are created they form themselves into logical rings 
around which tokens can be
       passed.  These token passing mechanism is used for two purposes, for 
registration control and
-      for leader election.</t>
+      for leader election.  A leader is necessary to circulate group 
updates, to start tokens to
+      initiate registration and to represent a given scope in an upper 
scope.</t>
      
      <t>
             The "token" is an LSControlMessage (see <xref 
target="LSControl-Token" />) 
@@ -411,17 +412,43 @@
       they were available.  In the absence of a priority, the nodes 
essentially 
       are randomly ordered.  
       </t>
-
-     
-     <t>
-      The key is that as long as the identifier is chosen consistently 
within a
-      given scope, the choice of identifier doesn't affect the operation of 
the 
-      protocol.
-     </t>
+       
+      <t>The Vice-leader will be elected via the same mechanism, initiated 
by the current leader,
+       with the current leader excluded.</t>
       
+       <t>
+        The Leader and Vice-Leader LS instances should exchange messages 
+        (see <xref target="LSControl-Leader" />)
+        periodically to ensure that in the event of a failure the lower
+        level will still have a link to the upper level.  A Vice-Leader 
+        will be monitoring the time between successive communications 
+        from the Leader to be sure it has not failed.  In the event that
+        it has, the "Join" procedure will start to the upper level to keep 
+        the hierarchy complete.
+       </t>
+      
+      <t>Token-based election occurs when the group membership changes.  A 
node must initiate
+       leader election if it doesn't receive a token in the target token 
rotation time.  As the
+       identifiers are deterministic, multiple nodes may initiate election 
at the same time with the
+      same result.</t>
+       
+    
+       <figure anchor="leader-election-example">
+        <preamble>Illustration of Leader Election Algorithm</preamble>
+        <artwork>
+         
+         LS1                LS2                LS3
+         |                  |                  | 
+         (...)              (...)              (...)  
+         |                  |                  | 
+         
+        </artwork>
+        <postamble>LS1, LS2 and LS3 are members of the ring.</postamble>
+       </figure>
+       
       </section>
     
-     <section title="">
+     <section title="Token Passing for Registration Control">
      <t>
             The token can be viewed as "permission to talk" and permits the 
             holding LS to send its summary information to all other 
available LS
@@ -544,63 +571,7 @@
 
     </section>
     
-    
-    <section anchor="Leader_Election" title="Leader election">
-     <t>
-           The most important role of any group of HLS instances is electing 
a 
-           leader to serve as a representative in upper level communication. 
 
-           This logical ring should consist of one representative LS from 
each 
-           of similar lower scope configuration.  
-     </t>
-            
 
-     <t>
-          The Leader and Vice-Leader LS instances should exchange messages 
-          (see <xref target="LSControl-Leader" />)
-          periodically to ensure that in the event of a failure the lower
-          level will still have a link to the upper level.  A Vice-Leader 
-          will be monitoring the time between successive communications 
-          from the Leader to be sure it has not failed.  In the event that
-          it has, the "Join" procedure will start to the upper level to keep 
-          the hierarchy complete.
-     </t>
-
-     
-      <figure anchor="leader-election-example">
-       <preamble>Illustration of Leader Election Algorithm</preamble>
-       <artwork>
-                          
-  LS1                LS2                LS3
-   |                  |                  | 
- (...)              (...)              (...)  
-   |                  |                  | 
-
-             </artwork>
-       <postamble>LS1, LS2 and LS3 are members of the ring.  Leader election 
occurs when ... TBD</postamble>
-      </figure>
-    
-      <t>The algorithm for leader election works as follow:</t>
-      
-      <t>
-        <list type="symbols">
-        <t>1. ...tbd</t>
-        <t>2. ...tbd</t>
-        </list>
-      </t>
-      
-      <t>MG: Open issues to be described</t>
-      <t>- when does leader election occur?</t>
-      <t>- who initiates leader election?</t>
-      <t>- is vice leader still necessary? (at least in the first version; 
perhaps it could be implemented/discussed later)</t>
-      <t>- who initiates leader election if leader doesn't work; when (after 
what time) does it occur?</t>
-      <t>- what if more than one node initiates leader election?</t>
-
-     
-     
-     
-    </section>
-    
-
    </section>
  <!-- Summarization Section -->
    <section anchor="summary" title="Summarization">