Skip to Content.
Sympa Menu

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

Subject: perfsonar development work

List archive

nmwg: r318 - trunk/nmwg/doc/dLS


Chronological Thread 
  • From:
  • To: ,
  • Subject: nmwg: r318 - trunk/nmwg/doc/dLS
  • Date: Wed, 2 Jan 2008 19:36:12 -0500
Author: boote
Date: 2008-01-02 19:36:11 -0500 (Wed, 02 Jan 2008)
New Revision: 318

Modified:
trunk/nmwg/doc/dLS/dLS_spec.html
trunk/nmwg/doc/dLS/dLS_spec.xml
Log:
Adding lots of information on Scope formation.



Modified: trunk/nmwg/doc/dLS/dLS_spec.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS_spec.html 2008-01-02 15:46:48 UTC (rev 317)
+++ trunk/nmwg/doc/dLS/dLS_spec.html 2008-01-03 00:36:11 UTC (rev 318)
@@ -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="#join_procedure">3.2.1. Join Procedure</a></span></dt><dd><dl><dt><span
class="section"><a href="#join_alg">3.2.1.1.
Algorithm</a></span></dt></dl></dd><dt><span class="section"><a
href="#token_messages">3.2.2. Token Messages for Control and
Election</a></span></dt><dd><dl><dt><span class="section"><a hr
ef="#leader_election">3.2.2.1. Leader Election</a></span></d!
t><dt><s
pan class="section"><a href="#registration_control">3.2.2.2. Registration
Control</a></span></dt><dd><dl><dt><span class="section"><a
href="#passing_algorithm">3.2.2.2.1. Passing
Algorithm</a></span></dt><dt><span class="section"><a
href="#rotation_time_computation">3.2.2.2.2. Rotation Time
Computation</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#summarization_messages">3.2.3. 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 clas
s="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_j!
oin">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="#bib
liography">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></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="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>
This document describes the
<span class="emphasis"><em>Distributed Lookup Service</em></span>
(<span><strong class="command">dLS</strong></span>)
- in the <a href="#id861630">perfSONAR</a> system. This modification
extends
+ in the <a href="#id862043">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
@@ -44,20 +44,29 @@
crux of this service.
</p></li></ul></div><p>
</p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="system_specific_operation"></a>3. System Specific
Operation</h2></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a
id="system_overview"></a>3.1. Overview</h3></div></div></div><p>
- The first step of information flow is when a general
+ The first step of any discovery service is finding the
appropriate
+ servers. Any <span class="emphasis"><em>perfSONAR</em></span>
client that is looking
+ for information, or any <span
class="emphasis"><em>perfSONAR</em></span> server
+ that is attempting to publish information will use the same
+ <span class="emphasis"><em>bootstrapping</em></span> protocol to
find the appropriate
+ <span><strong class="command">LS</strong></span> server(s) to
interact with.
+ </p><p>
+ The initial information flow happens when a general
<span class="emphasis"><em>perfSONAR</em></span> service
registers with an
- <span><strong class="command">LS</strong></span> instance. The
service should know the name of an
- <span><strong class="command">LS</strong></span> via static
configuration (the most common case
- for legacy deployments), or may learn through other advanced
methods.
- A service registers a <span class="emphasis"><em>service
metadata</em></span> record about
+ <span><strong class="command">LS</strong></span> instance. The
service will know the
+ Scope that it wants the information published in, and will
+ use that in the <span
class="emphasis"><em>bootstrapping</em></span> protocol
+ to determine which <span><strong
class="command">LS</strong></span> instance(s) to
+ initially pubish to. A service registers a <span
class="emphasis"><em>service
+ metadata</em></span> record about
itself and full metadata (i.e. containing all static measurement
information such as subject, eventType(s), and any parameters,
see
- <a href="#service_metadata">Service Metadata Example</a>) about
stored data it has knowledge
- of. Such a record is called Lookup Information (see
+ <a href="#service_metadata">Service Metadata Example</a>) about
stored data it has
+ knowledge of. Such a record is called Lookup Information (see
<a href="#lookup_info">Lookup Information</a>).
</p><p>
The idea is to move the metadata from a service-local
- <a href="#id861648">XML</a> data store to a specialized
+ <a href="#id862061">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>)
@@ -70,17 +79,18 @@
full details of data stored in long-term archival
<span class="emphasis"><em>Measurement Archives</em></span>
(<span><strong class="command">MA</strong></span>s).
</p><p>
- The architecture of the <span><strong
class="command">dLS</strong></span> protocol assumes the
- existence of logical groups of <span><strong
class="command">LS</strong></span> instances. The
- architecture allows for multiple levels thus representing splits
- of a hierarchy. The model of interaction between any two specific
+ The architecture of the <span><strong
class="command">dLS</strong></span> proscribes the
+ existence of logical groups of <span><strong
class="command">LS</strong></span> instances
+ orgainized in scoped hierarchies.
+ The model of interaction between any two specific
<span><strong class="command">LS</strong></span> instances
depends only upon the relative
relationship in the hierarchy, not upon the specific location in
the hierarchy. (A given LS instance will only communicate with
another LS if it is in the same scope, or one scope above it.)
For that reason, most references to other scopes
in the hierarchy
- will be made refering to <span
class="emphasis"><em>lower</em></span> and
+ will be made refering to <span
class="emphasis"><em>lower</em></span>,
+ <span class="emphasis"><em>current</em></span> and
<span class="emphasis"><em>upper</em></span> scopes and these
references are made
relative to the specific <span><strong
class="command">LS</strong></span> instance. The
exception to this rule is for instances that end up in the very
@@ -93,21 +103,24 @@
discovery data set.
</p><p>
To better define this classification consider an example at a
high
- level: inter-domain communication. It is natural to assume that
+ level: inter-domain communication. It is natural to assume that
a single domain will deploy an <span><strong
class="command">LS</strong></span> instance to
manage deployed services. A goal of <span
class="emphasis"><em>perfSONAR</em></span>
is to ease the detection of end to end performance issues
particularly across domain boundaries, therefore communication
between domain
<span><strong class="command">LS</strong></span> instances is
paramount. We assume for this
- example that the <span class="emphasis"><em>top</em></span> most
level is that of the
- domain. (So, all domain-level <span><strong
class="command">LS</strong></span> instances
- will have joined a common scope.)
+ example that the <span class="emphasis"><em>top</em></span> most
level is the
+ set of all
+ domains. (So, all domain-level <span><strong
class="command">LS</strong></span> instances
+ will have joined a common top-level scope.)
A single domain will likely
have multiple <span><strong class="command">LS</strong></span>
instances deployed. For
example, they might have one deployed for each individual
type of Measurement Archive (MA) they have deployed to distribute
- the load of metadata queries.
+ the load of metadata queries - or to optimize the types of
+ searches those specific <span><strong
class="command">LS</strong></span> instances
+ need to do.
In this example,
a <span class="emphasis"><em>leader</em></span> from this set of
domain
<span><strong class="command">LS</strong></span> instances will
represent the domain in the
@@ -116,7 +129,8 @@
case.
</p><p>
The scoping designations are important to the next stage: data
- reduction. We observe that the abundance of information
available via
+ reduction. We observe that the abundance of information
available
+ via
the original metadata description is rather obtuse when it comes
to
answering a simple (and common) query such as <span
class="emphasis"><em>give me
bandwidth data for host x</em></span>.
@@ -126,193 +140,306 @@
complete metadata into smaller and smaller sets as the
information
is passed through the scope hierarchy. (From bottom to top.)
</p><p>
- Finally, using the scoping and summarizing steps we come to the
final,
+ Finally, using the scoping and summarizing steps we come to the
+ final,
and arguably most important phase: search. Search must rely on
two
phases to work efficiently in the <span><strong
class="command">dLS</strong></span> framework,
namely discovery and query. The first step is locating
<span class="emphasis"><em>where</em></span> information can be
found. This involves
- asking semi direct questions regarding the well defined network
topology
- in order to locate the <span
class="emphasis"><em>vicinity</em></span> of data. The query
- phase will then ask more esoteric questions once it locates the
proper
+ asking semi direct questions regarding the well defined network
+ topology
+ in order to locate the <span
class="emphasis"><em>vicinity</em></span> of data.
+ The query
+ phase will then ask more esoteric questions once it locates the
+ proper
<span><strong class="command">LS</strong></span> instances to
ask. The discovery phase is made
possible through the process of summarization, while the query
phase
- remains similar to the current <span><strong
class="command">LS</strong></span> functionality.
+ remains similar to the current <span><strong
class="command">LS</strong></span> functionality.
</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>
- The first aspect of this system is how to form the hierarchy of
- <span><strong class="command">LS</strong></span> instances and
subsequently organize the scopes.
- The simplest answer is that the highest scope be formed based on the
- domain name of the participating systems as mentioned in the previous
- examples. That would allow e.g. <span
class="emphasis"><em>internet2.edu</em></span>,
- <span class="emphasis"><em>geant2.net</em></span>, and <span
class="emphasis"><em>pionier.gov.pl</em></span>
- to potentially operate more than one <span><strong
class="command">LS</strong></span> instance
- inside their own domains (for performance and scalability.) As
- <span><strong class="command">LS</strong></span> instances come
online they will invoke
- <span class="emphasis"><em>bootstrapping</em></span> procedures to
find and join a lower
- scoped group first. The <span><strong
class="command">LS</strong></span> that a service contacts
- to register becomes the <span class="emphasis"><em>Home
LS</em></span> (
- <a href="#HLS">HLS</a>) of that particular service.
- </p><p>
- The scopes should be named based on URIs. This will allow a
- domain-level scope to take the form
- <a href="http://internet2.edu";
target="_top">http://internet2.edu</a>,
- with subdomain scopes named
- <a href="http://internet2.edu/foo";
target="_top">http://internet2.edu/foo</a>,
- etc. The top-level scope can be called
- <a href="http://perfsonar.net"; target="_top">http://perfsonar.net</a>
- with potential for geographic divisions later if necessary for
- performance (such as
- <a href="http://eu.perfsonar.net";
target="_top">http://eu.perfsonar.net</a>).
- </p><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:
- </p><p>
- </p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p><a href="#join_procedure">Join
Procedure</a> - Join Procedure</p></li><li style="list-style-type:
circle"><p><a href="#token_messages">Token Messages for Control and
Election</a> - Token Passing</p></li><li style="list-style-type:
circle"><p><a href="#summarization_messages">Summarization Messages</a> -
Summarization Notification</p></li></ul></div><p>
- </p><p>
- Each of these procedures is important to keeping members of the
- distributed <span class="emphasis"><em>service</em></span>
functioning correctly. The
- 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><h4 class="title"><a
id="join_procedure"></a>3.2.1. Join Procedure</h4></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
- <a href="#ls_ring">LS Ring File Structure</a>) files. The
inter-domain knowledge (i.e.
- <span class="emphasis"><em>lower</em></span>) is used first to
establish a connection
- to an already in progress grouping, or perhaps to start a group
that
- may not exist yet.
- </p><p>
- A joining <span><strong class="command">LS</strong></span> will
continuously search the
- <span class="emphasis"><em>LSRing</em></span> information and send
an
- <span class="emphasis"><em>LSControl</em></span> message to known
<span><strong class="command">LS</strong></span>
- instances with a <span class="emphasis"><em>join</em></span>
- <span class="emphasis"><em>eventType</em></span> (see <a
href="#ls_join">LS Join</a>)
- until a successful response is seen. The <span><strong
class="command">LS</strong></span>
- candidate will then search through the successful
- <span class="emphasis"><em>LSControlResponse</em></span> to this
message and update its
- <span class="emphasis"><em>LSRing</em></span> information with the
returned information.
- This can mean updating the <span
class="emphasis"><em>active</em></span> and
- <span class="emphasis"><em>leader</em></span> parameters as well
as adding new
- <span><strong class="command">LS</strong></span> instances. The
first parameter is indicative of
- the <span class="emphasis"><em>live-ness</em></span> (i.e. were we
successful in
- contacting it recently), the second is used to indicate who the
- current <span class="emphasis"><em>leader</em></span> of this
group is. These dynamic
- variables will be constantly changing.
- </p><p>
- For security purposes, it is necessary for the members of the
- <span class="emphasis"><em>LSRing</em></span> to know that a new
member has joined
- without that member authenticating pairwise with each other member
of
- the group. To accomplish this, the initially contacted
- <span><strong class="command">LS</strong></span> will request that
the current group leader
- initiate a token rotation to allow all members to update their
- <span class="emphasis"><em>LSRing</em></span> files thus allowing
instant recognition of
- the new member.
- </p><p>
- After this initial warm-up the <span><strong
class="command">LS</strong></span> 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="#token_messages">Token Messages for Control and
Election</a>).
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="join_alg"></a>3.2.1.1. Algorithm</h5></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
- not fully enumerated for this description.
- </p><p>
- </p><div class="mediaobject"><img src="images/ls_join1.png"
/></div><p>
- </p><p>
- </p><div class="orderedlist"><ol type="1"><li><p>
- <span><strong class="command">LS1</strong></span>
(candidate to the group) sends
- <span class="emphasis"><em>join</em></span>
- (<span
class="emphasis"><em>http://perfsonar.net/services/LS/join</em></span>
- eventType) request to <span><strong
class="command">LS7</strong></span> (non-functioning
- member from some group). This request will time out and
- <span><strong class="command">LS1</strong></span> must try
again.
- </p></li><li><p>
- <span><strong class="command">LS1</strong></span> sends
another
- <span class="emphasis"><em>join</em></span>
- (<span
class="emphasis"><em>http://perfsonar.net/services/LS/join</em></span>
- eventType) request to <span><strong
class="command">LS2</strong></span> (member of the
- group). <span><strong class="command">LS2</strong></span>
receives
- <span class="emphasis"><em>join</em></span> message from
<span><strong class="command">LS1</strong></span>
- and decides whether to accept it or not. Application of
- security policy may occur here.
- </p></li><li><p>
- <span><strong class="command">LS2</strong></span> accepts
<span class="emphasis"><em>join</em></span>
- request from <span><strong
class="command">LS1</strong></span> and responds with success
- code and <span class="emphasis"><em>LSRing</em></span>
content.
- <span><strong class="command">LS1</strong></span> will
accept this, parse the response
- and update it's own <span
class="emphasis"><em>LSRing</em></span>.
- <span><strong class="command">LS1</strong></span> will now
wait (i.e. the length of
- the token rotation time, see
- <a href="#rotation_time_computation">Rotation Time
Computation</a>) until it is time
- to speak to the group.
- </p></li><li><p>
- <span><strong class="command">LS2</strong></span> sends
- <span class="emphasis"><em>updateToken</em></span>
- (<span
class="emphasis"><em>http://perfsonar.net/services/LS/updateToken</em></span>
- eventType) to <span><strong
class="command">LS3</strong></span> (the leader of the
- group). <span
class="emphasis"><em>updateToken</em></span> contains the
- URL of <span><strong class="command">LS1</strong></span>.
<span><strong class="command">LS3</strong></span> updates
- its <span class="emphasis"><em>LSRing</em></span> with URL
of
- <span><strong class="command">LS1</strong></span>. The
job of informing the remainder of
- the group now belongs to the leader, <span><strong
class="command">LS3</strong></span>.
- Note that if <span><strong
class="command">LS3</strong></span> was initially contacted
- this step would be unnecessary.
- </p></li><li><p>
- <span><strong class="command">LS3</strong></span>
immediately sends
- <span class="emphasis"><em>updateToken</em></span>
- (<span
class="emphasis"><em>http://perfsonar.net/services/LS/updateToken</em></span>)
- to next peer from <span
class="emphasis"><em>LSRing</em></span>.
- <span class="emphasis"><em>updateToken</em></span>
contains updated
- <span class="emphasis"><em>LSRing</em></span> information.
This will be
- exchanged between all peers. This message will not be
- marked as a duplicate or dropped by any members of the
group.
- Note that additional tokens may still be circulating
through
- the group before or after this token, they will proceed as
- usual as this particular token is special for the
- <span class="emphasis"><em>control</em></span> of the
service.
- </p></li><li><p>
- <span><strong class="command">LS3</strong></span> also
must send a
- <span class="emphasis"><em>leader election</em></span>
token immediately to
- trigger a new election cycle. This will also exchanged
- between all peers.
- </p></li><li><p>
- After full cycle of passing the
- <span class="emphasis"><em>updateToken</em></span>,
<span><strong class="command">LS3</strong></span>
- receives the message again (identified by
- <span class="emphasis"><em>messageIdRef</em></span>) and
drops it immediately.
- Now all group members have knowledge about newly joined
- <span><strong class="command">LS1</strong></span>.
- </p></li><li><p>
- After a full cycle of leader election, a new leader is
- known. This new leader may start the backup leader
election.
- See <a href="#leader_election">Leader Election</a> for
more details.
- </p></li><li><p>
- Regular token exchange and summarization notification will
- resume in time.
- </p></li></ol></div><p>
- </p><p>
- Similarly, the initially contacted LS may choose to ignore the
- initial request from a candidate LS.
- </p><p>
- </p><div class="mediaobject"><img src="images/ls_join2.png"
/></div><p>
- </p><p>
- </p><div class="orderedlist"><ol type="1"><li><p>
- <span><strong class="command">LS1</strong></span>
(candidate to the group) sends
- <span class="emphasis"><em>join</em></span>
- (<span
class="emphasis"><em>http://perfsonar.net/services/LS/join</em></span>
- eventType) request to <span><strong
class="command">LS2</strong></span> (member of the
- group). <span><strong class="command">LS2</strong></span>
receives
- <span class="emphasis"><em>join</em></span> message from
<span><strong class="command">LS1</strong></span>
- and decides whether to accept it or not. Application of
- security policy may occur here.
- </p></li><li><p>
- <span><strong class="command">LS2</strong></span> rejects
<span class="emphasis"><em>join</em></span>
- request from <span><strong
class="command">LS1</strong></span> and responses with proper
- error code
- </p></li></ol></div><p>
- </p></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.2. Token Messages for Control and
Election</h4></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>.
+ 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>
+ <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
+ complete URI specification so port numbers and protocol
+ specifications other than 'psls' are not allowed.) The full
+ string defines the current
+ <span class="emphasis"><em>Scope</em></span>. Parent <span
class="emphasis"><em>Scopes</em></span>
+ 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.
+ </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>.
+ </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>.
+ </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.
+ </li></ol></div><p>
+ </p><p>
+ When configuring a new <span><strong
class="command">LS</strong></span> instance the
+ the following steps can be used to define child
+ <span class="emphasis"><em>Scopes</em></span> of a given
current
+ <span class="emphasis"><em>Scope</em></span>:
+ </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>
+ 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>
+ 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:
+ </p><p>
+ </p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p><a href="#join_procedure">Join
Procedure</a> - Join Procedure</p></li><li style="list-style-type:
circle"><p><a href="#token_messages">Token Messages for Control and
Election</a> - Token Passing</p></li><li style="list-style-type:
circle"><p><a href="#summarization_messages">Summarization Messages</a> -
Summarization Notification</p></li></ul></div><p>
+ </p><p>
+ Each of these procedures is important to keeping members of
the
+ distributed <span class="emphasis"><em>service</em></span>
functioning correctly. The
+ 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>
+ 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
+ <a href="#ls_ring">LS Ring File Structure</a>) files.
The inter-domain knowledge (i.e.
+ <span class="emphasis"><em>lower</em></span>) is used
first to establish a connection
+ to an already in progress grouping, or perhaps to start
a group that
+ may not exist yet.
+ </p><p>
+ A joining <span><strong
class="command">LS</strong></span> will continuously search the
+ <span class="emphasis"><em>LSRing</em></span>
information and send an
+ <span class="emphasis"><em>LSControl</em></span> message
to known <span><strong class="command">LS</strong></span>
+ instances with a <span
class="emphasis"><em>join</em></span>
+ <span class="emphasis"><em>eventType</em></span> (see <a
href="#ls_join">LS Join</a>)
+ until a successful response is seen. The <span><strong
class="command">LS</strong></span>
+ candidate will then search through the successful
+ <span class="emphasis"><em>LSControlResponse</em></span>
to this message and update its
+ <span class="emphasis"><em>LSRing</em></span>
information with the returned information.
+ This can mean updating the <span
class="emphasis"><em>active</em></span> and
+ <span class="emphasis"><em>leader</em></span> parameters
as well as adding new
+ <span><strong class="command">LS</strong></span>
instances. The first parameter is indicative of
+ the <span class="emphasis"><em>live-ness</em></span>
(i.e. were we successful in
+ contacting it recently), the second is used to indicate
who the
+ current <span class="emphasis"><em>leader</em></span> of
this group is. These dynamic
+ variables will be constantly changing.
+ </p><p>
+ For security purposes, it is necessary for the members
of the
+ <span class="emphasis"><em>LSRing</em></span> to know
that a new member has joined
+ without that member authenticating pairwise with each
other member of
+ the group. To accomplish this, the initially contacted
+ <span><strong class="command">LS</strong></span> will
request that the current group leader
+ initiate a token rotation to allow all members to update
their
+ <span class="emphasis"><em>LSRing</em></span> files thus
allowing instant recognition of
+ the new member.
+ </p><p>
+ After this initial warm-up the <span><strong
class="command">LS</strong></span> 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="#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>
+ 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
+ not fully enumerated for this description.
+ </p><p>
+ </p><div class="mediaobject"><img
src="images/ls_join1.png" /></div><p>
+ </p><p>
+ </p><div class="orderedlist"><ol type="1"><li><p>
+ <span><strong
class="command">LS1</strong></span> (candidate to the group) sends
+ <span
class="emphasis"><em>join</em></span>
+ (<span
class="emphasis"><em>http://perfsonar.net/services/LS/join</em></span>
+ eventType) request to <span><strong
class="command">LS7</strong></span> (non-functioning
+ member from some group). This request
will time out and
+ <span><strong
class="command">LS1</strong></span> must try again.
+ </p></li><li><p>
+ <span><strong
class="command">LS1</strong></span> sends another
+ <span
class="emphasis"><em>join</em></span>
+ (<span
class="emphasis"><em>http://perfsonar.net/services/LS/join</em></span>
+ eventType) request to <span><strong
class="command">LS2</strong></span> (member of the
+ group). <span><strong
class="command">LS2</strong></span> receives
+ <span
class="emphasis"><em>join</em></span> message from <span><strong
class="command">LS1</strong></span>
+ and decides whether to accept it or not.
Application of
+ security policy may occur here.
+ </p></li><li><p>
+ <span><strong
class="command">LS2</strong></span> accepts <span
class="emphasis"><em>join</em></span>
+ request from <span><strong
class="command">LS1</strong></span> and responds with success
+ code and <span
class="emphasis"><em>LSRing</em></span> content.
+ <span><strong
class="command">LS1</strong></span> will accept this, parse the response
+ and update it's own <span
class="emphasis"><em>LSRing</em></span>.
+ <span><strong
class="command">LS1</strong></span> will now wait (i.e. the length of
+ the token rotation time, see
+ <a
href="#rotation_time_computation">Rotation Time Computation</a>) until it is
time
+ to speak to the group.
+ </p></li><li><p>
+ <span><strong
class="command">LS2</strong></span> sends
+ <span
class="emphasis"><em>updateToken</em></span>
+ (<span
class="emphasis"><em>http://perfsonar.net/services/LS/updateToken</em></span>
+ eventType) to <span><strong
class="command">LS3</strong></span> (the leader of the
+ group). <span
class="emphasis"><em>updateToken</em></span> contains the
+ URL of <span><strong
class="command">LS1</strong></span>. <span><strong
class="command">LS3</strong></span> updates
+ its <span
class="emphasis"><em>LSRing</em></span> with URL of
+ <span><strong
class="command">LS1</strong></span>. The job of informing the remainder of
+ the group now belongs to the leader,
<span><strong class="command">LS3</strong></span>.
+ Note that if <span><strong
class="command">LS3</strong></span> was initially contacted
+ this step would be unnecessary.
+ </p></li><li><p>
+ <span><strong
class="command">LS3</strong></span> immediately sends
+ <span
class="emphasis"><em>updateToken</em></span>
+ (<span
class="emphasis"><em>http://perfsonar.net/services/LS/updateToken</em></span>)
+ to next peer from <span
class="emphasis"><em>LSRing</em></span>.
+ <span
class="emphasis"><em>updateToken</em></span> contains updated
+ <span
class="emphasis"><em>LSRing</em></span> information. This will be
+ exchanged between all peers. This
message will not be
+ marked as a duplicate or dropped by any
members of the group.
+ Note that additional tokens may still be
circulating through
+ the group before or after this token,
they will proceed as
+ usual as this particular token is
special for the
+ <span
class="emphasis"><em>control</em></span> of the service.
+ </p></li><li><p>
+ <span><strong
class="command">LS3</strong></span> also must send a
+ <span class="emphasis"><em>leader
election</em></span> token immediately to
+ trigger a new election cycle. This will
also exchanged
+ between all peers.
+ </p></li><li><p>
+ After full cycle of passing the
+ <span
class="emphasis"><em>updateToken</em></span>, <span><strong
class="command">LS3</strong></span>
+ receives the message again (identified
by
+ <span
class="emphasis"><em>messageIdRef</em></span>) and drops it immediately.
+ Now all group members have knowledge
about newly joined
+ <span><strong
class="command">LS1</strong></span>.
+ </p></li><li><p>
+ After a full cycle of leader election, a
new leader is
+ known. This new leader may start the
backup leader election.
+ See <a href="#leader_election">Leader
Election</a> for more details.
+ </p></li><li><p>
+ Regular token exchange and summarization
notification will
+ resume in time.
+ </p></li></ol></div><p>
+ </p><p>
+ Similarly, the initially contacted LS may choose to
ignore the
+ initial request from a candidate LS.
+ </p><p>
+ </p><div class="mediaobject"><img
src="images/ls_join2.png" /></div><p>
+ </p><p>
+ </p><div class="orderedlist"><ol type="1"><li><p>
+ <span><strong
class="command">LS1</strong></span> (candidate to the group) sends
+ <span
class="emphasis"><em>join</em></span>
+ (<span
class="emphasis"><em>http://perfsonar.net/services/LS/join</em></span>
+ eventType) request to <span><strong
class="command">LS2</strong></span> (member of the
+ group). <span><strong
class="command">LS2</strong></span> receives
+ <span
class="emphasis"><em>join</em></span> message from <span><strong
class="command">LS1</strong></span>
+ and decides whether to accept it or not.
Application of
+ security policy may occur here.
+ </p></li><li><p>
+ <span><strong
class="command">LS2</strong></span> rejects <span
class="emphasis"><em>join</em></span>
+ 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>
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
@@ -331,7 +458,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.2.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.3.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
@@ -418,7 +545,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.2.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.3.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
@@ -426,7 +553,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.2.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.3.2.1. Passing
Algorithm</h6></div></div></div><p>
The algorithm for token passing is described in the following
image and list.
</p><p>
@@ -470,7 +597,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.2.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.3.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
@@ -489,7 +616,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.3. 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.4. 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
@@ -1541,8 +1668,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="id861630"></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="id862043"></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="id861648"></a><p>[<abbr class="abbrev">XML</abbr>] <span class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id862061"></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-02 15:46:48 UTC (rev 317)
+++ trunk/nmwg/doc/dLS/dLS_spec.xml 2008-01-03 00:36:11 UTC (rev 318)
@@ -204,7 +204,8 @@
another LS if it is in the same scope, or one scope above it.)
For that reason, most references to other scopes
in the hierarchy
- will be made refering to <emphasis>lower</emphasis> and
+ will be made refering to <emphasis>lower</emphasis>,
+ <emphasis>current</emphasis> and
<emphasis>upper</emphasis> scopes and these references are made
relative to the specific <command>LS</command> instance. The
exception to this rule is for instances that end up in the very
@@ -280,277 +281,426 @@
</section>

