perfsonar development work

Author: zurawski
Date: 2007-10-10 11:08:35 -0400 (Wed, 10 Oct 2007)
New Revision: 288

Modified:
   trunk/nmwg/doc/dLS/dLS.html
   trunk/nmwg/doc/dLS/dLS.pdf
   trunk/nmwg/doc/dLS/dLS.xml
Log:
Small syntax changes and updated document.

-jason



Modified: trunk/nmwg/doc/dLS/dLS.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS.html 2007-10-10 13:14:31 UTC (rev 287)
+++ trunk/nmwg/doc/dLS/dLS.html 2007-10-10 15:08:35 UTC (rev 288)
@@ -300,8 +300,9 @@
 <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="5 Appendices" href="#rfc.section.5">
-<link rel="Chapter" href="#rfc.section.6" title="6 References">
+<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">
 <meta name="generator" 
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291, 
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica 
http://www.saxonica.com/";>
 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/";>
 <meta name="DC.Creator" content="Boote, J">
@@ -401,24 +402,28 @@
 <a href="#rfc.section.2">2.</a>&nbsp;<a id="system" href="#system">System 
Specific Operation</a>
 </h1>
 <h2 id="rfc.section.2.1">
-<a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="summary" 
href="#summary">Summarization</a>
+<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.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 LS that a service contacts to register 
becomes the "Home LS" (HLS, see <a href="#glossary" 
title="Glossary">Section&nbsp;5.1</a>) of that particular service. It is the 
responsibility of the HLS to make summary data about the all of the pS 
services it knows of available to the larger enterprise and to draw relevant 
queries to itself.</p>
-<p id="rfc.section.2.1.p.4">The construction of such a summary is important 
to the overall success of this service; summaries prevents other LS instances 
from being overloaded by information, must be general enough to allow for 
easy creation and exchange but also must retain enough information to provide 
a rich query interface able to locate the distributed information. That means 
service metadata information must be filtered (summarized) as it propagates 
through the LS cloud. We start by making an observation that summarization is 
best based on scope (see also <a href="#scope" 
title="Scope">Section&nbsp;2.2</a> for forming scope), simply put this means 
that we should attempt to summarize the "most" the "further" away from the 
source that we get. This creates a smaller data set that travels the furthest 
away while keeping the larger and more informative data sets closer to the 
source. We present the strategies as such: </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">
+<a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="summary" 
href="#summary">Summarization</a>
+</h2>
+<p id="rfc.section.2.2.p.1">The LS that a service contacts to register 
becomes the "Home LS" (HLS, see <a href="#glossary" 
title="Glossary">Section&nbsp;6.1</a>) of that particular service. It is the 
responsibility of the HLS to make summary data about the all of the pS 
services it knows of available to the larger enterprise and to draw relevant 
queries to itself.</p>
+<p id="rfc.section.2.2.p.2">The construction of such a summary is important 
to the overall success of this service; summaries prevents other LS instances 
from being overloaded by information, must be general enough to allow for 
easy creation and exchange but also must retain enough information to provide 
a rich query interface able to locate the distributed information. That means 
service metadata information must be filtered (summarized) as it propagates 
through the LS cloud. We start by making an observation that summarization is 
best based on scope (see also <a href="#scope" title="Scope 
Forming">Section&nbsp;2.3</a> for forming scope), simply put this means that 
we should attempt to summarize the "most" the "further" away from the source 
that we get. This creates a smaller data set that travels the furthest away 
while keeping the larger and more informative data sets closer to the source. 
We present the strategies as such: </p>
 <ul>
 <li>Summarization for the "lower scope" (formerly known as "local 
scope")</li>
 <li>Summarization for the "upper scope" (formerly known as "global 
scope")</li>
 </ul>
 <p> We limit the discussion in this case to these two scopes, although 
extension to "n" scopes is possible. As the number of scopes increases 
additional "aggregation" will be necessary to combine information thus 
reducing the size of the data sets further.</p>
-<h3 id="rfc.section.2.1.1">
-<a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a 
id="lower_scope_summarization" href="#lower_scope_summarization">Lower Scope 
Summarization</a>
+<h3 id="rfc.section.2.2.1">
+<a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a 
id="lower_scope_summarization" href="#lower_scope_summarization">Lower Scope 
Summarization</a>
 </h3>
-<p id="rfc.section.2.1.1.p.1">This first level of summarization, between HLS 
instances internal to a domain, consists of simply dropping superfluous 
information from the metadata descriptions provided by registered services. 
For now we define this to be simply removing additional "parameter" elements 
from the metadata. Special consideration must be given to the 
"supportedEventType" parameter by simply converting this to actual eventType 
elements. This will ensure interoperability with legacy services.</p>
-<p id="rfc.section.2.1.1.p.2">Future iterations may choose to drop 
additional pieces of information deemed unnecessary or private such as parts 
of topological descriptions. This sort of modification is encouraged as long 
as the data remains "symmetrical" and conforms to the schematic definitions 
for a given metadata description. It should be noted that such modifications 
will affect the searching procedure and could isolate the source services.</p>
-<p id="rfc.section.2.1.1.p.3">The mechanics for performing this level of 
summarization can use any number of technologies. Either Extensible 
Stylesheet Language Transformation (XSLT) documents or the XQuery language 
(see <a href="#glossary" title="Glossary">Section&nbsp;5.1</a>) may be used 
to prepare the initial data for exchange in this first level. Since the 
exchange of this local information will occur frequently, a simple operation 
that is scheduled or on demand should be employed by the individual 
implementations to ensure the regular LS functions are not impeded.</p>
-<p id="rfc.section.2.1.1.p.4">In order to make information available to the 
LS cloud, the HLS will advertise this summary information to other LS 
instances to propagate the appropriate information. Information exchange will 
be handled using a "taking turns" protocol such as token ring (see <a 
href="#glossary" title="Glossary">Section&nbsp;5.1</a>). The holder of the 
token will then perform the information exchange to other known instances.</p>
+<p id="rfc.section.2.2.1.p.1">This first level of summarization, between HLS 
instances internal to a domain, consists of simply dropping superfluous 
information from the metadata descriptions provided by registered services. 
For now we define this to be simply removing additional "parameter" elements 
from the metadata. Special consideration must be given to the 
"supportedEventType" parameter by simply converting this to actual eventType 
elements. This will ensure interoperability with legacy services.</p>
+<p id="rfc.section.2.2.1.p.2">Future iterations may choose to drop 
additional pieces of information deemed unnecessary or private such as parts 
of topological descriptions. This sort of modification is encouraged as long 
as the data remains "symmetrical" and conforms to the schematic definitions 
for a given metadata description. It should be noted that such modifications 
will affect the searching procedure and could isolate the source services.</p>
+<p id="rfc.section.2.2.1.p.3">The mechanics for performing this level of 
summarization can use any number of technologies. Either Extensible 
Stylesheet Language Transformation (XSLT) documents or the XQuery language 
(see <a href="#glossary" title="Glossary">Section&nbsp;6.1</a>) may be used 
to prepare the initial data for exchange in this first level. Since the 
exchange of this local information will occur frequently, a simple operation 
that is scheduled or on demand should be employed by the individual 
implementations to ensure the regular LS functions are not impeded.</p>
+<p id="rfc.section.2.2.1.p.4">In order to make information available to the 
LS cloud, the HLS will advertise this summary information to other LS 
instances to propagate the appropriate information. Information exchange will 
be handled using a "taking turns" protocol such as token ring. The holder of 
the token will then perform the information exchange to other known instances 
(see <a href="#glossary" title="Glossary">Section&nbsp;6.1</a>).</p>
 <div id="hls-cloud">
 </div>
 <div id="rfc.figure.2">
@@ -454,51 +459,50 @@
              </pre>
 <p>HLS instances communicating via a token message (A). The holder of the 
token (LS3) will inform everyone of it's summary information (B).</p>
 <p class="figure">Figure 2</p>
-<p id="rfc.section.2.1.1.p.6">Once exchanged, the details regarding storage 
in the XML database backend (see <a href="#glossary" 
title="Glossary">Section&nbsp;5.1</a>) are also left to individual 
implementations. It is understood that this information, in the possession of 
non HLS instances, is provided as a convenience and should be treated in the 
same way that directly registered information is (i.e. purged on expiration). 
When requested, credit must also be attributed to the HLS as being 
(non)authoritative for each piece of information.</p>
-<h3 id="rfc.section.2.1.2">
-<a href="#rfc.section.2.1.2">2.1.2</a>&nbsp;<a 
id="upper_scope_summarization" href="#upper_scope_summarization">Upper Scope 
Summarization</a>
+<p id="rfc.section.2.2.1.p.6">Once exchanged, the details regarding storage 
in the XML database backend (see <a href="#glossary" 
title="Glossary">Section&nbsp;6.1</a>) are also left to individual 
implementations. It is understood that this information, in the possession of 
non HLS instances, is provided as a convenience and should be treated in the 
same way that directly registered information is (i.e. purged on expiration). 
When requested, credit must also be attributed to the HLS as being 
(non)authoritative for each piece of information.</p>
+<h3 id="rfc.section.2.2.2">
+<a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;<a 
id="upper_scope_summarization" href="#upper_scope_summarization">Upper Scope 
Summarization</a>
 </h3>
-<p id="rfc.section.2.1.2.p.1">A designated member of each lower ring will be 
required to interact with the upper scope. The mechanics of how we learn who 
is the designated leader is discussed in <a href="#tokens" title="Token 
Passing">Section&nbsp;2.2.2</a>. The leader of each lower scope (and the 
designated backup) will be responsible for examining each member's summary 
information and building a summarization/aggregation that best describes the 
contents of the ring.</p>
-<p id="rfc.section.2.1.2.p.2">The most natural summarization is based on the 
topology of the network (like in network routing). Thus, topology-based 
summarization will include this information as well as eventType information 
from the other LSs. Summarization will be performed using specialized summary 
algorithm. Topology information such as IP addresses will be summarized using 
algorithms basing on radix tree (see <a href="#IP-summary" title="IP 
addresses summarization algorithm">Section&nbsp;2.1.2.1</a>).</p>
-<p id="rfc.section.2.1.2.p.3">Other information can be summarized in a less 
programmatic fashion through the use of either Extensible Stylesheet Language 
Transformation (XSLT) documents or the XQuery language as discussed in the 
previous section. These mechanisms will take into account the XML elements 
that represent the network topology currently used in metadata subjects as 
well as additional items such as eventTypes.</p>
-<p id="rfc.section.2.1.2.p.4">The output of this process becomes a "service 
summary" that represents a breadth of the original input. See <a 
href="#LSControl-Summary-lower" title="LS Summary Message 
(Lower)">Section&nbsp;4.6</a> or <a href="#LSControl-Summary-upper" title="LS 
Summary Message (Upper)">Section&nbsp;4.7</a> for a mock-up of the summary 
output. Additional transformations, while aggressive, will strive to preserve 
as much information as possible to remain useful during the search 
procedures.</p>
-<h4 id="rfc.section.2.1.2.1">
-<a href="#rfc.section.2.1.2.1">2.1.2.1</a>&nbsp;<a id="IP-summary" 
href="#IP-summary">IP addresses summarization algorithm</a>
+<p id="rfc.section.2.2.2.p.1">A designated member of each lower scope will 
be required to interact with the upper scope. The mechanics of how we learn 
who is the designated leader is discussed in <a href="#tokens" title="Token 
Passing">Section&nbsp;2.3.2</a>. The leader of each lower scope (and the 
designated backup) will be responsible for examining each member's summary 
information and building a summarization/aggregation that best describes the 
contents of the ring.</p>
+<p id="rfc.section.2.2.2.p.2">The most natural summarization is based on the 
topology of the network (like in network routing). Thus, topology-based 
summarization will include this information as well as eventType information 
from the other LSs. Summarization will be performed using specialized summary 
algorithm. Topology information such as IP addresses will be summarized using 
algorithms basing on Radix Tree (see <a href="#IP-summary" title="IP 
addresses summarization algorithm">Section&nbsp;2.2.2.1</a>).</p>
+<p id="rfc.section.2.2.2.p.3">Other information can be summarized in a less 
programmatic fashion through the use of either Extensible Stylesheet Language 
Transformation (XSLT) documents or the XQuery language as discussed in the 
previous section. These mechanisms will take into account the XML elements 
that represent the network topology currently used in metadata subjects as 
well as additional items such as eventTypes.</p>
+<p id="rfc.section.2.2.2.p.4">The output of this process becomes a "service 
summary" that represents a breadth of the original input. See <a 
href="#LSControl-Summary-lower" title="LS Summary Message 
(Lower)">Section&nbsp;4.6</a> or <a href="#LSControl-Summary-upper" title="LS 
Summary Message (Upper)">Section&nbsp;4.7</a> for a mock-up of the summary 
output. Additional transformations, while aggressive, will strive to preserve 
as much information as possible to remain useful during the search 
procedures.</p>
+<h4 id="rfc.section.2.2.2.1">
+<a href="#rfc.section.2.2.2.1">2.2.2.1</a>&nbsp;<a id="IP-summary" 
href="#IP-summary">IP addresses summarization algorithm</a>
 </h4>
-<p id="rfc.section.2.1.2.1.p.1">To properly summarize a list of strings such 
as IP addresses we must rely on the help of special algorithms and data 
structures. The <a href="http://en.wikipedia.org/wiki/Radix_tree";>Radix 
Tree</a> algorithm is useful in creating "associative arrays" where the keys 
are expressed as strings. Radix Tree implementations have been used in 
practice to index things such as text documents as well as more menial tasks 
such as dictionaries. We are most interested in indexing IP addresses with 
their natural hierarchy, where it is necessary to describe a large ranges of 
values and have few exceptions.</p>
-<p id="rfc.section.2.1.2.1.p.2">A detailed explanation of the nuances of the 
Radix Tree is well beyond the scope of this document, but a brief overview is 
presented for completeness. The structure itself is best described as a 
binary tree where nodes contain whole values and the edges are the primary 
source of navigation. The edges of the tree can be based on a single 
character or perhaps on even longer strings (one of the features that leads 
to efficiency for small data sets). The algorithm should support the 
following basic operations: </p>
+<p id="rfc.section.2.2.2.1.p.1">To properly summarize a list of strings such 
as IP addresses we must rely on the help of special algorithms and data 
structures. The <a href="http://en.wikipedia.org/wiki/Radix_tree";>Radix 
Tree</a> algorithm is useful in creating "associative arrays" where the keys 
are expressed as strings. Radix Tree implementations have been used in 
practice to index things such as text documents as well as more menial tasks 
such as dictionaries. We are most interested in indexing IP addresses with 
their natural hierarchy, where it is necessary to describe a large ranges of 
values and have few exceptions.</p>
+<p id="rfc.section.2.2.2.1.p.2">A detailed explanation of the nuances of the 
Radix Tree is well beyond the scope of this document, but a brief overview is 
presented for completeness. The structure itself is best described as a 
binary tree where nodes contain whole values and the edges are the primary 
source of navigation. The edges of the tree can be based on a single 
character or perhaps on even longer strings (one of the features that leads 
to efficiency for small data sets). The algorithm should support the 
following basic operations: </p>
 <ul>
 <li>Lookup: Indicate that something is or is not contained in the tree.</li>
 <li>Insert: Like in most inserts we attempt to place something into the 
structure. We first start by doing a Lookup to see if it exists already; the 
point where we stop is where we will insert the object. We are careful to 
utilize the longest matching prefix of any other nearby edge to our 
advantage. This last part is normally referred to as "splitting" and ensures 
that each node has no more than two children.</li>
 <li>Delete: Delete an object from the tree. This operation will be 
complicated by "collapsing" parents that have a single child and merging the 
edges.</li>
 </ul>
-<p id="rfc.section.2.1.2.1.p.3">Once constructed, it is possible to consult 
the structure in creating IP summaries as well as constructing information 
regarding netmasks.</p>
-<h2 id="rfc.section.2.2">
-<a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="scope" href="#scope">Scope</a>
+<p id="rfc.section.2.2.2.1.p.3">Once constructed, it is possible to consult 
the structure in creating IP summaries as well as constructing information 
regarding netmasks.</p>
+<h2 id="rfc.section.2.3">
+<a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="scope" href="#scope">Scope 
Forming</a>
 </h2>
-<p id="rfc.section.2.2.p.1">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.</p>
-<p id="rfc.section.2.2.p.2">The next question is how to form the lower and 
upper scopes. The simplest answer is that the lower scope be formed based on 
the domain name of the participating systems. That would allow e.g. 
internet2.edu, geant2.net, and pionier.gov.pl to potentially operate more 
than one LS instance inside their own domains (for performance and 
scalability.) As LS instances come online they will invoke bootstrapping 
procedures to find and join a lower scoped group first.</p>
-<p id="rfc.section.2.2.p.3">The scopes should be named based on URIs. This 
will allow a domain-level scope to take the form <a 
href="http://internet2.edu";>http://internet2.edu</a>, with subdomain scopes 
named <a href="http://internet2.edu/foo";>http://internet2.edu/foo</a>, etc. 
The top-level scope can be called <a 
href="http://perfsonar.net";>http://perfsonar.net</a> with potential for 
geographic divisions later if necessary for performance (such as <a 
href="http://eu.perfsonar.net";>http://eu.perfsonar.net</a>).</p>
-<p id="rfc.section.2.2.p.4">The major algorithms used to form and maintain 
the ring structure of the dLS, no matter which scope we are talking about, 
are as follows: </p>
+<p id="rfc.section.2.3.p.1">The next question is how to form the lower and 
upper scopes. The simplest answer is that the lower scope be formed based on 
the domain name of the participating systems. That would allow e.g. 
internet2.edu, geant2.net, and pionier.gov.pl to potentially operate more 
than one LS instance inside their own domains (for performance and 
scalability.) As LS instances come online they will invoke bootstrapping 
procedures to find and join a lower scoped group first.</p>
+<p id="rfc.section.2.3.p.2">The scopes should be named based on URIs. This 
will allow a domain-level scope to take the form <a 
href="http://internet2.edu";>http://internet2.edu</a>, with subdomain scopes 
named <a href="http://internet2.edu/foo";>http://internet2.edu/foo</a>, etc. 
The top-level scope can be called <a 
href="http://perfsonar.net";>http://perfsonar.net</a> with potential for 
geographic divisions later if necessary for performance (such as <a 
href="http://eu.perfsonar.net";>http://eu.perfsonar.net</a>).</p>
+<p id="rfc.section.2.3.p.3">The major algorithms used to form and maintain 
the ring structure of the dLS, no matter which scope we are talking about, 
are as follows: </p>
 <ul>
 <li>Join Procedure</li>
 <li>Token Passing</li>
 <li>Summarization Notification</li>
 </ul>
 <p> Each of these procedures is paramount to keeping members of the 
distributed "service" functioning correctly. The algorithms will be presented 
in the frame of the lower scope, but will be used in the same manner for the 
upper scope as well.</p>
-<h3 id="rfc.section.2.2.1">
-<a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a id="join" href="#join">Join 
Procedure</a>
+<h3 id="rfc.section.2.3.1">
+<a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="join" href="#join">Join 
Procedure</a>
 </h3>
-<p id="rfc.section.2.2.1.p.1">When an LS instance comes online it will have 
some bootstrapping knowledge of potential peers (both inter and intra 
domain). The inter-domain knowledge is used first to establish a connection 
to an already in progress ring, or perhaps to start a ring that may not exist 
yet.</p>
-<p id="rfc.section.2.2.1.p.2">An LS will continuously search it's LSRing 
information (see <a href="#LSRing" title="LS Ring File 
Structure">Section&nbsp;4.3</a>) until a successful response to an LSControl 
message (with a "join" eventType, see <a href="#LSControl-Join" title="LS 
Joining Message for Joining a Ring">Section&nbsp;4.4</a>) is seen. The LS 
will search though the successful response to this message and update its 
LSRing with the returned information. This can mean updating the 
"contentSize" and "active" parameters as well as adding new LS instances. 
These parameters are indicative of the size of each LS (i.e. how many 
services are registering with it) and "live-ness" (i.e. were we successful in 
contacting it recently). The contacted LS will also update the local copy of 
LSRing to add the new member to its "available" list.</p>
-<p id="rfc.section.2.2.1.p.3">After updating, the LS will broadcast another 
LSControl message (with a "summary" eventType, see <a 
href="#LSControl-Summary-lower" title="LS Summary Message 
(Lower)">Section&nbsp;4.6</a>, or of we are dealing with the upper level see 
<a href="#LSControl-Summary-upper" title="LS Summary Message 
(Upper)">Section&nbsp;4.7</a>) to all of the "active" LS instances from it's 
LSRing. Again the responses will be parsed to get any useful updated 
information. Each of the recipient LS instances will do the same, including 
adding this new member to their own lists (as many of them will not know of 
it's existence yet).</p>
-<p id="rfc.section.2.2.1.p.4">After this initial warm-up the LS will observe 
the rules of token etiquette and remain silent until it is contacted with a 
token, or it has not seen one in a very long time.</p>
-<h4 id="rfc.section.2.2.1.1">
-<a href="#rfc.section.2.2.1.1">2.2.1.1</a>&nbsp;<a id="join_algorithm" 
href="#join_algorithm">Join Algorithm</a>
+<p id="rfc.section.2.3.1.p.1">When an LS instance comes online it will have 
some bootstrapping knowledge of potential peers (both inter and intra 
domain). This information is contained in LSRing file (see <a href="#LSRing" 
title="LS Ring File Structure">Section&nbsp;4.3</a>). The inter-domain 
knowledge is used first to establish a connection to an already in progress 
ring, or perhaps to start a ring that may not exist yet.</p>
+<p id="rfc.section.2.3.1.p.2">A candidate LS will continuously search it's 
LSRing information and send an LSControl mesage to its know LS instances with 
a "join" eventType (see <a href="#LSControl-Join" title="LS Joining Message 
for Joining a Ring">Section&nbsp;4.4</a>) until a successful response is 
seen. The LS candidate will then search through the successful 
LSControlResponse to this message and update its LSRing with the returned 
information. This can mean updating the "contentSize" and "active" parameters 
as well as adding new LS instances. These parameters are indicative of the 
size of each LS (i.e. how many services are registering with it) and 
"live-ness" (i.e. were we successful in contacting it recently). The 
contacted LS will also update the local copy of LSRing to add the new member 
to its "available" list.</p>
+<p id="rfc.section.2.3.1.p.3">After updating, the newly joined LS will 
broadcast another LSControl message with a "summary" eventType (see <a 
href="#LSControl-Summary-lower" title="LS Summary Message 
(Lower)">Section&nbsp;4.6</a>, or if we are dealing with the upper level see 
<a href="#LSControl-Summary-upper" title="LS Summary Message 
(Upper)">Section&nbsp;4.7</a>) to all of the "active" LS instances from its 
LSRing. Again the responses will be parsed to get any useful updated 
information. At the end of this process joining LS will possess an LSRing 
file reflecting the state of the dLS cloud. Each of the recipient LS 
instances which hasn't heard anything from this joining LS previously will do 
the same, including adding this new member to their own lists (as they didn't 
know of it's existence yet).</p>
+<p id="rfc.section.2.3.1.p.4">After this initial warm-up the LS will observe 
the rules of token etiquette and remain silent until it is contacted with a 
token, or it has not seen one in a very long time (see <a href="#tokens" 
title="Token Passing">Section&nbsp;2.3.2</a>).</p>
+<h4 id="rfc.section.2.3.1.1">
+<a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="join_algorithm" 
href="#join_algorithm">Join Algorithm</a>
 </h4>
-<p id="rfc.section.2.2.1.1.p.1">
+<p id="rfc.section.2.3.1.1.p.1">
 </p>
-<div id="join-example">
+<div id="join-example2">
 </div>
 <div id="rfc.figure.3">
 </div>
@@ -509,9 +513,9 @@
    |                                                    |
    |                                                    |
  __V__                      _____                      _V___ 
-|     |                    |     |            (1)     |     |
-| LS3 | &lt;----------------- | LS2 | &lt;________________&gt; | LS1 | 
-|_____|                    |_____|           (2,3)    |_____|
+|     |                    |     | &lt;_______(1)_______ |     |
+| LS3 | &lt;----------------- | LS2 |                 | LS1 | 
+|_____|                    |_____| _______(3)_______&gt; |_____|
    |                          ^ ^                       ^ ^
    |                          | |                       | |
    |          _____           | |                       | |
@@ -523,58 +527,84 @@
              
              </pre>
 <p class="figure">Figure 3</p>
-<p>  <p id="rfc.section.2.2.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">Let's assume LS2, LS3 and LS4 are in 
the ring. LS1 wants to join the dLS cloud.</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</dd>
-<dd>2. LS2 receives join message from L1 and decides whether to accept it or 
not. A security policy may occur here</dd>
-<dd>3. LS1 gets the answer - success joining (result code: 
http://perfsonar.net/result/success/LS/join) or failure (error code)</dd>
-<dd>4. After receiving the response from LS2, LS1 will parse the results to 
discover all members of the ring.</dd>
-<dd>5. LS1 will "broadcast" its summary info (lower or upper) to all of the 
LS instances it learns of. This is of course "out of turn" as LS1 doesn't 
have the token yet but this reasoning is twofold: <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>
+<dd>3. LS2 sends the LSControlResponse answer indicating success joining 
(result code: http://perfsonar.net/result/success/LS/join) or failure (error 
code).</dd>
+<dd>4. After receiving the response from LS2, LS1 parses the results of 
LSControlResponse to discover all members of its scope.</dd>
+<dd>5. LS1 broadcast its summary info (lower or upper) with LSControl 
message with http://perfsonar.net/services/LS/summary eventType to all of the 
LS instances it learns of. This is of course "out of turn" as LS1 doesn't 
have the token yet but this reasoning is twofold: <dl class="empty">
 <dd>This expedites all ring members knowing the new LS, the ring will grow 
instantly by inserting the new member into the correct position.</dd>
 <dd>This allows the information it provides to the leaders to become 
available for the next upper ring summary as soon as possible. Worst case 
scenarios would place this knowledge cycles away from being recognized.</dd>
 </dl>
 </dd>
-<dd>6. All members of the ring will process the summaries, save the 
necessary information, and recognize the new peer. Responses will be prepared 
for LS1.</dd>
+<dd>6. All members of the ring process the summaries, save the necessary 
information, and recognize the new peer. Responses are sent to LS1.</dd>
 </dl>
-<h3 id="rfc.section.2.2.2">
-<a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;<a id="tokens" 
href="#tokens">Token Passing</a>
+<h3 id="rfc.section.2.3.2">
+<a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="tokens" 
href="#tokens">Token Passing</a>
 </h3>
-<p id="rfc.section.2.2.2.p.1">The "token" is a message (see <a 
href="#LSControl-Token" title="LS Token Message">Section&nbsp;4.5</a>) meant 
to be passed around an LSRing to the various members in some order. There are 
various criterion that can be used in deciding how to order the ring so that 
everyone can predict where the token is, when they might expect to get it, 
and whom they should get it from/ pass it to next. It is important that we 
choose a sound method that is simple to calculate, and should use as much 
"knowledge" of the ring as possible without burdening the LS instances too 
much with complex calculations.</p>
-<p id="rfc.section.2.2.2.p.2">A common method used in P2P (see <a 
href="#glossary" title="Glossary">Section&nbsp;5.1</a>) systems such as 
Gnutella when forming "ultrapeers" is to consider the size of the data that a 
node is serving. The principle, as described <a 
href="http://rakjar.de/gnufu/index.php/GnuFU_en#Network_model:_Change_who_calls_whom:_Ultrapeers_and_Leafs";>here</a>,
 alludes to the fact that nodes with less content to look after (i.e. less 
services, or services with a smaller amount of data) can spend more time and 
effort helping the enterprise as a whole by taking on additional roles (such 
as serving as leaders). As such we will record the number of metadata 
elements that register with each LS and share this with our friends in the 
form of the "contentSize" parameter.</p>
-<p id="rfc.section.2.2.2.p.3">Token passing is directly related to the 
concept of leader election (see <a href="#Leader_Election" title="Leader 
election">Section&nbsp;2.2.4</a>), so more explanation of this approach will 
follow. For now we are justified in saying that the "contentSize" forms a 
good criterion for "ordering" the members of the ring. With all members of 
the ring aware of everyone's data size, we can easily know who we should pass 
the token to, and receive it from at any point in time.</p>
-<p id="rfc.section.2.2.2.p.4">The token can be viewed as "permission to 
talk" and permits the holder to send it's summary information to all 
available LS instances (see <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>). The responses will be parsed to get any 
useful updated information.</p>
-<p id="rfc.section.2.2.2.p.5">The holder of the token, after completing 
summarization, will wait some pre-determined amount of time before sending 
the token to the next LS instance. In general the LS instances should not be 
overly sensitive to the progression of the token. If each LS instance is 
monitoring the progress, and for some reason we have lost the token it may 
start a flurry of retransmits and drops that will take cycles to calm down 
again.</p>
-<p id="rfc.section.2.2.2.p.6">Thus we leave the decisions regarding tokens 
up to a single node, namely the designated leader of a ring. We build 
functionality into leader nodes to be the only "maker" and "executioner" of 
tokens. Extra tokens are dropped/created only by a single node in the ring. 
All strange thrashing behavior is avoided and if something bad happens it is 
eliminated in a single passing. The leader node will have knowledge of the 
size of the ring (even if the Ring has grown our Join algorithm will inform 
all interested parties instantly) and the token "wait" period (should be a 
standard value) thus calculating the expected time is not an issue.</p>
-<h4 id="rfc.section.2.2.2.1">
-<a href="#rfc.section.2.2.2.1">2.2.2.1</a>&nbsp;<a 
id="token_passing_algorithm" href="#token_passing_algorithm">Token passing 
algorithm</a>
+<p id="rfc.section.2.3.2.p.1">The "token" is an LSControlMessage (see <a 
href="#LSControl-Token" title="LS Token Message">Section&nbsp;4.5</a>) meant 
to be passed around an LSRing to the various members in some order. There are 
various criterion that can be used in deciding how to order the ring so that 
everyone can predict where the token is, when they might expect to get it, 
and whom they should get it from/ pass it to next. It is important that we 
choose a sound method that is simple to calculate, and should use as much 
"knowledge" of the ring as possible without burdening the LS instances too 
much with complex calculations.</p>
+<p id="rfc.section.2.3.2.p.2">A common method used in P2P systems such as 
Gnutella when forming "ultrapeers" is to consider the size of the data that a 
node is serving. The principle, as described <a 
href="http://rakjar.de/gnufu/index.php/GnuFU_en#Network_model:_Change_who_calls_whom:_Ultrapeers_and_Leafs";>here</a>,
 alludes to the fact that nodes with less content to look after (i.e. less 
services, or services with a smaller amount of data) can spend more time and 
effort helping the enterprise as a whole by taking on additional roles (such 
as serving as leaders). As such we will record the number of metadata 
elements that register with each LS and share this with our friends in the 
form of the "contentSize" parameter.</p>
+<p id="rfc.section.2.3.2.p.3">Token passing is directly related to the 
concept of leader election (see <a href="#Leader_Election" title="Leader 
election">Section&nbsp;2.3.4</a>), so more explanation of this approach will 
follow. For now we are justified in saying that the "contentSize" forms a 
good criterion for "ordering" the members of the ring. With all members of 
the ring aware of everyone's data size, we can easily know who we should pass 
the token to, and receive it from at any point in time. We assume passing 
order between the LSs from smallest to greatest "contentSize" (with wrap 
around at the ends).</p>
+<p id="rfc.section.2.3.2.p.4">The token can be viewed as "permission to 
talk" and permits the holding LS to send it's summary information to all 
other available LS instances (see <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>). The responses will be parsed to get any 
useful updated information about current dLS cloud state.</p>
+<p id="rfc.section.2.3.2.p.5">The holder of the token, after completing 
summarization, will wait some pre-determined amount of time before sending 
the token to the next LS instance. In general the LS instances should not be 
overly sensitive to the progression of the token. If each LS instance is 
monitoring the progress, and for some reason we have lost the token it may 
start a flurry of retransmits and drops that will take cycles to calm down 
again. Thus we leave the decisions regarding tokens up to a single node, 
namely the designated leader of a scope. We build functionality into leader 
nodes to be the only "maker" and "executioner" of tokens. Extra tokens are 
dropped/created only by a single node in the ring. All strange thrashing 
behavior is avoided and if something bad happens it is eliminated in a single 
passing. The leader node will have knowledge of the size of the ring (even if 
the ring has grown our join algorithm will inform all interested parties 
instantly) and t
 he token "wait" period (should be a standard value) thus calculating the 
expected time is not an issue.</p>
+<h4 id="rfc.section.2.3.2.1">
+<a href="#rfc.section.2.3.2.1">2.3.2.1</a>&nbsp;<a 
id="token_passing_algorithm" href="#token_passing_algorithm">Token Passing 
Algorithm</a>
 </h4>
-<p id="rfc.section.2.2.2.1.p.1">The algorithm for token passing works as 
follows. </p>
+<div id="join-example">
+</div>
+<div id="rfc.figure.4">
+</div>
+<p>Illustration of Token Passing Algorithm</p>
+<pre>
+                          
+   _____________(3)____________
+   |                          |
+   |                          |
+ __V__                      __|__
+|     | &lt;_______(6)_______ |     |
+| LS2 |                    | LS1 |
+|_____| &lt;----------------- |____/T\ Token  
+   |                         ^ |\_/
+   |                         | |
+   |          _____          | |
+   |         |     |         | |
+   |-------&gt; | LS3 | --------| |
+             |_____| &lt;___(3)___|
+                                 
+             
+             
+             </pre>
+<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>
 <dl class="empty">
-<dd>0. When any LS receives the token (LSControlRequest message with the 
http://perfsonar.net/services/LS/token/... eventType, we will do the 
following:</dd>
-<dd>1. Update local peer list (from token)</dd>
-<dd>2. Send summary to all peers in the lease (excluding itself)</dd>
-<dd>3. Wait for some amount of time</dd>
-<dd>4. Send token to next peer from the list (if it fails, try next one)</dd>
+<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>
 </dl>
-<h3 id="rfc.section.2.2.3">
-<a href="#rfc.section.2.2.3">2.2.3</a>&nbsp;<a id="summary-blast" 
href="#summary-blast">summarization Notification</a>
+<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>
 </h3>
-<p id="rfc.section.2.2.3.p.1">As discussed in the prior two sections there 
are two acceptable instances to send your summary to the LSRing: </p>
+<p id="rfc.section.2.3.3.p.1">As discussed in the prior two sections there 
are two acceptable instances to send your summary to the LSRing: </p>
 <ol>
 <li>When first joining</li>
 <li>When holding the token</li>
 </ol>
-<p id="rfc.section.2.2.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.2.3.p.3">
+<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>
-<h3 id="rfc.section.2.2.4">
-<a href="#rfc.section.2.2.4">2.2.4</a>&nbsp;<a id="Leader_Election" 
href="#Leader_Election">Leader election</a>
+<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>
-<p id="rfc.section.2.2.4.p.1">The most important role of the lower ring 
nodes is electing a leader to serve in the upper levels. This logical ring 
should consist of one representative from each of the lower scopes. This 
representative will be selected based on the "contentSize" parameter, which 
as we have discussed previously is a count of the number of metadata elements 
the LS is responsible for. We choose this parameter primarily because it 
imposes a very simple ordering on the nodes, and allows us to choose the 
"least busy" node for performing more important work.</p>
-<p id="rfc.section.2.2.4.p.2">The theory behind this choice of leader is 
that unladen LS instances will not be as loaded processing requests and 
responses from clients and other services, thus the choice to name them as 
leaders is natural. An added feature of this criteria is that it becomes very 
simple to designate a leader LS for a domain; simply deploy an LS instance 
that does not accept registrations. This service will only serve in the role 
of liaison to the upper level.</p>
-<p id="rfc.section.2.2.4.p.3">All LS instances will have a complete view at 
any given time (and updated over time) of the values of the "contentSize" 
parameter for all peer LS instances in an LSRing. This ensures that the 
"Leader" and "Vice-Leader" are always known. Explicit election is therefore 
not required, and succession can pass between the two executives quickly.</p>
-<p id="rfc.section.2.2.4.p.4">The Leader and Vice-Leader LS instances should 
exchange messages periodically to ensure that in the event of a failure the 
lower level will still have a link to the upper level (see <a 
href="#LSControl-Leader" title="LS Leader Message">Section&nbsp;4.8</a>). 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.</p>
-<p id="rfc.section.2.2.4.p.5">
+<p id="rfc.section.2.3.4.p.1">The most important role of the lower scope 
nodes is electing a leader to serve in the upper levels. This logical ring 
should consist of one representative LS from each of the lower scopes. This 
representative will be selected based on the "contentSize" parameter, which 
as we have discussed previously is a count of the number of metadata elements 
the LS is responsible for. We choose this parameter primarily because it 
imposes a very simple ordering on the nodes, and allows us to choose the 
"least busy" node for performing more important work.</p>
+<p id="rfc.section.2.3.4.p.2">The theory behind this choice of leader is 
that unladen LS instances will not be as loaded processing requests and 
responses from clients and other services, thus the choice to name them as 
leaders is natural. An added feature of this criteria is that it becomes very 
simple to designate a leader LS for a domain; simply deploy an LS instance 
that does not accept registrations. This service will only serve in the role 
of liaison to the upper level.</p>
+<p id="rfc.section.2.3.4.p.3">All LS instances will have a complete view at 
any given time (and updated over time) of the values of the "contentSize" 
parameter for all peer LS instances in an LSRing. This ensures that the 
"Leader" and "Vice-Leader" are always known. Explicit election is therefore 
not required, and succession can pass between the two executives quickly.</p>
+<p id="rfc.section.2.3.4.p.4">The Leader and Vice-Leader LS instances should 
exchange messages (see <a href="#LSControl-Leader" title="LS Leader 
Message">Section&nbsp;4.8</a>) 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.</p>
+<p id="rfc.section.2.3.4.p.5">
 <br>
 <br>
 <br>START_NOTE (Maciej 10/3/07):<br>
@@ -583,7 +613,7 @@
 <br>
 <br>
 </p>
-<p id="rfc.section.2.2.4.p.6">
+<p id="rfc.section.2.3.4.p.6">
 <br>
 <br>
 <br>START_NOTE (Jason 10/4/07):<br>
@@ -592,35 +622,35 @@
 <br>
 <br>
 </p>
-<h3 id="rfc.section.2.2.5">
-<a href="#rfc.section.2.2.5">2.2.5</a>&nbsp;<a id="scopes" 
href="#scopes">scopes</a>
+<h3 id="rfc.section.2.3.5">
+<a href="#rfc.section.2.3.5">2.3.5</a>&nbsp;<a id="scopes" 
href="#scopes">Scopes</a>
 </h3>
-<p id="rfc.section.2.2.5.p.1">Scopes are named based on URIs. The top-level 
domain provides a natural basis for the formation of these URIs. These URIs 
may be constructed to allow internal differentiation. In the future, we may 
need a mechanism to provide another level of hierarchy above the domain level 
and below the root, but that is left for future work. Note: I would like to 
see this be something like: <a 
href="http://lsls.perfsonar.net/master/internet2.edu/";>http://lsls.perfsonar.net/master/internet2.edu/</a>.
 Actual syntax doesn"t matter that much but I would like the following 
components: </p>
+<p id="rfc.section.2.3.5.p.1">Scopes are named based on URIs. The top-level 
domain provides a natural basis for the formation of these URIs. These URIs 
may be constructed to allow internal differentiation. In the future, we may 
need a mechanism to provide another level of hierarchy above the domain level 
and below the root, but that is left for future work. Note: I would like to 
see this be something like: <a 
href="http://lsls.perfsonar.net/master/internet2.edu/";>http://lsls.perfsonar.net/master/internet2.edu/</a>.
 Actual syntax doesn't matter that much but I would like the following 
components: </p>
 <ol>
-<li>well-known hostname to get the current root.hints from (lsls)</li>
-<li>a place holder for where we can break the scope between organization and 
upper levels (master)</li>
-<li>a zero-conf default name for the organization (internet2.edu)</li>
+<li>Well-known hostname to get the current root.hints from (lsls)</li>
+<li>A place holder for where we can break the scope between organization and 
upper levels (master)</li>
+<li>A zero-conf default name for the organization (internet2.edu)</li>
 <li>A way to sub-divide the organization (everything after trailing / )</li>
 </ol>
-<h2 id="rfc.section.2.3">
-<a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="search" 
href="#search">Search</a>
+<h2 id="rfc.section.2.4">
+<a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="search" 
href="#search">Search</a>
 </h2>
-<p id="rfc.section.2.3.p.1">The search operation is obviously critical to 
the Lookup Service's function. It is envisioned that searching could take one 
of two major forms, iterative and recursive, analogous to those used in DNS. 
This design will focus exclusively on iterative initially as the only method 
in the first versions of the dLS. The key act when searching is to find what 
eventTypes exist for a particular topology element or set of topology 
elements.</p>
-<p id="rfc.section.2.3.p.2">As outlined above, the full data that services 
register to an LS is not expected to leave the scope of that LS. The 
information is summarized before wider distribution. Therefore, a client 
needs to find an LS in the scope of the HLS to make queries about the 
complete metadata. Specifically, a client wishing to locate information might 
specify a topology element in a query to locate the LS instance (or 
instances) that contain the relevant details. This separation of full data 
and summary data means the overall act of searching is broken down into two 
distinct phases -- Discovery and Metadata Query.</p>
-<h3 id="rfc.section.2.3.1">
-<a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="discovery" 
href="#discovery">Discovery Phase</a>
+<p id="rfc.section.2.4.p.1">The search operation is obviously critical to 
the Lookup Service's function. It is envisioned that searching could take one 
of two major forms, iterative and recursive, analogous to those used in DNS. 
This design will focus exclusively on iterative initially as the only method 
in the first versions of the dLS. The key act when searching is to find what 
eventTypes exist for a particular topology element or set of topology 
elements.</p>
+<p id="rfc.section.2.4.p.2">As outlined above, the full data that services 
register to an LS is not expected to leave the scope of that LS. The 
information is summarized before wider distribution. Therefore, a client 
needs to find an LS in the scope of the HLS to make queries about the 
complete metadata. Specifically, a client wishing to locate information might 
specify a topology element in a query to locate the LS instance (or 
instances) that contain the relevant details. This separation of full data 
and summary data means the overall act of searching is broken down into two 
distinct phases - Discovery and Metadata Query.</p>
+<h3 id="rfc.section.2.4.1">
+<a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;<a id="discovery" 
href="#discovery">Discovery Phase</a>
 </h3>
-<p id="rfc.section.2.3.1.p.1">The Discovery Phase is used to locate the set 
of Authoritative LS (or LSes) for a given Subject/eventType tuple. This 
requires a query to be constructed over the Discovery information set (which 
is not described yet, but which must consist of the 3-tuple of Subject 
Summary, eventType and Authoritative LS.) Either a specific API call and a 
pre-prepared query, or some automatic mechanism, must map the desired query 
into a query of the Discovery infoset (see <a href="#LSControl-Discovery" 
title="LS Discovery Message">Section&nbsp;4.9</a>).</p>
-<h4 id="rfc.section.2.3.1.1">
-<a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="discovery-alg" 
href="#discovery-alg">Discovery Algorithm</a>
+<p id="rfc.section.2.4.1.p.1">The discovery phase is used to locate the set 
of Authoritative LS (or LSes) for a given Subject/eventType tuple. This 
requires a query to be constructed over the Discovery information set (which 
is not described yet, but which must consist of the 3-tuple of Subject 
Summary, eventType and Authoritative LS.) Either a specific API call and a 
pre-prepared query, or some automatic mechanism, must map the desired query 
into a query of the Discovery infoset (see <a href="#LSControl-Discovery" 
title="LS Discovery Message">Section&nbsp;4.9</a>).</p>
+<h4 id="rfc.section.2.4.1.1">
+<a href="#rfc.section.2.4.1.1">2.4.1.1</a>&nbsp;<a id="discovery-alg" 
href="#discovery-alg">Discovery Algorithm</a>
 </h4>
-<p id="rfc.section.2.3.1.1.p.1">The discovery algorithm is as follows.</p>
+<p id="rfc.section.2.4.1.1.p.1">The discovery algorithm is as follows.</p>
 <ol>
 <li>A client locates an LS of some sort (this may be known beforehand via a 
configuration value, or from bootstrapping).</li>
 <li>The client should start by making a discovery query (possibly using an 
API call) to locate an LS that contains the data it is interested in. The 
results of this query will be: <ol style="list-style-type: lower-alpha">
 <li>Failure: Returned if there is no LS at a higher scope than the current 
one, and nothing was found in the summary infoset that matches the query.</li>
 <li>Referral: This is returned when there is no match other than a "global 
wildcard" <ol style="list-style-type: lower-alpha">
-<li>If this LS is not participating in the highest (upper) scope, then it 
returns the leader of its current scope (or a direct referral to an instance 
of the next-higher scope.) This is effectively a wildcard match saying "I 
don"t know the answer, but I know who might." This is how the Metadata 
registered to an LS in another scope (domain) is found.</li>
+<li>If this LS is not participating in the highest (upper) scope, then it 
returns the leader of its current scope (or a direct referral to an instance 
of the next-higher scope.) This is effectively a wildcard match saying "I 
don't know the answer, but I know who might." This is how the Metadata 
registered to an LS in another scope (domain) is found.</li>
 </ol>
 </li>
 <li>Success: We define success to mean at least one matching LS has been 
returned. The LS must return the following: <ol style="list-style-type: 
lower-alpha">
@@ -633,11 +663,11 @@
 </li>
 <li>The client will need to iterate through the list of returned LS 
instances. If the LS returns itself, this LS can be used in the following 
Metadata query phase. If the returned LS is different, a discovery query 
should be made to it.</li>
 </ol>
-<h3 id="rfc.section.2.3.2">
-<a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="metadata-query" 
href="#metadata-query">Metadata Query Phase</a>
+<h3 id="rfc.section.2.4.2">
+<a href="#rfc.section.2.4.2">2.4.2</a>&nbsp;<a id="metadata-query" 
href="#metadata-query">Metadata Query Phase</a>
 </h3>
-<p id="rfc.section.2.3.2.p.1">The Metadata Query Phase with an individual LS 
is the same as the query mechanism that is in place with the current LS 
implementations.</p>
-<p id="rfc.section.2.3.2.p.2">Once we have found the Home LS (or Home LSes) 
that contain data in the range of our discovery query, we can pose Metadata 
Queries to each of them. The results will be failure or success.</p>
+<p id="rfc.section.2.4.2.p.1">The Metadata Query Phase with an individual LS 
is the same as the query mechanism that is in place with the current LS 
implementations.</p>
+<p id="rfc.section.2.4.2.p.2">Once we have found the HLS (or Home LSes) that 
contain data in the range of our discovery query, we can pose Metadata 
Queries to each of them. The results will be failure or success.</p>
 <hr class="noprint">
 <h1 id="rfc.section.3" class="np">
 <a href="#rfc.section.3">3.</a>&nbsp;<a id="bootstrapping" 
href="#bootstrapping">Bootstrapping</a>
@@ -1010,18 +1040,13 @@
 </h2>
 <p id="rfc.section.4.6.p.1">This message exchange represents when an LS 
instance is holding the token and sharing summary information (lower scope). 
The message consists of metadata/data pair(s) that contain service 
information and a parameter indicating "size" of the data set the LS manages 
as well as the minimal (without parameters) summary.</p>
 <p id="rfc.section.4.6.p.2">The response message should indicate success or 
failure via the eventType, and will contain metadata/data pair(s). The 
metadata should indicate who the service is, and its "size" for leader voting 
purposes. The data section is message that can be used for logging.</p>
-<p id="rfc.section.4.6.p.3">Caveots: </p>
+<p id="rfc.section.4.6.p.3">When receiving the message, check your local 
list and update it as needed for: </p>
 <dl class="empty">
-<dd>These messages are sent to everyone when you get a token.</dd>
-<dd>These messages are sent to everyone when you come online (and do not 
necessarily have the token).</dd>
-</dl>
-<p id="rfc.section.4.6.p.4">When receiving the message, check your local 
list and update it as needed for: </p>
-<dl class="empty">
 <dd>Do you know of this service? If so make sure the vote and other info is 
ok.</dd>
 <dd>Update the summary info in your collection</dd>
 <dd>If you don"t know of them, add them!</dd>
 </dl>
-<p id="rfc.section.4.6.p.5">
+<p id="rfc.section.4.6.p.4">
 <pre>
                        
 &lt;nmwg:message type="LSControlRequest"&gt;
@@ -1090,18 +1115,13 @@
 </h2>
 <p id="rfc.section.4.7.p.1">This message exchange represents when an LS 
instance is holding the token and sharing summary information. The message 
consists of metadata/data pair(s) that contain service information and a 
parameter indicating "size" of the data set the LS manages. The "data" 
portion is the summary info (FORMAT TBD!!!)</p>
 <p id="rfc.section.4.7.p.2">The response message should indicate success or 
failure via the eventType, and will contain metadata/data pair(s). The 
metadata should indicate who the service is, and its "size" for leader voting 
purposes. The data section is message that can be used for logging.</p>
-<p id="rfc.section.4.7.p.3">Caveots: </p>
+<p id="rfc.section.4.7.p.3">When receiving the message, check your local 
list and update it as needed for: </p>
 <dl class="empty">
-<dd>These messages are sent to everyone when you get a token.</dd>
-<dd>These messages are sent to everyone when you come online (and do not 
necessarily have the token).</dd>
-</dl>
-<p id="rfc.section.4.7.p.4">When receiving the message, check your local 
list and update it as needed for: </p>
-<dl class="empty">
 <dd>Do you know of this service? If so make sure the vote and other info is 
ok.</dd>
 <dd>Update the summary info in your collection</dd>
-<dd>If you don"t know of them, add them!</dd>
+<dd>If you don't know of them, add them!</dd>
 </dl>
-<p id="rfc.section.4.7.p.5">
+<p id="rfc.section.4.7.p.4">
 <pre>
                        
 &lt;nmwg:message type="LSControlRequest"&gt;
@@ -1326,23 +1346,31 @@
 </p>
 <hr class="noprint">
 <h1 id="rfc.section.5" class="np">
-<a href="#rfc.section.5">5.</a>&nbsp;<a id="apdx" href="#apdx">Appendices</a>
+<a href="#rfc.section.5">5.</a>&nbsp;<a id="codes" href="#codes">Result 
codes</a>
 </h1>
-<h2 id="rfc.section.5.1">
-<a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="glossary" 
href="#glossary">Glossary</a>
+<ul>
+<li>error.ls.foo -</li>
+<li>success.ls.foo -</li>
+</ul>
+<hr class="noprint">
+<h1 id="rfc.section.6" class="np">
+<a href="#rfc.section.6">6.</a>&nbsp;<a id="apdx" href="#apdx">Appendices</a>
+</h1>
+<h2 id="rfc.section.6.1">
+<a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="glossary" 
href="#glossary">Glossary</a>
 </h2>
 <ul>
-<li>AuthotitativeLS -</li>
+<li>AuthoritativeLS - LS that is an authority for the perfSONAR services in 
question. AuthoritativeLS is a result of discovery phase and can be used in 
the metadata query phase.</li>
 <li>Berkeley DB XML - Oracle Berkeley DB XML is an open source, embeddable 
XML database with XQuery-based access to documents stored in containers and 
indexed based on their content.</li>
-<li>Bootstraping -</li>
+<li>Bootstraping - It refers to the process of automatically finding at 
service startup other LS instances of the scope utilizing a previously 
configured registry.</li>
 <li>eXist XML DB - eXist is an Open Source native XML database featuring 
efficient, index-based XQuery processing, automatic indexing, extensions for 
full-text search, XUpdate support, XQuery update extensions and tight 
integration with existing XML development tools.</li>
 <li>Home LS (HLS) - The Home LS of a Service is the LS where the Service 
registers its Lookup Information</li>
 <li>Lookup Service (LS) - The Lookup Service is a key element of the 
perfSONAR framework because it allows every independent service to be a 
visible part of the system. New services may identify themselves to the 
community and provide their detailed capabilities description. Other services 
are able to communicate to the LS in order to get this data called Lookup 
Information. Basic Lookup Service supports registration, query, keepalives 
and de-registration actions (additionally updates?).</li>
 <li>Lookup Information - information registered by a Service in the Lookup 
Service</li>
 <li>Lower Scope - The scoping paradigm meant to indicate inter-domain 
relationships.</li>
-<li>LSRing -</li>
+<li>LSRing - Represents the state of the LS cloud listing available LS 
instances</li>
 <li>Multidomain / Distributed Lookup Information (mLS) - Lookup Service 
which supports summarization and communication with other Lookup Services 
(which might be in the same domain...)</li>
-<li>P2P -</li>
+<li>P2P - network infrastucture that does not have fixed clients and 
servers, but a number of peer nodes that function as both clients and servers 
to the other nodes on the network. This model is contrasted with the 
client-server model.</li>
 <li>Service - A Service is an application that communicates with other 
perfSONAR Services via standardized protocol set (SOAP+XML+NMWGv2)</li>
 <li>Summary Information - aggregated information from Lookup Information 
that is sent by one LS to another</li>
 <li>Token Ring - A ring network in which the network topology features nodes 
connected to exactly two other nodes, forming a circular pathway for signals: 
a ring. Data travels from node to node, with each node handling every packet. 
We use a logical ring in which a "token" message is used to synchronize the 
communication among the nodes.</li>
@@ -1351,7 +1379,7 @@
 <li>XQuery - A query language (with some programming language features) that 
is designed to query collections of XML data. It is semantically similar to 
SQL.</li>
 </ul>
 <h1 class="np" id="rfc.references">
-<a href="#rfc.section.6">6.</a> References</h1>
+<a href="#rfc.section.7">7.</a> References</h1>
 <table summary="References" border="0" cellpadding="2">
 <tr>
 <td class="topnowrap">

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

Modified: trunk/nmwg/doc/dLS/dLS.xml
===================================================================
--- trunk/nmwg/doc/dLS/dLS.xml  2007-10-10 13:14:31 UTC (rev 287)
+++ trunk/nmwg/doc/dLS/dLS.xml  2007-10-10 15:08:35 UTC (rev 288)
@@ -457,7 +457,7 @@
           <section anchor="join_algorithm" title="Join Algorithm"> 
  
             <t>
-            <figure anchor="join-example">
+            <figure anchor="join-example2">
              <preamble>Illustration of LS Join Algorithm</preamble>
              <artwork>
                           (5,6)
@@ -606,10 +606,11 @@
         
 
           <section anchor="token_passing_algorithm" title="Token Passing 
Algorithm">
-
+<!--
           <section anchor="tokenpass_algorithm" title="Toking Passing 
Algorithm"> 
  
             <t>
+-->
             <figure anchor="join-example">
              <preamble>Illustration of Token Passing Algorithm</preamble>
              <artwork>