Skip to Content.
Sympa Menu

perfsonar-dev - nmwg: r319 - trunk/nmwg/doc/dLS

Subject: perfsonar development work

List archive

nmwg: r319 - trunk/nmwg/doc/dLS


Chronological Thread 
  • From:
  • To: ,
  • Subject: nmwg: r319 - trunk/nmwg/doc/dLS
  • Date: Fri, 4 Jan 2008 02:04:53 -0500
Author: boote
Date: 2008-01-04 02:04:52 -0500 (Fri, 04 Jan 2008)
New Revision: 319

Modified:
trunk/nmwg/doc/dLS/dLS_spec.html
trunk/nmwg/doc/dLS/dLS_spec.xml
Log:
Adding additional explaination of scopes and a diagram.



Modified: trunk/nmwg/doc/dLS/dLS_spec.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS_spec.html 2008-01-03 00:36:11 UTC (rev 318)
+++ trunk/nmwg/doc/dLS/dLS_spec.html 2008-01-04 07:04:52 UTC (rev 319)
@@ -1,9 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
-<html xmlns="http://www.w3.org/1999/xhtml";><head><meta
http-equiv="Content-Type" content="text/html; charset=UTF-8"
/><title>Distributed Lookup Service (dLS) in the perfSONAR
Framework</title><meta name="generator" content="DocBook XSL Stylesheets
V1.71.1" /></head><body><div class="article" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h1 class="title"><a
id="id731884"></a>Distributed Lookup Service (dLS) in the perfSONAR
Framework</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Boote</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Glowiak</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Swany</span></h3></div><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Zurawski</span></h3></div></div></div><div><p cla
ss="copyright">Copyright © 2006, 2007 Internet2, Poznan Supercomputing and
Networking Center, University of Delaware</p></div></div><hr /></div><div
class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a
href="#changes">1. Document Changes</a></span></dt><dt><span
class="section"><a href="#introduction">2.
Introduction</a></span></dt><dt><span class="section"><a
href="#system_specific_operation">3. System Specific
Operation</a></span></dt><dd><dl><dt><span class="section"><a
href="#system_overview">3.1. Overview</a></span></dt><dt><span
class="section"><a href="#system_scope">3.2. Scope
Formation</a></span></dt><dd><dl><dt><span class="section"><a
href="#scope_hierarchy">3.2.1. Scope
Hierarchy</a></span></dt><dd><dl><dt><span class="section"><a
href="#scope_defaults">3.2.1.1. Scope
Defaults</a></span></dt></dl></dd><dt><span class="section"><a
href="#scope_algorithms">3.2.2. Scope
Algorithms</a></span></dt><dd><dl><dt><span class="section"><a href="#joi
n_procedure">3.2.2.1. Join Procedure</a></span></dt><dd><dl>!
<dt><spa
n class="section"><a href="#join_alg">3.2.2.1.1.
Algorithm</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#token_messages">3.2.3. Token Messages for Control and
Election</a></span></dt><dd><dl><dt><span class="section"><a
href="#leader_election">3.2.3.1. Leader Election</a></span></dt><dt><span
class="section"><a href="#registration_control">3.2.3.2. Registration
Control</a></span></dt><dd><dl><dt><span class="section"><a
href="#passing_algorithm">3.2.3.2.1. Passing
Algorithm</a></span></dt><dt><span class="section"><a
href="#rotation_time_computation">3.2.3.2.2. Rotation Time
Computation</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#summarization_messages">3.2.4. Summarization
Messages</a></span></dt></dl></dd><dt><span class="section"><a
href="#bootstrapping">3.3. Bootstrapping</a></span></dt><dt><span
class="section"><a href="#system_summarization">3.4.
Summarization</a></span></dt><dd><dl><dt><span class="section"><a href="#
system_summarization_lower">3.4.1. Lower Scope</a></span></dt><dt><span
class="section"><a href="#system_summarization_upper">3.4.2. Upper
Scope</a></span></dt><dd><dl><dt><span class="section"><a
href="#system_summarization_upper_alg">3.4.2.1. IP Address
Algorithm</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#system_search">3.5. Search</a></span></dt><dd><dl><dt><span
class="section"><a href="#system_search_discovery_phase">3.5.1. Discovery
Phase</a></span></dt><dd><dl><dt><span class="section"><a
href="#system_search_discovery_algorithm">3.5.1.1.
Algorithm</a></span></dt></dl></dd><dt><span class="section"><a
href="#system_search_metadata_query_phase">3.5.2. Metadata Query
Phase</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#structures_and_messages">4. Structures and
Messages</a></span></dt><dd><dl><dt><span class="section"><a
href="#service_metadata">4.1. Service Metadata
Example</a></span></dt><dt><span class="section"><a
href="#lookup_info">4.2. Lookup Information</a></span></dt><!
dt><span
class="section"><a href="#ls_ring">4.3. LS Ring File
Structure</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_ring_lower">4.3.1. Lower Level</a></span></dt><dt><span
class="section"><a href="#ls_ring_upper">4.3.2. Upper
Level</a></span></dt></dl></dd><dt><span class="section"><a
href="#ls_join">4.4. LS Join</a></span></dt><dd><dl><dt><span
class="section"><a href="#ls_join_request">4.4.1.
Request</a></span></dt><dt><span class="section"><a
href="#ls_join_response">4.4.2. Response</a></span></dt></dl></dd><dt><span
class="section"><a href="#ls_token_message">4.5. LS Token
Message</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_token_message_request">4.5.1. Request</a></span></dt><dt><span
class="section"><a href="#ls_token_message_response">4.5.2.
Response</a></span></dt></dl></dd><dt><span class="section"><a
href="#ls_summary_message">4.6. LS Summary
Message</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_summary_message_upper">4.6.
1. Upper</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_summary_message_upper_request">4.6.1.1.
Request</a></span></dt><dt><span class="section"><a
href="#ls_summary_message_upper_response">4.6.1.2.
Response</a></span></dt></dl></dd><dt><span class="section"><a
href="#ls_summary_message_lower">4.6.2.
Lower</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_summary_message_lower_request">4.6.2.1.
Request</a></span></dt><dt><span class="section"><a
href="#ls_summary_message_lower_response">4.6.2.2.
Response</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#ls_leader_message">4.7. LS Leader
Message</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_leader_message_request">4.7.1. Request</a></span></dt><dt><span
class="section"><a href="#ls_leader_message_response">4.7.2.
Response</a></span></dt></dl></dd><dt><span class="section"><a
href="#ls_discovery_message">4.8. LS Discovery
Message</a></span></dt><dd><dl><dt><span c
lass="section"><a href="#ls_discovery_message_request">4.8.1!
. Reques
t</a></span></dt><dt><span class="section"><a
href="#ls_discovery_message_response">4.8.2.
Response</a></span></dt></dl></dd></dl></dd><dt><span class="glossary"><a
href="#glossary">Terms</a></span></dt><dt><span class="bibliography"><a
href="#bibliography">References</a></span></dt></dl></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2
class="title" style="clear: both"><a id="changes"></a>1. Document
Changes</h2></div></div></div><div class="table"><a id="table.1"></a><p
class="title"><b>Table 1. Change Log</b></p><div
class="table-contents"><table summary="Change Log" border="1"><colgroup><col
align="left" /></colgroup><thead><tr><th align="left">Version</th><th
align="left">Date</th><th align="left">Description</th><th
align="left">Author(s)</th></tr></thead><tbody><tr><td
align="left">1.0</td><td align="left">12/17/2007</td><td align="left">Initial
Preparation</td><td align="left">J. Zurawski</td></tr><tr><td
align="left">1.1</td><
td align="left">1/1/2008</td><td align="left">Update of Scope Formation and
boot-strapping</td><td align="left">J.
Boote</td></tr></tbody></table></div></div><br class="table-break"
/></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="introduction"></a>2. Introduction</h2></div></div></div><p>
+<html xmlns="http://www.w3.org/1999/xhtml";><head><meta
http-equiv="Content-Type" content="text/html; charset=UTF-8"
/><title>Distributed Lookup Service (dLS) in the perfSONAR
Framework</title><meta name="generator" content="DocBook XSL Stylesheets
V1.71.1" /></head><body><div class="article" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h1 class="title"><a
id="id824766"></a>Distributed Lookup Service (dLS) in the perfSONAR
Framework</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Boote</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Glowiak</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Swany</span></h3></div><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Zurawski</span></h3></div></div></div><div><p cla
ss="copyright">Copyright © 2006, 2007 Internet2, Poznan Supercomputing and
Networking Center, University of Delaware</p></div></div><hr /></div><div
class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a
href="#changes">1. Document Changes</a></span></dt><dt><span
class="section"><a href="#introduction">2.
Introduction</a></span></dt><dt><span class="section"><a
href="#system_specific_operation">3. System Specific
Operation</a></span></dt><dd><dl><dt><span class="section"><a
href="#system_overview">3.1. Overview</a></span></dt><dt><span
class="section"><a href="#system_scope">3.2. Scope
Formation</a></span></dt><dd><dl><dt><span class="section"><a
href="#scope_specification">3.2.1. Scope
Specification</a></span></dt><dt><span class="section"><a
href="#scope_hierarchy">3.2.2. Scope Hierarchy</a></span></dt><dt><span
class="section"><a href="#scope_defaults">3.2.3. Scope
Defaults</a></span></dt><dt><span class="section"><a
href="#scope_algorithms">3.2.4.
Scope Algorithms</a></span></dt><dd><dl><dt><span class="sec!
tion"><a
href="#join_procedure">3.2.4.1. Join
Procedure</a></span></dt><dd><dl><dt><span class="section"><a
href="#join_alg">3.2.4.1.1.
Algorithm</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#token_messages">3.2.5. Token Messages for Control and
Election</a></span></dt><dd><dl><dt><span class="section"><a
href="#leader_election">3.2.5.1. Leader Election</a></span></dt><dt><span
class="section"><a href="#registration_control">3.2.5.2. Registration
Control</a></span></dt><dd><dl><dt><span class="section"><a
href="#passing_algorithm">3.2.5.2.1. Passing
Algorithm</a></span></dt><dt><span class="section"><a
href="#rotation_time_computation">3.2.5.2.2. Rotation Time
Computation</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#summarization_messages">3.2.6. Summarization
Messages</a></span></dt></dl></dd><dt><span class="section"><a
href="#bootstrapping">3.3. Bootstrapping</a></span></dt><dt><span
class="section"><a href="#system_summarization"
>3.4. Summarization</a></span></dt><dd><dl><dt><span class="section"><a
>href="#system_summarization_lower">3.4.1. Lower
>Scope</a></span></dt><dt><span class="section"><a
>href="#system_summarization_upper">3.4.2. Upper
>Scope</a></span></dt><dd><dl><dt><span class="section"><a
>href="#system_summarization_upper_alg">3.4.2.1. IP Address
>Algorithm</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
>href="#system_search">3.5. Search</a></span></dt><dd><dl><dt><span
>class="section"><a href="#system_search_discovery_phase">3.5.1. Discovery
>Phase</a></span></dt><dd><dl><dt><span class="section"><a
>href="#system_search_discovery_algorithm">3.5.1.1.
>Algorithm</a></span></dt></dl></dd><dt><span class="section"><a
>href="#system_search_metadata_query_phase">3.5.2. Metadata Query
>Phase</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
>href="#structures_and_messages">4. Structures and
>Messages</a></span></dt><dd><dl><dt><span class="section"><a
>href="#service_metad
ata">4.1. Service Metadata Example</a></span></dt><dt><span !
class="s
ection"><a href="#lookup_info">4.2. Lookup
Information</a></span></dt><dt><span class="section"><a href="#ls_ring">4.3.
LS Ring File Structure</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_ring_lower">4.3.1. Lower Level</a></span></dt><dt><span
class="section"><a href="#ls_ring_upper">4.3.2. Upper
Level</a></span></dt></dl></dd><dt><span class="section"><a
href="#ls_join">4.4. LS Join</a></span></dt><dd><dl><dt><span
class="section"><a href="#ls_join_request">4.4.1.
Request</a></span></dt><dt><span class="section"><a
href="#ls_join_response">4.4.2. Response</a></span></dt></dl></dd><dt><span
class="section"><a href="#ls_token_message">4.5. LS Token
Message</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_token_message_request">4.5.1. Request</a></span></dt><dt><span
class="section"><a href="#ls_token_message_response">4.5.2.
Response</a></span></dt></dl></dd><dt><span class="section"><a
href="#ls_summary_message">4.6. LS Summary Message</a></span>
</dt><dd><dl><dt><span class="section"><a
href="#ls_summary_message_upper">4.6.1.
Upper</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_summary_message_upper_request">4.6.1.1.
Request</a></span></dt><dt><span class="section"><a
href="#ls_summary_message_upper_response">4.6.1.2.
Response</a></span></dt></dl></dd><dt><span class="section"><a
href="#ls_summary_message_lower">4.6.2.
Lower</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_summary_message_lower_request">4.6.2.1.
Request</a></span></dt><dt><span class="section"><a
href="#ls_summary_message_lower_response">4.6.2.2.
Response</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#ls_leader_message">4.7. LS Leader
Message</a></span></dt><dd><dl><dt><span class="section"><a
href="#ls_leader_message_request">4.7.1. Request</a></span></dt><dt><span
class="section"><a href="#ls_leader_message_response">4.7.2.
Response</a></span></dt></dl></dd><dt><span class="section"><a href="#ls_
discovery_message">4.8. LS Discovery Message</a></span></dt>!
<dd><dl>
<dt><span class="section"><a href="#ls_discovery_message_request">4.8.1.
Request</a></span></dt><dt><span class="section"><a
href="#ls_discovery_message_response">4.8.2.
Response</a></span></dt></dl></dd></dl></dd><dt><span class="glossary"><a
href="#glossary">Terms</a></span></dt><dt><span class="bibliography"><a
href="#bibliography">References</a></span></dt></dl></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2
class="title" style="clear: both"><a id="changes"></a>1. Document
Changes</h2></div></div></div><div class="table"><a id="table.1"></a><p
class="title"><b>Table 1. Change Log</b></p><div
class="table-contents"><table summary="Change Log" border="1"><colgroup><col
align="left" /></colgroup><thead><tr><th align="left">Version</th><th
align="left">Date</th><th align="left">Description</th><th
align="left">Author(s)</th></tr></thead><tbody><tr><td
align="left">1.0</td><td align="left">12/17/2007</td><td align="left">Initial
Prepa
ration</td><td align="left">J. Zurawski</td></tr><tr><td
align="left">1.1</td><td align="left">1/1/2008</td><td align="left">Update of
Scope Formation and boot-strapping</td><td align="left">J.
Boote</td></tr></tbody></table></div></div><br class="table-break"
/></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="introduction"></a>2. Introduction</h2></div></div></div><p>
This document describes the
<span class="emphasis"><em>Distributed Lookup Service</em></span>
(<span><strong class="command">dLS</strong></span>)
- in the <a href="#id862043">perfSONAR</a> system. This modification
extends
+ in the <a href="#id905462">perfSONAR</a> system. This modification
extends
the basic <span class="emphasis"><em>Lookup Service</em></span>
(<span><strong class="command">LS</strong></span>)
functionality that has been present in the system for some time. The
basic LS supports the storage and querying of
@@ -66,7 +66,7 @@
<a href="#lookup_info">Lookup Information</a>).
</p><p>
The idea is to move the metadata from a service-local
- <a href="#id862061">XML</a> data store to a specialized
+ <a href="#id905480">XML</a> data store to a specialized
<span><strong class="command">LS</strong></span> with additional
searching capabilities. The
<span><strong class="command">LS</strong></span> consists of an
XML database, (i.e.
<a href="#Berkeley DB XML">Berkeley DB XML</a> or <a
href="#eXist XML DB">eXist XML DB</a>)
@@ -158,18 +158,12 @@
</p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="system_scope"></a>3.2. Scope Formation</h3></div></div></div><p>
Each <span><strong class="command">LS</strong></span> instance
holds registration and
summarization data relative to a specific
- <span class="emphasis"><em>Scope</em></span>.
+ <span class="emphasis"><em>Scope</em></span> (and included
+ <span class="emphasis"><em>Sub-Scope</em></span>).
The <span class="emphasis"><em>Scope</em></span> is used to
restrict the
amount of information that needs to be shared globally, but
still allow the information to be found.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="scope_hierarchy"></a>3.2.1. Scope Hierarchy</h4></div></div></div><p>
- The hierarchy of <span><strong
class="command">LS</strong></span> servers is largely
- determined by configuration. Each new <span><strong
class="command">LS</strong></span>
- will be configured with a defined <span
class="emphasis"><em>Scope</em></span>
- specification. This <span
class="emphasis"><em>Scope</em></span> plays a
- similar role as domains in the <span><strong
class="command">DNS</strong></span>
- architecure.
- </p><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="scope_specification"></a>3.2.1. Scope
Specification</h4></div></div></div><p>
<span class="emphasis"><em>Scope's</em></span> are specified
as a '!' separated
list of URIs, the protocol schema of each URI is defined as
'psls'. (A simplified URI syntax is being used, not the
@@ -180,31 +174,40 @@
will be found by removing components of the
<span class="emphasis"><em>Scope</em></span> while child
<span class="emphasis"><em>Scopes</em></span> will be found
by
- concatenating additional components on.
+ adding additional components on.
</p><p>
+ A typical <span class="emphasis"><em>Scope</em></span>
specification
+ might look like:
+ </p><pre class="programlisting">
+
+ psls://perfsonar.net/!psls://ls.internet2.edu
+
+ </pre><p>
+ </p><p>
To traverse up to the parent
<span class="emphasis"><em>Scope</em></span> level, the
following steps
are applied:
</p><div class="orderedlist"><ol type="1"><li>
- If the last URI in the list has a path component, the
- last path component is removed and the remaining URI
- is used as the last component of the URI list, and
- defines the parent <span
class="emphasis"><em>Scope</em></span>.
+ If the last URI in the list has a path component,
+ the last path component is removed and the
+ remaining URI is used as the last component of
+ the URI list, and defines the parent
+ <span class="emphasis"><em>Scope</em></span>.
</li><li>
If the last URI has a fully qualified hostname with
- more than two parts (for example, www.example.com has
- three parts, or labels) then the first component of
- the hostname is removed, and the resulting URI is
used
- as the last URI in the list, and defines the parent
- <span class="emphasis"><em>Scope</em></span>.
+ more than two parts (for example, www.example.com
+ has three parts, or labels) then the first
+ component of the hostname is removed, and the
+ resulting URI is used as the last URI in the list,
+ and defines the parent <span
class="emphasis"><em>Scope</em></span>.
</li><li>
- If the last URI has a fully qualified hostname with
two
- or less parts (for example, example.com) then the
entire
- URI is removed from the URI list and the now
truncated
- URI list defines the parent <span
class="emphasis"><em>Scope</em></span>.
- If the last URI is being removed from this action,
then
- there is no parent, and you are at the root of this
- hierarchy.
+ If the last URI has a fully qualified hostname with
+ two or less parts (for example, example.com) then
+ the entire URI is removed from the URI list and the
+ now truncated URI list defines the parent
+ <span class="emphasis"><em>Scope</em></span>. If
the last URI is
+ being removed from this action, then there is no
+ parent, and you are at the root of this hierarchy.
</li></ol></div><p>
</p><p>
When configuring a new <span><strong
class="command">LS</strong></span> instance the
@@ -214,82 +217,142 @@
</p><div class="orderedlist"><ol type="1"><li>
If the new <span><strong
class="command">LS</strong></span> is in the same DNS
domain as the final URI in the given
- <span class="emphasis"><em>Scope</em></span>, a path
component can
- be appended to create a new <span
class="emphasis"><em>Scope</em></span>.
- (A new <span><strong
class="command">LS</strong></span> can simply
- use the same <span
class="emphasis"><em>Scope</em></span> specification,
- the reason to create a new one might be to sub-divide
- a domain for performance reasons.)
- </li><li>
- If the new <span><strong
class="command">LS</strong></span> is in a DNS sub-domain
- of the final URI in the given
- <span class="emphasis"><em>Scope</em></span>,
- the final URI can use the full sub-domain as the
- hostname component of the final URI.
- </li><li>
+ <span class="emphasis"><em>Scope</em></span>, a path
component can be
+ appended to create a new
+ <span class="emphasis"><em>Scope</em></span>. (A new
+ <span><strong class="command">LS</strong></span> can
simply use the same
+ <span class="emphasis"><em>Scope</em></span>
specification, the
+ reason to create a new one might be to sub-divide a
+ domain for performance reasons.) </li><li>
+ If the new <span><strong
class="command">LS</strong></span> is in a DNS
+ sub-domain of the final URI in the given
+ <span class="emphasis"><em>Scope</em></span>, the
final URI can use
+ the full sub-domain as the hostname component of
+ the final URI. </li><li>
If the new <span><strong
class="command">LS</strong></span> is in a different
domain, then it can append a new URI to the list.
</li></ol></div><p>
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="scope_defaults"></a>3.2.1.1. Scope Defaults</h5></div></div></div><p>
- The default <span class="emphasis"><em>Scope</em></span>
- <span><strong class="command">SHOULD</strong></span> be
determined by appending a URI
- with the fully qualified hostname of the host running the
- <span><strong class="command">LS</strong></span> to the
global ls.perfsonar.net domain
- that will be supported by the perfSONAR consortium.
- For example,
- a new <span><strong class="command">LS</strong></span>
started on ls.example.com would
- get a default <span
class="emphasis"><em>Scope</em></span> of:
- </p><pre class="programlisting">
-
- psls://perfsonar.net/!psls://ls.example.com
-
- </pre><p>
- </p><p>
- Given this default, the scopes that will be defined
- from the top of the hierarchy will be:
- </p><div class="orderedlist"><ol type="1"><li>
- psls://perfsonar.net
- </li><li>
- psls://perfsonar.net/!psls://example.com
- </li><li>
- psls://perfsonar.net/!psls://ls.example.com
- </li></ol></div><p>
- </p><p>
- This particular choice of defaults means that each domain
- that runs more than one <span><strong
class="command">LS</strong></span> will
- automatically create a sub scope within the domain.
- This is a useful setup if specific <span><strong
class="command">LS</strong></span>
- instances will be dedicated to specific measurements
- (especially geographically). However, if a domain is
- running multiple <span><strong
class="command">LS</strong></span> instances for
- reliability reasons alone, they should define the
- bottom <span class="emphasis"><em>Scope</em></span> to
the same thing
- for all of their instances (For example, by leaving
- the hostname component off of the fully-qualified
- hostname.)
- </p><p>
- The perfSONAR portion of the Scope hierarchy is
- made up of one level. The leader of this level
- will still have responsibilities regarding
- token rotation and Ring Joining, but will not need to
- Join a parent level with the Ring summary.
- It is expected that several
- members of the perfSONAR consortium will run servers
- to support the perfsonar.net level
- <span class="emphasis"><em>Scope</em></span> and in
effect be the
- root servers for the perfSONAR Lookup Service.
- In the future, it might make sense to sub-divide the
- perfsonar.net domain to allow for geographic
distributions
- based upon continents or countries. This optimizations
- can be added in after the fact, without changing
- <span><strong class="command">Scope</strong></span>
specifications for already
- deployed <span><strong
class="command">LS</strong></span> instances. (Already
- deployed <span><strong
class="command">LS</strong></span> instances would simply
- jump over the geographic <span
class="emphasis"><em>Scope</em></span>
- directly to the root <span
class="emphasis"><em>Scope</em></span>. This
- would not be as efficient for discovery, but will
- continue to work.
- </p></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="scope_algorithms"></a>3.2.2. Scope Algorithms</h4></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="scope_hierarchy"></a>3.2.2. Scope Hierarchy</h4></div></div></div><p>
+ The hierarchy of <span><strong
class="command">LS</strong></span> servers is largely
+ determined by configuration. Each new <span><strong
class="command">LS</strong></span>
+ will be configured with a defined <span
class="emphasis"><em>Scope</em></span>
+ specification. This <span
class="emphasis"><em>Scope</em></span> plays a
+ similar role as domains in the <span><strong
class="command">DNS</strong></span>
+ architecure. It allows you to name the area where specific
+ information can be found, with more specific
+ <span class="emphasis"><em>Scopes</em></span> indicating
more specific
+ information content.
+ </p><p>
+ The <span class="emphasis"><em>Scope</em></span> hierarchy
is simply an
+ organization of <span><strong
class="command">LS</strong></span> instances grouped
+ into more and more specific subsets.
+ </p><p>
+ </p><div class="mediaobject"><img
src="images/global_scope.png" /></div><p>
+ </p><p>
+ Using the above diagram, we can explain how the given
+ <span><strong class="command">LS</strong></span> instances
interact and the roles they
+ play:
+ </p><div class="itemizedlist"><ul type="disc"><li>
+ A and B are both in the same domain (and have the
+ same scope specification). They will do
+ intra-summary sharing of information with each
+ other. One of them will be elected as the
+ leader of the 'domain' level, and will summarize
+ the domain for participation in the global
+ ring.
+ </li><li><p>
+ C and D have a similar arrangement as A and B
+ above, but are part of a sub-domain. This
sub-domain
+ will be summarized and one of (C or D) will
+ represent the sub-domain information in the
+ domain level ring.
+ </p><p>
+ E and F have the exact same arrangement as
+ C and D.
+ </p><p>
+ The two leaders from these two sub-domains
+ will participate in a domain level ring - and
+ have a leader election at the domain level
+ scope. The winner of that election will
+ represent the domain by summarizing all content
+ from the domain (and therefore the
+ sub-domains) in the global scope by particpating
+ in the global ring.
+ </p></li><li><p>
+ H is specified using a sub-scope of the one G
+ is specified with. H is in a scope of its
+ own, and therefore participates in a ring
+ of one. Another <span><strong
class="command">LS</strong></span> instance
+ could be started using the same scope
+ specification - but it is not necessary.
+ H will summarize its own content (inter-scope
+ style summarization) and as the leader will
+ particpate in a domain level ring with G.
+ </p><p>
+ G and H will elect a leader of the domain
+ level scope and summarize the domain for
+ participation in the global ring.
+ </p></li></ul></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="scope_defaults"></a>3.2.3. Scope Defaults</h4></div></div></div><p>
+ The default <span class="emphasis"><em>Scope</em></span>
+ <span><strong class="command">SHOULD</strong></span> be
determined by appending a URI
+ with the fully qualified hostname of the host running the
+ <span><strong class="command">LS</strong></span> to the
global ls.perfsonar.net domain
+ that will be supported by the perfSONAR consortium.
+ For example,
+ a new <span><strong class="command">LS</strong></span>
started on ls.example.com would
+ get a default <span class="emphasis"><em>Scope</em></span>
of:
+ </p><pre class="programlisting">
+
+ psls://perfsonar.net/!psls://ls.example.com
+
+ </pre><p>
+ </p><p>
+ Given this default, the scopes that will be defined
+ from the top of the hierarchy will be:
+ </p><div class="orderedlist"><ol type="1"><li>
+ psls://perfsonar.net
+ </li><li>
+ psls://perfsonar.net/!psls://example.com
+ </li><li>
+ psls://perfsonar.net/!psls://ls.example.com
+ </li></ol></div><p>
+ </p><p>
+ This particular choice of defaults means that each domain
+ that runs more than one <span><strong
class="command">LS</strong></span> will
+ automatically create a sub scope within the domain.
+ This is a useful setup if specific <span><strong
class="command">LS</strong></span>
+ instances will be dedicated to specific measurements
+ (especially geographically). However, if a domain is
+ running multiple <span><strong
class="command">LS</strong></span> instances for
+ reliability reasons alone, they should define the
+ bottom <span class="emphasis"><em>Scope</em></span> to the
same thing
+ for all of their instances (For example, by leaving
+ the hostname component off of the fully-qualified
+ hostname.)
+ </p><p>
+ The perfSONAR portion of the Scope hierarchy is
+ made up of one level. The leader of this level
+ will still have responsibilities regarding
+ token rotation and Ring Joining, but will not need to
+ Join a parent level with the Ring summary.
+ It is expected that several
+ members of the perfSONAR consortium will run servers
+ to support the perfsonar.net level
+ <span class="emphasis"><em>Scope</em></span> and in effect
be the
+ root servers for the perfSONAR Lookup Service.
+ In the future, it might make sense to sub-divide the
+ perfsonar.net domain to allow for geographic distributions
+ based upon continents or countries. This optimizations
+ can be added in after the fact, without changing
+ <span><strong class="command">Scope</strong></span>
specifications for already
+ deployed <span><strong class="command">LS</strong></span>
instances. (Already
+ deployed <span><strong class="command">LS</strong></span>
instances would simply
+ jump over the geographic <span
class="emphasis"><em>Scope</em></span>
+ directly to the root <span
class="emphasis"><em>Scope</em></span>. This
+ would not be as efficient for discovery, but will
+ continue to work.
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="scope_algorithms"></a>3.2.4. Scope Algorithms</h4></div></div></div><p>
The major algorithms used to form and maintain the structure
of the <span><strong class="command">dLS</strong></span>, no
matter which scope we are
talking about, are as follows:
@@ -301,7 +364,7 @@
algorithms will be presented in the frame of <span><strong
class="command">HLS</strong></span>
instances communicating in a lower scope, but will be used
in the same
manner for inter-domain communication as an upper scope as
well.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="join_procedure"></a>3.2.2.1. Join Procedure</h5></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="join_procedure"></a>3.2.4.1. Join Procedure</h5></div></div></div><p>
When an <span><strong class="command">LS</strong></span>
instance comes online it must have some
knowledge of potential peers (both inter and intra
scope). This
information is contained in <span
class="emphasis"><em>LSRing</em></span> (see
@@ -340,7 +403,7 @@
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="#token_messages">Token Messages for Control and
Election</a>).
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="join_alg"></a>3.2.2.1.1. Algorithm</h6></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="join_alg"></a>3.2.4.1.1. Algorithm</h6></div></div></div><p>
The algorithm for joining a logical group works as
follows. Some
steps have been simplified for the sake of the
diagram. Additional
steps (i.e. security, individual requests and
responses, etc.) are
@@ -439,7 +502,7 @@
request from <span><strong
class="command">LS1</strong></span> and responses with proper
error code
</p></li></ol></div><p>
- </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="token_messages"></a>3.2.3. Token Messages for Control and
Election</h4></div></div></div><p>
+ </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="token_messages"></a>3.2.5. Token Messages for Control and
Election</h4></div></div></div><p>
When scopes are created, they form themselves into logical groups
around which tokens must be passed. This token passing mechanism
is
used for two purposes: <a href="#leader_election">Leader
Election</a> and
@@ -458,7 +521,7 @@
calculate, and should use as much <span
class="emphasis"><em>knowledge</em></span> of
the group as possible without burdening the <span><strong
class="command">LS</strong></span>
instances too much with complex calculations.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="leader_election"></a>3.2.3.1. Leader Election</h5></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="leader_election"></a>3.2.5.1. Leader Election</h5></div></div></div><p>
The essential idea in the token passing mechanism for leader
election is that some identifier is chosen for each node and that
the node with the highest identifier win the election and becomes
@@ -545,7 +608,7 @@
communicate backup information with this vice leader. It is not
important for the rest of the group to know who the vice leader
may be.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="registration_control"></a>3.2.3.2. Registration
Control</h5></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="registration_control"></a>3.2.5.2. Registration
Control</h5></div></div></div><p>
The token can be viewed as <span class="emphasis"><em>permission
to talk</em></span>
and permits the holding <span><strong
class="command">LS</strong></span> to send its summary
information to all other available <span><strong
class="command">LS</strong></span> instances
@@ -553,7 +616,7 @@
<a href="#ls_summary_message_upper">Upper</a>). The responses
will
be parsed to get any useful updated information about current
<span><strong class="command">dLS</strong></span> cloud state.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="passing_algorithm"></a>3.2.3.2.1. Passing
Algorithm</h6></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="passing_algorithm"></a>3.2.5.2.1. Passing
Algorithm</h6></div></div></div><p>
The algorithm for token passing is described in the following
image and list.
</p><p>
@@ -597,7 +660,7 @@
<a href="#rotation_time_computation">Rotation Time
Computation</a>) it should be
dropped. This will ensure that too many tokens do not enter
into
the group at a given time.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="rotation_time_computation"></a>3.2.3.2.2. Rotation Time
Computation</h6></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="rotation_time_computation"></a>3.2.5.2.2. Rotation Time
Computation</h6></div></div></div><p>
The token rotation time can best be described as the time
required
to receive, service, and temper traffic within the
<span><strong class="command">LS</strong></span> group. Each
<span><strong class="command">LS</strong></span> instance
@@ -616,7 +679,7 @@
that the leader has failed and another election should be
initiated. Conversely if a token is seen too early (less than
half the calculated time) the token should be dropped.
- </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="summarization_messages"></a>3.2.4. Summarization
Messages</h4></div></div></div><p>
+ </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="summarization_messages"></a>3.2.6. Summarization
Messages</h4></div></div></div><p>
<a href="#system_summarization_lower">Lower Scope</a> and
<a href="#system_summarization_upper">Upper Scope</a> contain
examples of the
message format for this exchange. It is left up to the
@@ -1668,8 +1731,8 @@
A query language (with some programming language
features) that is designed to query collections of XML data. It
is semantically similar to SQL.
- </p></dd></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div></div><div class="bibliography"><div
class="titlepage"><div><div><h2 class="title"><a
id="bibliography"></a>References</h2></div></div></div><div
class="biblioentry"><a id="id862043"></a><p>[<abbr
class="abbrev">perfSONAR</abbr>] <span class="title"><i>
+ </p></dd></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div></div><div class="bibliography"><div
class="titlepage"><div><div><h2 class="title"><a
id="bibliography"></a>References</h2></div></div></div><div
class="biblioentry"><a id="id905462"></a><p>[<abbr
class="abbrev">perfSONAR</abbr>] <span class="title"><i>
<a href="http://www.perfsonar.net"; target="_top">perfSONAR</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id862061"></a><p>[<abbr class="abbrev">XML</abbr>] <span class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id905480"></a><p>[<abbr class="abbrev">XML</abbr>] <span class="title"><i>
<a href="http://www.w3.org/XML"; target="_top">Extensible Markup
Language (XML)</a>
</i>. </span></p></div></div></div></body></html>

Modified: trunk/nmwg/doc/dLS/dLS_spec.xml
===================================================================
--- trunk/nmwg/doc/dLS/dLS_spec.xml 2008-01-03 00:36:11 UTC (rev 318)
+++ trunk/nmwg/doc/dLS/dLS_spec.xml 2008-01-04 07:04:52 UTC (rev 319)
@@ -286,24 +286,16 @@
<para>
Each <command>LS</command> instance holds registration and
summarization data relative to a specific
- <emphasis>Scope</emphasis>.
+ <emphasis>Scope</emphasis> (and included
+ <emphasis>Sub-Scope</emphasis>).
The <emphasis>Scope</emphasis> is used to restrict the
amount of information that needs to be shared globally, but
still allow the information to be found.
</para>

- <section id="scope_hierarchy" xreflabel="Scope Hierarchy">
- <title>Scope Hierarchy</title>
+ <section id="scope_specification" xreflabel="Scope Specification">
+ <title>Scope Specification</title>
<para>
- The hierarchy of <command>LS</command> servers is largely
- determined by configuration. Each new <command>LS</command>
- will be configured with a defined <emphasis>Scope</emphasis>
- specification. This <emphasis>Scope</emphasis> plays a
- similar role as domains in the <command>DNS</command>
- architecure.
- </para>
-
- <para>
<emphasis>Scope's</emphasis> are specified as a '!' separated
list of URIs, the protocol schema of each URI is defined as
'psls'. (A simplified URI syntax is being used, not the
@@ -314,38 +306,49 @@
will be found by removing components of the
<emphasis>Scope</emphasis> while child
<emphasis>Scopes</emphasis> will be found by
- concatenating additional components on.
+ adding additional components on.
</para>

<para>
+ A typical <emphasis>Scope</emphasis> specification
+ might look like:
+ <programlisting>
+ <![CDATA[
+ psls://perfsonar.net/!psls://ls.internet2.edu
+ ]]>
+ </programlisting>
+ </para>
+
+ <para>
To traverse up to the parent
<emphasis>Scope</emphasis> level, the following steps
are applied:
<orderedlist numeration="arabic">
<listitem>
- If the last URI in the list has a path component, the
- last path component is removed and the remaining URI
- is used as the last component of the URI list, and
- defines the parent <emphasis>Scope</emphasis>.
+ If the last URI in the list has a path component,
+ the last path component is removed and the
+ remaining URI is used as the last component of
+ the URI list, and defines the parent
+ <emphasis>Scope</emphasis>.
</listitem>

<listitem>
If the last URI has a fully qualified hostname with
- more than two parts (for example, www.example.com has
- three parts, or labels) then the first component of
- the hostname is removed, and the resulting URI is
used
- as the last URI in the list, and defines the parent
- <emphasis>Scope</emphasis>.
+ more than two parts (for example, www.example.com
+ has three parts, or labels) then the first
+ component of the hostname is removed, and the
+ resulting URI is used as the last URI in the list,
+ and defines the parent <emphasis>Scope</emphasis>.
</listitem>

<listitem>
- If the last URI has a fully qualified hostname with
two
- or less parts (for example, example.com) then the
entire
- URI is removed from the URI list and the now
truncated
- URI list defines the parent
<emphasis>Scope</emphasis>.
- If the last URI is being removed from this action,
then
- there is no parent, and you are at the root of this
- hierarchy.
+ If the last URI has a fully qualified hostname with
+ two or less parts (for example, example.com) then
+ the entire URI is removed from the URI list and the
+ now truncated URI list defines the parent
+ <emphasis>Scope</emphasis>. If the last URI is
+ being removed from this action, then there is no
+ parent, and you are at the root of this hierarchy.
</listitem>
</orderedlist>
</para>
@@ -359,21 +362,20 @@
<listitem>
If the new <command>LS</command> is in the same DNS
domain as the final URI in the given
- <emphasis>Scope</emphasis>, a path component can
- be appended to create a new
<emphasis>Scope</emphasis>.
- (A new <command>LS</command> can simply
- use the same <emphasis>Scope</emphasis>
specification,
- the reason to create a new one might be to sub-divide
- a domain for performance reasons.)
- </listitem>
+ <emphasis>Scope</emphasis>, a path component can be
+ appended to create a new
+ <emphasis>Scope</emphasis>. (A new
+ <command>LS</command> can simply use the same
+ <emphasis>Scope</emphasis> specification, the
+ reason to create a new one might be to sub-divide a
+ domain for performance reasons.) </listitem>

<listitem>
- If the new <command>LS</command> is in a DNS
sub-domain
- of the final URI in the given
- <emphasis>Scope</emphasis>,
- the final URI can use the full sub-domain as the
- hostname component of the final URI.
- </listitem>
+ If the new <command>LS</command> is in a DNS
+ sub-domain of the final URI in the given
+ <emphasis>Scope</emphasis>, the final URI can use
+ the full sub-domain as the hostname component of
+ the final URI. </listitem>

<listitem>
If the new <command>LS</command> is in a different
@@ -381,81 +383,169 @@
</listitem>
</orderedlist>
</para>
+ </section>

- <section id="scope_defaults" xreflabel="Scope Defaults">
- <title>Scope Defaults</title>
- <para>
- The default <emphasis>Scope</emphasis>
- <command>SHOULD</command> be determined by appending a
URI
- with the fully qualified hostname of the host running the
- <command>LS</command> to the global ls.perfsonar.net
domain
- that will be supported by the perfSONAR consortium.
- For example,
- a new <command>LS</command> started on ls.example.com
would
- get a default <emphasis>Scope</emphasis> of:
- <programlisting>
- <![CDATA[
- psls://perfsonar.net/!psls://ls.example.com
- ]]>
- </programlisting>
- </para>
+ <section id="scope_hierarchy" xreflabel="Scope Hierarchy">
+ <title>Scope Hierarchy</title>
+ <para>
+ The hierarchy of <command>LS</command> servers is largely
+ determined by configuration. Each new <command>LS</command>
+ will be configured with a defined <emphasis>Scope</emphasis>
+ specification. This <emphasis>Scope</emphasis> plays a
+ similar role as domains in the <command>DNS</command>
+ architecure. It allows you to name the area where specific
+ information can be found, with more specific
+ <emphasis>Scopes</emphasis> indicating more specific
+ information content.
+ </para>

- <para>
- Given this default, the scopes that will be defined
- from the top of the hierarchy will be:
- <orderedlist>
- <listitem>
- psls://perfsonar.net
- </listitem>
- <listitem>
- psls://perfsonar.net/!psls://example.com
- </listitem>
- <listitem>
- psls://perfsonar.net/!psls://ls.example.com
- </listitem>
- </orderedlist>
- </para>
+ <para>
+ The <emphasis>Scope</emphasis> hierarchy is simply an
+ organization of <command>LS</command> instances grouped
+ into more and more specific subsets.
+ </para>

- <para>
- This particular choice of defaults means that each domain
- that runs more than one <command>LS</command> will
- automatically create a sub scope within the domain.
- This is a useful setup if specific <command>LS</command>
- instances will be dedicated to specific measurements
- (especially geographically). However, if a domain is
- running multiple <command>LS</command> instances for
- reliability reasons alone, they should define the
- bottom <emphasis>Scope</emphasis> to the same thing
- for all of their instances (For example, by leaving
- the hostname component off of the fully-qualified
- hostname.)
- </para>
+ <para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/global_scope.png"/>
+ </imageobject>
+ </mediaobject>
+ </para>

- <para>
- The perfSONAR portion of the Scope hierarchy is
- made up of one level. The leader of this level
- will still have responsibilities regarding
- token rotation and Ring Joining, but will not need to
- Join a parent level with the Ring summary.
- It is expected that several
- members of the perfSONAR consortium will run servers
- to support the perfsonar.net level
- <emphasis>Scope</emphasis> and in effect be the
- root servers for the perfSONAR Lookup Service.
- In the future, it might make sense to sub-divide the
- perfsonar.net domain to allow for geographic
distributions
- based upon continents or countries. This optimizations
- can be added in after the fact, without changing
- <command>Scope</command> specifications for already
- deployed <command>LS</command> instances. (Already
- deployed <command>LS</command> instances would simply
- jump over the geographic <emphasis>Scope</emphasis>
- directly to the root <emphasis>Scope</emphasis>. This
- would not be as efficient for discovery, but will
- continue to work.
- </para>
+ <para>
+ Using the above diagram, we can explain how the given
+ <command>LS</command> instances interact and the roles they
+ play:
+ <itemizedlist>
+ <listitem>
+ A and B are both in the same domain (and have the
+ same scope specification). They will do
+ intra-summary sharing of information with each
+ other. One of them will be elected as the
+ leader of the 'domain' level, and will summarize
+ the domain for participation in the global
+ ring.
+ </listitem>
+ <listitem>
+ <para>
+ C and D have a similar arrangement as A and B
+ above, but are part of a sub-domain. This
sub-domain
+ will be summarized and one of (C or D) will
+ represent the sub-domain information in the
+ domain level ring.
+ </para>
+ <para>
+ E and F have the exact same arrangement as
+ C and D.
+ </para>
+ <para>
+ The two leaders from these two sub-domains
+ will participate in a domain level ring - and
+ have a leader election at the domain level
+ scope. The winner of that election will
+ represent the domain by summarizing all content
+ from the domain (and therefore the
+ sub-domains) in the global scope by particpating
+ in the global ring.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ H is specified using a sub-scope of the one G
+ is specified with. H is in a scope of its
+ own, and therefore participates in a ring
+ of one. Another <command>LS</command> instance
+ could be started using the same scope
+ specification - but it is not necessary.
+ H will summarize its own content (inter-scope
+ style summarization) and as the leader will
+ particpate in a domain level ring with G.
+ </para>
+ <para>
+ G and H will elect a leader of the domain
+ level scope and summarize the domain for
+ participation in the global ring.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>

- </section>
+
+ <section id="scope_defaults" xreflabel="Scope Defaults">
+ <title>Scope Defaults</title>
+ <para>
+ The default <emphasis>Scope</emphasis>
+ <command>SHOULD</command> be determined by appending a URI
+ with the fully qualified hostname of the host running the
+ <command>LS</command> to the global ls.perfsonar.net domain
+ that will be supported by the perfSONAR consortium.
+ For example,
+ a new <command>LS</command> started on ls.example.com would
+ get a default <emphasis>Scope</emphasis> of:
+ <programlisting>
+ <![CDATA[
+ psls://perfsonar.net/!psls://ls.example.com
+ ]]>
+ </programlisting>
+ </para>
+
+ <para>
+ Given this default, the scopes that will be defined
+ from the top of the hierarchy will be:
+ <orderedlist>
+ <listitem>
+ psls://perfsonar.net
+ </listitem>
+ <listitem>
+ psls://perfsonar.net/!psls://example.com
+ </listitem>
+ <listitem>
+ psls://perfsonar.net/!psls://ls.example.com
+ </listitem>
+ </orderedlist>
+ </para>
+
+ <para>
+ This particular choice of defaults means that each domain
+ that runs more than one <command>LS</command> will
+ automatically create a sub scope within the domain.
+ This is a useful setup if specific <command>LS</command>
+ instances will be dedicated to specific measurements
+ (especially geographically). However, if a domain is
+ running multiple <command>LS</command> instances for
+ reliability reasons alone, they should define the
+ bottom <emphasis>Scope</emphasis> to the same thing
+ for all of their instances (For example, by leaving
+ the hostname component off of the fully-qualified
+ hostname.)
+ </para>
+
+ <para>
+ The perfSONAR portion of the Scope hierarchy is
+ made up of one level. The leader of this level
+ will still have responsibilities regarding
+ token rotation and Ring Joining, but will not need to
+ Join a parent level with the Ring summary.
+ It is expected that several
+ members of the perfSONAR consortium will run servers
+ to support the perfsonar.net level
+ <emphasis>Scope</emphasis> and in effect be the
+ root servers for the perfSONAR Lookup Service.
+ In the future, it might make sense to sub-divide the
+ perfsonar.net domain to allow for geographic distributions
+ based upon continents or countries. This optimizations
+ can be added in after the fact, without changing
+ <command>Scope</command> specifications for already
+ deployed <command>LS</command> instances. (Already
+ deployed <command>LS</command> instances would simply
+ jump over the geographic <emphasis>Scope</emphasis>
+ directly to the root <emphasis>Scope</emphasis>. This
+ would not be as efficient for discovery, but will
+ continue to work.
+ </para>
+
</section>

<section id="scope_algorithms" xreflabel="Scope Algorithms">
@@ -701,7 +791,7 @@
</section>
</section>
</section>
-
+
<section id="token_messages" xreflabel="Token Messages for Control and
Election">
<title>Token Messages for Control and Election</title>



  • nmwg: r319 - trunk/nmwg/doc/dLS, svnlog, 01/04/2008

Archive powered by MHonArc 2.6.16.

Top of Page