<section id="system_scope" xreflabel="Scope Formation">
- <title>Scope Formation</title>
+ <title>Scope Formation</title>

- <para>
- The first aspect of this system is how to form the hierarchy of
- <command>LS</command> instances and subsequently organize the scopes.
- The simplest answer is that the highest scope be formed based on the
- domain name of the participating systems as mentioned in the previous
- examples. That would allow e.g. <emphasis>internet2.edu</emphasis>,
- <emphasis>geant2.net</emphasis>, and
<emphasis>pionier.gov.pl</emphasis>
- to potentially operate more than one <command>LS</command> instance
- inside their own domains (for performance and scalability.) As
- <command>LS</command> instances come online they will invoke
- <emphasis>bootstrapping</emphasis> procedures to find and join a
lower
- scoped group first. The <command>LS</command> that a service
contacts
- to register becomes the <emphasis>Home LS</emphasis> (
- <xref linkend="HLS" />) of that particular service.
- </para>
-
- <para>
- The scopes should be named based on URIs. This will allow a
- domain-level scope to take the form
- <ulink url="http://internet2.edu";>http://internet2.edu</ulink>,
- with subdomain scopes named
- <ulink
url="http://internet2.edu/foo";>http://internet2.edu/foo</ulink>,
- etc. The top-level scope can be called
- <ulink url="http://perfsonar.net";>http://perfsonar.net</ulink>
- with potential for geographic divisions later if necessary for
- performance (such as
- <ulink
url="http://eu.perfsonar.net";>http://eu.perfsonar.net</ulink>).
- </para>
-
- <para>
- The major algorithms used to form and maintain the structure of
- the <command>dLS</command>, no matter which scope we are talking
about,
- are as follows:
- </para>
-
- <para>
- <itemizedlist mark='opencircle'>
- <listitem>
- <para><xref linkend="join_procedure" /> - Join Procedure</para>
- </listitem>
- <listitem>
- <para><xref linkend="token_messages" /> - Token Passing</para>
- </listitem>
- <listitem>
- <para><xref linkend="summarization_messages" /> - Summarization
Notification</para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- Each of these procedures is important to keeping members of the
- distributed <emphasis>service</emphasis> functioning correctly. The
- algorithms will be presented in the frame of <command>HLS</command>
- instances communicating in a lower scope, but will be used in the
same
- manner for inter-domain communication as an upper scope as well.
- </para>
-
- <section id="join_procedure" xreflabel="Join Procedure">
- <title>Join Procedure</title>
-
<para>
- When an <command>LS</command> instance comes online it must have
some
- knowledge of potential peers (both inter and intra scope). This
- information is contained in <emphasis>LSRing</emphasis> (see
- <xref linkend="ls_ring" />) files. The inter-domain knowledge
(i.e.
- <emphasis>lower</emphasis>) is used first to establish a connection
- to an already in progress grouping, or perhaps to start a group
that
- may not exist yet.
+ Each <command>LS</command> instance holds registration and
+ summarization data relative to a specific
+ <emphasis>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>
-
- <para>
- A joining <command>LS</command> will continuously search the
- <emphasis>LSRing</emphasis> information and send an
- <emphasis>LSControl</emphasis> message to known
<command>LS</command>
- instances with a <emphasis>join</emphasis>
- <emphasis>eventType</emphasis> (see <xref linkend="ls_join" />)
- until a successful response is seen. The <command>LS</command>
- candidate will then search through the successful
- <emphasis>LSControlResponse</emphasis> to this message and update
its
- <emphasis>LSRing</emphasis> information with the returned
information.
- This can mean updating the <emphasis>active</emphasis> and
- <emphasis>leader</emphasis> parameters as well as adding new
- <command>LS</command> instances. The first parameter is
indicative of
- the <emphasis>live-ness</emphasis> (i.e. were we successful in
- contacting it recently), the second is used to indicate who the
- current <emphasis>leader</emphasis> of this group is. These
dynamic
- variables will be constantly changing.
- </para>

- <para>
- For security purposes, it is necessary for the members of the
- <emphasis>LSRing</emphasis> to know that a new member has joined
- without that member authenticating pairwise with each other member
of
- the group. To accomplish this, the initially contacted
- <command>LS</command> will request that the current group leader
- initiate a token rotation to allow all members to update their
- <emphasis>LSRing</emphasis> files thus allowing instant
recognition of
- the new member.
- </para>
-
- <para>
- After this initial warm-up the <command>LS</command> 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
- <xref linkend="token_messages" />).
- </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.
+ </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
+ complete URI specification so port numbers and protocol
+ specifications other than 'psls' are not allowed.) The full
+ string defines the current
+ <emphasis>Scope</emphasis>. Parent
<emphasis>Scopes</emphasis>
+ will be found by removing components of the
+ <emphasis>Scope</emphasis> while child
+ <emphasis>Scopes</emphasis> will be found by
+ concatenating additional components on.
+ </para>

