perfsonar development work

Author: mac
Date: 2007-10-11 07:37:13 -0400 (Thu, 11 Oct 2007)
New Revision: 290

Modified:
   trunk/nmwg/doc/dLS/dLS.html
   trunk/nmwg/doc/dLS/dLS.pdf
Log:
Szymon did some changes recently, so I generate PDF and HTML before reading 
(next iteration) :)



Modified: trunk/nmwg/doc/dLS/dLS.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS.html 2007-10-11 07:36:20 UTC (rev 289)
+++ trunk/nmwg/doc/dLS/dLS.html 2007-10-11 11:37:13 UTC (rev 290)
@@ -299,7 +299,7 @@
 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
 <link rel="Chapter" title="2 System Specific Operation" 
href="#rfc.section.2">
 <link rel="Chapter" title="3 Bootstrapping" href="#rfc.section.3">
-<link rel="Chapter" title="4 structures and Messages" href="#rfc.section.4">
+<link rel="Chapter" title="4 Structures and Messages" href="#rfc.section.4">
 <link rel="Chapter" title="5 Result codes" href="#rfc.section.5">
 <link rel="Chapter" title="6 Appendices" href="#rfc.section.6">
 <link rel="Chapter" href="#rfc.section.7" title="7 References">
@@ -404,7 +404,7 @@
 <h2 id="rfc.section.2.1">
 <a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="overview" 
href="#overview">Overview</a>
 </h2>