- <section id="join_alg" xreflabel="Algorithm">
- <title>Algorithm</title>
+ <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>.
+ </listitem>

- <para>
- 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
- not fully enumerated for this description.
- </para>
-
- <para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/ls_join1.png"/>
- </imageobject>
- </mediaobject>
- </para>
+ <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>.
+ </listitem>

- <para>
- <orderedlist numeration="arabic">
- <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.
+ </listitem>
+ </orderedlist>
+ </para>
+
+ <para>
+ When configuring a new <command>LS</command> instance the
+ the following steps can be used to define child
+ <emphasis>Scopes</emphasis> of a given current
+ <emphasis>Scope</emphasis>:
+ <orderedlist numeration="arabic">
+ <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>
+
+ <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
+ domain, then it can append a new URI to the list.
+ </listitem>
+ </orderedlist>
+ </para>
+
+ <section id="scope_defaults" xreflabel="Scope Defaults">
+ <title>Scope Defaults</title>
<para>
- <command>LS1</command> (candidate to the group) sends
- <emphasis>join</emphasis>
- (<emphasis>http://perfsonar.net/services/LS/join</emphasis>
- eventType) request to <command>LS7</command>
(non-functioning
- member from some group). This request will time out and
- <command>LS1</command> must try again.
+ 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>
- </listitem>
- <listitem>
+
<para>
- <command>LS1</command> sends another
- <emphasis>join</emphasis>
- (<emphasis>http://perfsonar.net/services/LS/join</emphasis>
- eventType) request to <command>LS2</command> (member of the
- group). <command>LS2</command> receives
- <emphasis>join</emphasis> message from
<command>LS1</command>
- and decides whether to accept it or not. Application of
- security policy may occur here.
+ 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>
- </listitem>
- <listitem>
+
<para>
- <command>LS2</command> accepts <emphasis>join</emphasis>
- request from <command>LS1</command> and responds with
success
- code and <emphasis>LSRing</emphasis> content.
- <command>LS1</command> will accept this, parse the response
- and update it's own <emphasis>LSRing</emphasis>.
- <command>LS1</command> will now wait (i.e. the length of
- the token rotation time, see
- <xref linkend="rotation_time_computation" />) until it is
time
- to speak to the group.
+ 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>
- </listitem>
- <listitem>
+
<para>
- <command>LS2</command> sends
- <emphasis>updateToken</emphasis>
-
(<emphasis>http://perfsonar.net/services/LS/updateToken</emphasis>
- eventType) to <command>LS3</command> (the leader of the
- group). <emphasis>updateToken</emphasis> contains the
- URL of <command>LS1</command>. <command>LS3</command>
updates
- its <emphasis>LSRing</emphasis> with URL of
- <command>LS1</command>. The job of informing the
remainder of
- the group now belongs to the leader,
<command>LS3</command>.
- Note that if <command>LS3</command> was initially contacted
- this step would be unnecessary.
+ 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>
- </listitem>
- <listitem>
+
+ </section>
+ </section>
+
+ <section id="scope_algorithms" xreflabel="Scope Algorithms">
+ <title>Scope Algorithms</title>
+ <para>
+ The major algorithms used to form and maintain the structure
+ of the <command>dLS</command>, no matter which scope we are
+ talking about, are as follows:
+ </para>
+
+ <para>
+ <itemizedlist mark='opencircle'>
+ <listitem>
+ <para><xref linkend="join_procedure" /> - Join
Procedure</para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="token_messages" /> - Token
Passing</para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="summarization_messages" /> -
Summarization Notification</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ Each of these procedures is important to keeping members of
the
+ distributed <emphasis>service</emphasis> functioning
correctly. The
+ algorithms will be presented in the frame of
<command>HLS</command>
+ instances communicating in a lower scope, but will be used
in the same
+ manner for inter-domain communication as an upper scope as
well.
+ </para>
+
+ <section id="join_procedure" xreflabel="Join Procedure">
+ <title>Join Procedure</title>
+
<para>
- <command>LS3</command> immediately sends
- <emphasis>updateToken</emphasis>
-
(<emphasis>http://perfsonar.net/services/LS/updateToken</emphasis>)
- to next peer from <emphasis>LSRing</emphasis>.
- <emphasis>updateToken</emphasis> contains updated
- <emphasis>LSRing</emphasis> information. This will be
- exchanged between all peers. This message will not be
- marked as a duplicate or dropped by any members of the
group.
- Note that additional tokens may still be circulating
through
- the group before or after this token, they will proceed as
- usual as this particular token is special for the
- <emphasis>control</emphasis> of the service.
+ When an <command>LS</command> instance comes online it
must have some
+ knowledge of potential peers (both inter and intra
scope). This
+ information is contained in <emphasis>LSRing</emphasis>
(see
+ <xref linkend="ls_ring" />) files. The inter-domain
knowledge (i.e.
+ <emphasis>lower</emphasis>) is used first to establish a
connection
+ to an already in progress grouping, or perhaps to start
a group that
+ may not exist yet.
</para>
- </listitem>
- <listitem>
+
<para>
- <command>LS3</command> also must send a
- <emphasis>leader election</emphasis> token immediately to
- trigger a new election cycle. This will also exchanged
- between all peers.
+ A joining <command>LS</command> will continuously search
the
+ <emphasis>LSRing</emphasis> information and send an
+ <emphasis>LSControl</emphasis> message to known
<command>LS</command>
+ instances with a <emphasis>join</emphasis>
+ <emphasis>eventType</emphasis> (see <xref
linkend="ls_join" />)
+ until a successful response is seen. The
<command>LS</command>
+ candidate will then search through the successful
+ <emphasis>LSControlResponse</emphasis> to this message
and update its
+ <emphasis>LSRing</emphasis> information with the
returned information.
+ This can mean updating the <emphasis>active</emphasis>
and
+ <emphasis>leader</emphasis> parameters as well as adding
new
+ <command>LS</command> instances. The first parameter is
indicative of
+ the <emphasis>live-ness</emphasis> (i.e. were we
successful in
+ contacting it recently), the second is used to indicate
who the
+ current <emphasis>leader</emphasis> of this group is.
These dynamic
+ variables will be constantly changing.
</para>
- </listitem>
- <listitem>
+
<para>
- After full cycle of passing the
- <emphasis>updateToken</emphasis>, <command>LS3</command>
- receives the message again (identified by
- <emphasis>messageIdRef</emphasis>) and drops it
immediately.
- Now all group members have knowledge about newly joined
- <command>LS1</command>.
+ For security purposes, it is necessary for the members
of the
+ <emphasis>LSRing</emphasis> to know that a new member
has joined
+ without that member authenticating pairwise with each
other member of
+ the group. To accomplish this, the initially contacted
+ <command>LS</command> will request that the current
group leader
+ initiate a token rotation to allow all members to update
their
+ <emphasis>LSRing</emphasis> files thus allowing instant
recognition of
+ the new member.
</para>
- </listitem>
- <listitem>
+
<para>
- After a full cycle of leader election, a new leader is
- known. This new leader may start the backup leader
election.
- See <xref linkend="leader_election" /> for more details.
+ After this initial warm-up the <command>LS</command>
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
+ <xref linkend="token_messages" />).
</para>
- </listitem>
- <listitem>
- <para>
- Regular token exchange and summarization notification will
- resume in time.
- </para>
- </listitem>