-<p id="rfc.section.2.1.p.1">The first step of information flow is when a pS 
service registers with an LS. The service may know the name of an LS via 
static configuration (the most common case for legacy deployments), or other 
forms of bootstrapping such as multicast may occur. A service registers a 
"service metadata" record about itself and full metadata (i.e. containing all 
information such as subject, eventType(s), and any parameters, see <a 
href="#service-metadata" title="service metadata 
example">Section&nbsp;4.1</a>) about stored data it has knowledge of. Such a 
record is called Lookup Information (see <a href="#lookup-info" title="Lookup 
Information">Section&nbsp;4.2</a>).</p>
+<p id="rfc.section.2.1.p.1">The first step of information flow is when a pS 
service registers with an LS. The service may know the name of an LS via 
static configuration (the most common case for legacy deployments), or other 
forms of bootstrapping such as multicast may occur. A service registers a 
"service metadata" record about itself and full metadata (i.e. containing all 
information such as subject, eventType(s), and any parameters, see <a 
href="#service-metadata" title="Service metadata 
example">Section&nbsp;4.1</a>) about stored data it has knowledge of. Such a 
record is called Lookup Information (see <a href="#lookup-info" title="Lookup 
Information">Section&nbsp;4.2</a>).</p>
 <p id="rfc.section.2.1.p.2">The idea is to move the metadata from a local 
XML data store to a specialized LS with additional searching capabilities. 
While a service instance may support limited searching, this is not necessary 
as they should be focused on storing or gathering data and leave the lookup 
functionality to the LS. Possible exceptions are rapidly changing metadata 
like the most recent timestamp and full details of data stored in long-term 
archival MAs.</p>
 <p id="rfc.section.2.1.p.3">The architecture of the dLS protocol assumes the 
existence of logical rings of LS instances. The current proposal involves two 
levels of rings: lower scope and upper scope. Lower scope hides inter-domain 
relationships between LS instances while upper scope hides intra-domain 
relationships.</p>
 <h2 id="rfc.section.2.2">
@@ -514,7 +514,7 @@
    |                                                    |
  __V__                      _____                      _V___ 
 |     |                    |     | &lt;_______(1)_______ |     |
-| LS3 | &lt;----------------- | LS2 |                 | LS1 | 
+| LS3 | &lt;----------------- | LS2 |                    | LS1 | 
 |_____|                    |_____| _______(3)_______&gt; |_____|
    |                          ^ ^                       ^ ^
    |                          | |                       | |
@@ -526,8 +526,9 @@
              
              
              </pre>
+<p>LS2, LS3 and LS4 are in the ring. LS1 wants to join the dLS cloud.</p>
 <p class="figure">Figure 3</p>
-<p>  <p id="rfc.section.2.3.1.1.p.2">Let's assume LS2, LS3 and LS4 are in 
the ring. LS1 wants to join the dLS cloud.</p>  </p>
+<p>  <p id="rfc.section.2.3.1.1.p.2">The algorithm for joining the ring 
works as follows:</p>  </p>
 <dl class="empty">
 <dd>1. LS1 - Candidate sends LSControlRequest message with the 
http://perfsonar.net/services/LS/join eventType to selected LS2 which is 
already a member of the ring. LS2 was found in LSRing initial file during 
bootstrapping process.</dd>
 <dd>2. LS2 receives join message from L1 and decides whether to accept it or 
not. A security policy may occur here.</dd>
@@ -575,16 +576,16 @@
              
              
              </pre>
+<p>LS1, LS2 and LS3 are in the ring. LS1 receives a token.</p>
 <p class="figure">Figure 4</p>
-<p id="rfc.section.2.3.2.1.p.2">Let's assume LS1, LS2 and LS3 are in the 
ring. LS1 receives a token.</p>
-<p id="rfc.section.2.3.2.1.p.3">The algorithm for token passing works as 
follows. </p>
+<p id="rfc.section.2.3.2.1.p.2">The algorithm for token passing works as 
follows:</p>
 <dl class="empty">
-<dd>LS1 receives the token i.e. LSControlRequest message with the 
http://perfsonar.net/services/LS/token/ eventType from its predecessor 
L3.</dd>
-<dd>LS1 updates its local peer list based on token content.</dd>
-<dd>LS1 sends LSControlRequest message with the 
http://perfsonar.net/services/LS/summary/ eventType to all peers in the lease 
(excluding itself).</dd>
-<dd>LS2 receiving this message checks its collection and updates it if 
necessary with service info including "contentSize".</dd>
-<dd>LS1 waits for some amount of time.</dd>
-<dd>LS1 sends token to next LS (LS2) from the LSRing lower scope (if it 
fails, try next one).</dd>
+<dd>1. LS1 receives the token i.e. LSControlRequest message with the 
http://perfsonar.net/services/LS/token/ eventType from its predecessor 
L3.</dd>
+<dd>2. LS1 updates its local peer list based on token content.</dd>
+<dd>3. LS1 sends LSControlRequest message with the 
http://perfsonar.net/services/LS/summary/ eventType to all peers in the lease 
(excluding itself).</dd>
+<dd>3. LS2 receiving this message checks its collection and updates it if 
necessary with service info including "contentSize".</dd>
+<dd>4. LS1 waits for some amount of time.</dd>
+<dd>5. LS1 sends token to next LS (LS2) from the LSRing lower scope (if it 
fails, try next one).</dd>
 </dl>
 <h3 id="rfc.section.2.3.3">
 <a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="summary-blast" 
href="#summary-blast">Summarization Notification</a>
@@ -596,7 +597,7 @@
 </ol>
 <p id="rfc.section.2.3.3.p.2">In the first case we are explicitly entering 
ourselves into the ring when we get our first message from a peer. This 
ensures we show up in the token rotation instantly. The second case is the 
routine exchange started when a token arrives from a peer.</p>
 <p id="rfc.section.2.3.3.p.3">
-<a href="#LSControl-Summary-lower" title="LS Summary Message 
(Lower)">Section&nbsp;4.6</a> and <a href="#LSControl-Summary-upper" 
title="LS Summary Message (Upper)">Section&nbsp;4.7</a>contains examples of 
the message format for this exchange. It is left up to the implementation 
when the summarization occurs (i.e. at message send time, or also as a 
periodic event).</p>
+<a href="#LSControl-Summary-lower" title="LS Summary Message 
(Lower)">Section&nbsp;4.6</a> and <a href="#LSControl-Summary-upper" 
title="LS Summary Message (Upper)">Section&nbsp;4.7</a> contain examples of 
the message format for this exchange. It is left up to the implementation 
when the summarization occurs (i.e. at message send time, or also as a 
periodic event).</p>
 <h3 id="rfc.section.2.3.4">
 <a href="#rfc.section.2.3.4">2.3.4</a>&nbsp;<a id="Leader_Election" 
href="#Leader_Election">Leader election</a>
 </h3>
@@ -678,10 +679,10 @@
 <p id="rfc.section.3.p.4">The above discovery algorithm is used to find an 
LS within a given scope. Therefore, the only piece of information an LS 
should need to be pre-configured with is the scope it belongs to. And as 
stated above, that can be assumed to be "global:organization-dns-name". Note: 
Need to define the specific syntax above.</p>
 <hr class="noprint">
 <h1 id="rfc.section.4" class="np">
-<a href="#rfc.section.4">4.</a>&nbsp;<a id="structures-and-messages" 
href="#structures-and-messages">structures and Messages</a>
+<a href="#rfc.section.4">4.</a>&nbsp;<a id="structures-and-messages" 
href="#structures-and-messages">Structures and Messages</a>
 </h1>
 <h2 id="rfc.section.4.1">
-<a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="service-metadata" 
href="#service-metadata">service metadata example</a>
+<a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="service-metadata" 
href="#service-metadata">Service metadata example</a>
 </h2>
 <p id="rfc.section.4.1.p.1">Example of metadata describing information 
collected and stored in Measurement Archive service</p>
 <p id="rfc.section.4.1.p.2">
@@ -1351,6 +1352,7 @@
 <ul>
 <li>error.ls.foo -</li>
 <li>success.ls.foo -</li>
+<li>TBD</li>
 </ul>
 <hr class="noprint">
 <h1 id="rfc.section.6" class="np">

Modified: trunk/nmwg/doc/dLS/dLS.pdf
===================================================================
(Binary files differ)