- </orderedlist>
- </para>

- <para>
- Similarly, the initially contacted LS may choose to ignore the
- initial request from a candidate LS.
- </para>
+ <section id="join_alg" xreflabel="Algorithm">
+ <title>Algorithm</title>

- <para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/ls_join2.png"/>
- </imageobject>
- </mediaobject>
- </para>
-
- <para>
- <orderedlist numeration="arabic">
- <listitem>
- <para>
- <command>LS1</command> (candidate to the group) sends
- <emphasis>join</emphasis>
- (<emphasis>http://perfsonar.net/services/LS/join</emphasis>
- eventType) request to <command>LS2</command> (member of the
- group). <command>LS2</command> receives
- <emphasis>join</emphasis> message from
<command>LS1</command>
- and decides whether to accept it or not. Application of
- security policy may occur here.
- </para>
- </listitem>
- <listitem>
- <para>
- <command>LS2</command> rejects <emphasis>join</emphasis>
- request from <command>LS1</command> and responses with
proper
- error code
- </para>
- </listitem>
- </orderedlist>
- </para>
+ <para>
+ 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
+ not fully enumerated for this description.
+ </para>

-
+ <para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/ls_join1.png"/>
+ </imageobject>
+ </mediaobject>
+ </para>
+
+ <para>
+ <orderedlist numeration="arabic">
+ <listitem>
+ <para>
+ <command>LS1</command> (candidate to the
group) sends
+ <emphasis>join</emphasis>
+
(<emphasis>http://perfsonar.net/services/LS/join</emphasis>
+ eventType) request to
<command>LS7</command> (non-functioning
+ member from some group). This request
will time out and
+ <command>LS1</command> must try again.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>LS1</command> sends another
+ <emphasis>join</emphasis>
+
(<emphasis>http://perfsonar.net/services/LS/join</emphasis>
+ eventType) request to
<command>LS2</command> (member of the
+ group). <command>LS2</command> receives
+ <emphasis>join</emphasis> message from
<command>LS1</command>
+ and decides whether to accept it or not.
Application of
+ security policy may occur here.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>LS2</command> accepts
<emphasis>join</emphasis>
+ request from <command>LS1</command> and
responds with success
+ code and <emphasis>LSRing</emphasis>
content.
+ <command>LS1</command> will accept this,
parse the response
+ and update it's own
<emphasis>LSRing</emphasis>.
+ <command>LS1</command> will now wait
(i.e. the length of
+ the token rotation time, see
+ <xref
linkend="rotation_time_computation" />) until it is time
+ to speak to the group.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>LS2</command> sends
+ <emphasis>updateToken</emphasis>
+
(<emphasis>http://perfsonar.net/services/LS/updateToken</emphasis>
+ eventType) to <command>LS3</command>
(the leader of the
+ group).
<emphasis>updateToken</emphasis> contains the
+ URL of <command>LS1</command>.
<command>LS3</command> updates
+ its <emphasis>LSRing</emphasis> with URL
of
+ <command>LS1</command>. The job of
informing the remainder of
+ the group now belongs to the leader,
<command>LS3</command>.
+ Note that if <command>LS3</command> was
initially contacted
+ this step would be unnecessary.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>LS3</command> immediately sends
+ <emphasis>updateToken</emphasis>
+
(<emphasis>http://perfsonar.net/services/LS/updateToken</emphasis>)
+ to next peer from
<emphasis>LSRing</emphasis>.
+ <emphasis>updateToken</emphasis>
contains updated
+ <emphasis>LSRing</emphasis> information.
This will be
+ exchanged between all peers. This
message will not be
+ marked as a duplicate or dropped by any
members of the group.
+ Note that additional tokens may still be
circulating through
+ the group before or after this token,
they will proceed as
+ usual as this particular token is
special for the
+ <emphasis>control</emphasis> of the
service.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>LS3</command> also must send a
+ <emphasis>leader election</emphasis>
token immediately to
+ trigger a new election cycle. This will
also exchanged
+ between all peers.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ After full cycle of passing the
+ <emphasis>updateToken</emphasis>,
<command>LS3</command>
+ receives the message again (identified
by
+ <emphasis>messageIdRef</emphasis>) and
drops it immediately.
+ Now all group members have knowledge
about newly joined
+ <command>LS1</command>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ After a full cycle of leader election, a
new leader is
+ known. This new leader may start the
backup leader election.
+ See <xref linkend="leader_election" />
for more details.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Regular token exchange and summarization
notification will
+ resume in time.
+ </para>
+ </listitem>
+
+ </orderedlist>
+ </para>
+
+ <para>
+ Similarly, the initially contacted LS may choose to
ignore the
+ initial request from a candidate LS.
+ </para>
+
+ <para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/ls_join2.png"/>
+ </imageobject>
+ </mediaobject>
+ </para>
+
+ <para>
+ <orderedlist numeration="arabic">
+ <listitem>
+ <para>
+ <command>LS1</command> (candidate to the
group) sends
+ <emphasis>join</emphasis>
+
(<emphasis>http://perfsonar.net/services/LS/join</emphasis>
+ eventType) request to
<command>LS2</command> (member of the
+ group). <command>LS2</command> receives
+ <emphasis>join</emphasis> message from
<command>LS1</command>
+ and decides whether to accept it or not.
Application of
+ security policy may occur here.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>LS2</command> rejects
<emphasis>join</emphasis>
+ request from <command>LS1</command> and
responses with proper
+ error code
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+
+
+ </section>
+ </section>
</section>
- </section>

<section id="token_messages" xreflabel="Token Messages for Control and
Election">
<title>Token Messages for Control and Election</title>


  • nmwg: r318 - trunk/nmwg/doc/dLS, svnlog, 01/02/2008

Archive powered by MHonArc 2.6.16.

Top of Page