Skip to Content.
Sympa Menu

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

Subject: perfsonar development work

List archive

nmwg: r314 - trunk/nmwg/doc/dLS


Chronological Thread 
  • From:
  • To: ,
  • Subject: nmwg: r314 - trunk/nmwg/doc/dLS
  • Date: Thu, 20 Dec 2007 02:33:12 -0500
Author: boote
Date: 2007-12-20 02:33:12 -0500 (Thu, 20 Dec 2007)
New Revision: 314

Modified:
trunk/nmwg/doc/dLS/dLS_spec.html
trunk/nmwg/doc/dLS/dLS_spec.xml
Log:
Adding bootstrapping.

Cleaning up a bit of the scope discussion. (upper/lower confusion)



Modified: trunk/nmwg/doc/dLS/dLS_spec.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS_spec.html 2007-12-17 18:03:34 UTC (rev 313)
+++ trunk/nmwg/doc/dLS/dLS_spec.html 2007-12-20 07:33:12 UTC (rev 314)
@@ -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.0" /></head><body><div class="article" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h1 class="title"><a
id="id2478927"></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 cl
ass="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 h
ref="#leader_election">3.2.2.1. Leader Election</a></span></!
dt><dt><
span 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="#system_summarization">3.3.
Summarization</a></span></dt><dd><dl><dt><span class="section"><a
href="#system_summarization_lower">3.3.1. Lower
Scope</a></span></dt><dt><span class="section"><a
href="#system_summarization_upper">3.3.2. Upper
Scope</a></span></dt><dd><dl><dt><span class="section"><a
href="#system_summarization_upper_alg">3.3.2.1. IP Address
Algorithm</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#system_search">3.4. Search</a></span></dt><dd><dl><dt><span cl
ass="section"><a href="#system_search_discovery_phase">3.4.1. Discovery
Phase</a></span></dt><dd><dl><dt><span class="section"><a
href="#system_search_discovery_algorithm">3.4.1.1.
Algorithm</a></span></dt></dl></dd><dt><span class="section"><a
href="#system_search_metadata_query_phase">3.4.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></s
pan></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_messag
e_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:l
ang="en"><div class="titlepage"><div><div><h2 class="title" !
style="c
lear: 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="#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>
This document describes the
<span class="emphasis"><em>Distributed Lookup Service</em></span>
(<span><strong class="command">dLS</strong></span>)
- in the <a href="#id2532261">perfSONAR</a> system. This modification
extends
+ in the <a href="#id861630">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,87 +44,100 @@
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
- <span class="emphasis"><em>perfSONAR</em></span> service registers
with an
- <span><strong class="command">LS</strong></span>. 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
- 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="#lookup_info">Lookup Information</a>).
- </p><p>
- The idea is to move the metadata from a service-local
- <a href="#id2532279">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>)
- that handles the storage of data in native formats. While a
- service instance may support limited searching, this is not necessary
- as they should be focused on storing or gathering data and leave the
- lookup functionality to the <span><strong
class="command">LS</strong></span>. Possible exceptions
- when a client may need to contact a service directly are when
metadata
- rapidly changes, like the most recent data's timestamp and 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 should allow for multiple levels thus representing
splits
- of a hierarchy, although the basic example in this document will
revolve
- around only 2 of these levels. The authors realize it is impossible
to
- predict how the hierarchy of this service may split over time,
therefore
- we avoid using language that directly categorizes a group into a
- specific role. In general the two levels that define scope are
- <span class="emphasis"><em>lower</em></span> and <span
class="emphasis"><em>upper</em></span>.
- </p><p>
- To better define this classification consider an example
at a high
- level: inter-domain communication. It is natural to
assume that single
- domain will deploy an <span><strong
class="command">LS</strong></span> instance to manage deployed
- services. The true 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; further fragmentation by other factors such as
the
- <span class="emphasis"><em>top-level domain</em></span>
or geographical considerations
- are probable, just not of interest in this work. A
single domain may
- have multiple <span><strong
class="command">LS</strong></span> deployments; a representative
- <span class="emphasis"><em>leader</em></span> from this
set will represent the
- <span class="emphasis"><em>upper</em></span>
(intra-domain) scope and communicate with
- similar <span><strong class="command">LS</strong></span>
instances of other domains in this case.
- The actual registered services of the <span><strong
class="command">LS</strong></span> represent
- the <span class="emphasis"><em>lower</em></span> (local,
or in many cases inter-domain)
- scope.
- </p><p>
- The scoping designations are important to the next stage: data
- 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>. Although information
such as
- capacity or interface name are valuable when internal to a
domain, these
- variables do not represent common queries, perhaps posed by
- <span><strong class="command">NOC</strong></span> staff, that
could be asking something as simple
- as seeing utilization of a link. We propose a
- <span class="emphasis"><em>summarization</em></span> strategy
based on
- <span class="emphasis"><em>distance</em></span> from the source
that will distill the
- complete metadata into smaller and smaller sets as the
information is
- passed through the scope hierarchy.
- </p><p>
- 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
- <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.
- </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 step of information flow is 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
+ 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="#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
+ <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>)
+ that handles the storage of data in native formats. While a
+ service instance may support limited searching, this is not
+ necessary as they should be focused on storing or gathering data
+ and leave the lookup functionality to the <span><strong
class="command">LS</strong></span>.
+ However, a client may need to contact a service directly when
+ metadata rapidly changes, like the most recent data's timestamp
and
+ 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
+ <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
+ <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
+ <span class="emphasis"><em>top</em></span> scope, or at a very
+ <span class="emphasis"><em>bottom</em></span> scope. The <span
class="emphasis"><em>top</em></span>
+ scope represents the most summarized, but most overarching set
+ of discovery data available. The <span
class="emphasis"><em>bottom</em></span>
+ scope represents the most specific individual service
+ information available, but the least knowledge of the global
+ 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
+ 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.)
+ 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.
+ 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
+ <span class="emphasis"><em>top</em></span> (intra-domain) scope
and communicate with
+ similar <span><strong class="command">LS</strong></span>
instances of other domains in this
+ case.
+ </p><p>
+ The scoping designations are important to the next stage: data
+ 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>.
+ We specify a
+ <span class="emphasis"><em>summarization</em></span> strategy
based on
+ <span class="emphasis"><em>distance</em></span> from the source
that will distill the
+ 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,
+ 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
+ <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.
+ </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
@@ -163,7 +176,7 @@
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 domain). This
+ 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
@@ -482,7 +495,31 @@
message format for this exchange. It is left up to the
implementation when the summarization occurs (i.e. at message
send time, or also as a periodic event).
- </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="system_summarization"></a>3.3. Summarization</h3></div></div></div><p>
+ </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="bootstrapping"></a>3.3. Bootstrapping</h3></div></div></div><p>
+ Bootstrapping is the mechanism used by any
+ <span class="emphasis"><em>perfSONAR</em></span> service to find
the first
+ <span><strong class="command">LS</strong></span> instance. Once
any <span><strong class="command">LS</strong></span>
+ instance is found, the <a href="#system_search">Search</a>
+ mechanism can be used to find specific ones as required.
+ (For example, a new <span><strong
class="command">LS</strong></span> instance will need
+ to look for any current <span><strong
class="command">LS</strong></span> instances in the
+ same scope to determine if it should join an existing scope, or
+ if it should create a new one.)
+ </p><p>
+ The following steps should be done in
+ order to find an <span><strong
class="command">LS</strong></span>:
+ </p><div class="itemizedlist"><ul type="numbered"><li
style="list-style-type: numbered"><p>
+ Use an administratively defined <span><strong
class="command">LS</strong></span>
+ if it can be reached.
+ </p></li><li style="list-style-type: numbered"><p>
+ Use any <span><strong
class="command">LS</strong></span> instance that the
+ service has reached in the past. Services are
expected
+ to cache this information.
+ </p></li><li style="list-style-type: numbered"><p>
+ Contact the well known <span><strong
class="command">LS</strong></span> at
+ http://lsroot.perfsonar.net/.
+ </p></li></ul></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="system_summarization"></a>3.4. Summarization</h3></div></div></div><p>
It is the responsibility of the <span><strong
class="command">HLS</strong></span> to make summary
data about the all of the <span
class="emphasis"><em>perfSONAR</em></span> services it
knows of available to the larger enterprise and to draw relevant
@@ -521,7 +558,7 @@
example, thus involving only two scoped groups. Building upon the
basic ideas presented here, extension to multiple scopes will be
be presented in future work.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="system_summarization_lower"></a>3.3.1. Lower
Scope</h4></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="system_summarization_lower"></a>3.4.1. Lower
Scope</h4></div></div></div><p>
The lower scope summarization, described here as information
exchange
between <span><strong class="command">HLS</strong></span>
instances internal to a domain,
consists of simply extracting detailed information from the
metadata
@@ -574,7 +611,7 @@
expiration). When responding to queries for this information, the
<span><strong class="command">LS</strong></span> must indicate
whether or not it is
authoritative.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="system_summarization_upper"></a>3.3.2. Upper
Scope</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="system_summarization_upper"></a>3.4.2. Upper
Scope</h4></div></div></div><p>
A designated member of a given scope (often corresponding to an
organization) will be required to interact with other similar
<span><strong class="command">LS</strong></span>s (generally
representing other domains) in
@@ -614,7 +651,7 @@
summary output. Additional transformations, while aggressive, will
strive to preserve as much information as possible to remain
useful
during the search procedures.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="system_summarization_upper_alg"></a>3.3.2.1. IP Address
Algorithm</h5></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="system_summarization_upper_alg"></a>3.4.2.1. IP Address
Algorithm</h5></div></div></div><p>
To summarize a set of IP addresses we can build upon a common
structure for IP storage and lookup, the
<a href="http://en.wikipedia.org/wiki/Radix_tree";
target="_top">Radix (or
@@ -674,20 +711,25 @@
(CIDR) style, i.e. W.X.Y.Z/mask bits. There may be times when
this
address aggregation is manually specified and this is a
completely
viable interim solution.
- </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a
id="system_search"></a>3.4. Search</h3></div></div></div><p>
+ </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a
id="system_search"></a>3.5. Search</h3></div></div></div><p>
The search operation is obviously critical to the <span><strong
class="command">LS</strong></span>s
- function. It is envisioned that searching could take one of two
+ function. It is envisioned that searching will take two
major forms, iterative and recursive, analogous to those used in
DNS. This design will focus exclusively on iterative initially as
- the only method in the first versions of the <span><strong
class="command">dLS</strong></span>. The
+ the only method in the first versions of the <span><strong
class="command">dLS</strong></span>.
+ Recursive (and performance enhancements via caching) can
transparently
+ be added in later given the design of the client server protocol
+ interaction. The
key act when searching is to find what eventTypes exist for a
particular
topology element or set of topology elements.
</p><p>
As outlined above, the full data that services register to an
<span><strong class="command">LS</strong></span> is not expected to
leave the scope of that
- <span><strong class="command">LS</strong></span>. The information is
summarized before wider
+ <span><strong class="command">LS</strong></span> instance.
+ The information is summarized before wider
distribution. Therefore, a client needs to find an <span><strong
class="command">LS</strong></span>
- in the scope of the <span><strong
class="command">HLS</strong></span> to make queries about the
+ in the scope of the <span><strong
class="command">HLS</strong></span> to make the more
+ specific queries about the
complete metadata. Specifically, a client wishing to locate
information
might specify a topology element in a query to locate the
<span><strong class="command">LS</strong></span> instance (or
instances) that contain the relevant
@@ -695,7 +737,7 @@
act of searching is broken down into two distinct phases -
<a href="#system_search_discovery_phase">Discovery Phase</a> and
<a href="#system_search_metadata_query_phase">Metadata Query
Phase</a>.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="system_search_discovery_phase"></a>3.4.1. Discovery
Phase</h4></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="system_search_discovery_phase"></a>3.5.1. Discovery
Phase</h4></div></div></div><p>
The discovery phase is used to locate the set of Authoritative
<span><strong class="command">LS</strong></span> (or
<span><strong class="command">LS</strong></span>s) for a given
<span class="emphasis"><em>subject</em></span>/<span
class="emphasis"><em>eventType</em></span> tuple.
@@ -705,7 +747,7 @@
Either a specific API call and a pre-prepared query, or some
automatic
mechanism, must map the desired query into a query of the
Discovery
info-set (see <a href="#ls_discovery_message">LS Discovery
Message</a>)
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="system_search_discovery_algorithm"></a>3.4.1.1. Algorithm</h5></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="system_search_discovery_algorithm"></a>3.5.1.1. Algorithm</h5></div></div></div><p>
The discovery algorithm is as follows.
</p><p>
</p><div class="orderedlist"><ol type="1"><li><p>
@@ -776,7 +818,7 @@
<span><strong class="command">LS</strong></span> is
different, a discovery query should
be made to it.
</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="system_search_metadata_query_phase"></a>3.4.2. Metadata Query
Phase</h4></div></div></div><p>
+ </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="system_search_metadata_query_phase"></a>3.5.2. Metadata Query
Phase</h4></div></div></div><p>
The Metadata Query Phase with an individual <span><strong
class="command">LS</strong></span> is
the same as the query mechanism that is in place with the current
<span><strong class="command">LS</strong></span> implementations.
@@ -882,16 +924,15 @@

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a id="ls_ring"></a>4.3. LS
Ring File Structure</h3></div></div></div><p>
The <span><strong class="command">LSRing</strong></span> file
represents the
- <span class="emphasis"><em>state</em></span> of the <span><strong
class="command">LS</strong></span> cloud at either
- level of hierarchy (we avoid using the terms <span
class="emphasis"><em>global</em></span>
- and <span class="emphasis"><em>local</em></span> here since the
hierarchy may be much
- larger). This file must start with some static values, and
will be
- added to/deleted from as time goes on. As such implementations
must
- ensure that this file is under database control of some sort.
+ <span class="emphasis"><em>state</em></span> of the <span><strong
class="command">LS</strong></span> cloud at a
+ specific level of hierarchy. This file must start with some static
+ values, and will be added to/deleted from as time goes on.
+ As such implementations must ensure that this file is under
+ database control of some sort.
</p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="ls_ring_lower"></a>4.3.1. Lower Level</h4></div></div></div><p>
The <span class="emphasis"><em>lower</em></span> level represents
peer
<span><strong class="command">LS</strong></span> instances that
should represent the state within
- our domain (or other hierarchical split).
+ our scope (for example, a domain).
</p><pre class="programlisting">

&lt;nmwg:store type="LSRing-lower"&gt;
@@ -1500,8 +1541,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="id2532261"></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="id861630"></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="id2532279"></a><p>[<abbr class="abbrev">XML</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id861648"></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 2007-12-17 18:03:34 UTC (rev 313)
+++ trunk/nmwg/doc/dLS/dLS_spec.xml 2007-12-20 07:33:12 UTC (rev 314)
@@ -144,101 +144,114 @@
<title>System Specific Operation</title>

<section id="system_overview" xreflabel="Overview">
- <title>Overview</title>
+ <title>Overview</title>

- <para>
- The first step of information flow is when a
- <emphasis>perfSONAR</emphasis> service registers with an
- <command>LS</command>. The service should know the name of an
- <command>LS</command> via static configuration (the most common case
- for legacy deployments), or may learn through other advanced methods.
- A service registers a <emphasis>service metadata</emphasis> record
about
- itself and full metadata (i.e. containing all static measurement
- information such as subject, eventType(s), and any parameters, see
- <xref linkend="service_metadata" />) about stored data it has
knowledge
- of. Such a record is called Lookup Information (see
- <xref linkend="lookup_info" />).
- </para>
-
- <para>
- The idea is to move the metadata from a service-local
- <citation>XML</citation> data store to a specialized
- <command>LS</command> with additional searching capabilities. The
- <command>LS</command> consists of an XML database, (i.e.
- <xref linkend="Berkeley DB XML" /> or <xref linkend="eXist XML DB"
/>)
- that handles the storage of data in native formats. While a
- service instance may support limited searching, this is not necessary
- as they should be focused on storing or gathering data and leave the
- lookup functionality to the <command>LS</command>. Possible
exceptions
- when a client may need to contact a service directly are when
metadata
- rapidly changes, like the most recent data's timestamp and full
details
- of data stored in long-term archival
- <emphasis>Measurement Archives</emphasis> (<command>MA</command>s).
- </para>
-
- <para>
- The architecture of the <command>dLS</command> protocol assumes the
- existence of logical groups of <command>LS</command> instances. The
- architecture should allow for multiple levels thus representing
splits
- of a hierarchy, although the basic example in this document will
revolve
- around only 2 of these levels. The authors realize it is impossible
to
- predict how the hierarchy of this service may split over time,
therefore
- we avoid using language that directly categorizes a group into a
- specific role. In general the two levels that define scope are
- <emphasis>lower</emphasis> and <emphasis>upper</emphasis>.
- </para>
-
- <para>
- To better define this classification consider an example
at a high
- level: inter-domain communication. It is natural to
assume that single
- domain will deploy an <command>LS</command> instance to
manage deployed
- services. The true goal of
<emphasis>perfSONAR</emphasis> is to ease
- the detection of end to end performance issues
particularly across
- domain boundaries, therefore communication between domain
- <command>LS</command> instances is paramount. We assume
for this
- example that the <emphasis>top</emphasis> most level is
that of the
- domain; further fragmentation by other factors such as
the
- <emphasis>top-level domain</emphasis> or geographical
considerations
- are probable, just not of interest in this work. A
single domain may
- have multiple <command>LS</command> deployments; a
representative
- <emphasis>leader</emphasis> from this set will represent
the
- <emphasis>upper</emphasis> (intra-domain) scope and
communicate with
- similar <command>LS</command> instances of other domains
in this case.
- The actual registered services of the
<command>LS</command> represent
- the <emphasis>lower</emphasis> (local, or in many cases
inter-domain)
- scope.
- </para>
-
- <para>
- The scoping designations are important to the next stage: data
- 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 <emphasis>give me
- bandwidth data for host x</emphasis>. Although information
such as
- capacity or interface name are valuable when internal to a
domain, these
- variables do not represent common queries, perhaps posed by
- <command>NOC</command> staff, that could be asking something
as simple
- as seeing utilization of a link. We propose a
- <emphasis>summarization</emphasis> strategy based on
- <emphasis>distance</emphasis> from the source that will distill
the
- complete metadata into smaller and smaller sets as the
information is
- passed through the scope hierarchy.
- </para>
-
- <para>
- 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 <command>dLS</command>
framework,
- namely discovery and query. The first step is locating
- <emphasis>where</emphasis> information can be found. This
involves
- asking semi direct questions regarding the well defined network
topology
- in order to locate the <emphasis>vicinity</emphasis> of data.
The query
- phase will then ask more esoteric questions once it locates the
proper
- <command>LS</command> instances to ask. The discovery phase is
made
- possible through the process of summarization, while the query
phase
- remains similar to the current <command>LS</command>
functionality.
- </para>
+ <para>
+ The first step of information flow is when a general
+ <emphasis>perfSONAR</emphasis> service registers with an
+ <command>LS</command> instance. The service should know the
name of an
+ <command>LS</command> via static configuration (the most common
case
+ for legacy deployments), or may learn through other advanced
methods.
+ A service registers a <emphasis>service metadata</emphasis>
record about
+ itself and full metadata (i.e. containing all static measurement
+ information such as subject, eventType(s), and any parameters,
see
+ <xref linkend="service_metadata" />) about stored data it has
knowledge
+ of. Such a record is called Lookup Information (see
+ <xref linkend="lookup_info" />).
+ </para>

+ <para>
+ The idea is to move the metadata from a service-local
+ <citation>XML</citation> data store to a specialized
+ <command>LS</command> with additional searching capabilities.
The
+ <command>LS</command> consists of an XML database, (i.e.
+ <xref linkend="Berkeley DB XML" /> or <xref linkend="eXist XML
DB" />)
+ that handles the storage of data in native formats. While a
+ service instance may support limited searching, this is not
+ necessary as they should be focused on storing or gathering data
+ and leave the lookup functionality to the <command>LS</command>.
+ However, a client may need to contact a service directly when
+ metadata rapidly changes, like the most recent data's timestamp
and
+ full details of data stored in long-term archival
+ <emphasis>Measurement Archives</emphasis>
(<command>MA</command>s).
+ </para>
+
+ <para>
+ The architecture of the <command>dLS</command> protocol assumes
the
+ existence of logical groups of <command>LS</command> instances.
The
+ architecture allows for multiple levels thus representing splits
+ of a hierarchy. The model of interaction between any two specific
+ <command>LS</command> 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 <emphasis>lower</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
+ <emphasis>top</emphasis> scope, or at a very
+ <emphasis>bottom</emphasis> scope. The <emphasis>top</emphasis>
+ scope represents the most summarized, but most overarching set
+ of discovery data available. The <emphasis>bottom</emphasis>
+ scope represents the most specific individual service
+ information available, but the least knowledge of the global
+ discovery data set.
+ </para>
+
+ <para>
+ To better define this classification consider an example at a
high
+ level: inter-domain communication. It is natural to assume that
+ a single domain will deploy an <command>LS</command> instance to
+ manage deployed services. A goal of
<emphasis>perfSONAR</emphasis>
+ is to ease the detection of end to end performance issues
+ particularly across domain boundaries, therefore communication
+ between domain
+ <command>LS</command> instances is paramount. We assume for this
+ example that the <emphasis>top</emphasis> most level is that of
the
+ domain. (So, all domain-level <command>LS</command> instances
+ will have joined a common scope.)
+ A single domain will likely
+ have multiple <command>LS</command> 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.
+ In this example,
+ a <emphasis>leader</emphasis> from this set of domain
+ <command>LS</command> instances will represent the domain in the
+ <emphasis>top</emphasis> (intra-domain) scope and communicate
with
+ similar <command>LS</command> instances of other domains in this
+ case.
+ </para>
+
+ <para>
+ The scoping designations are important to the next stage: data
+ 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 <emphasis>give me
+ bandwidth data for host x</emphasis>.
+ We specify a
+ <emphasis>summarization</emphasis> strategy based on
+ <emphasis>distance</emphasis> from the source that will distill
the
+ complete metadata into smaller and smaller sets as the
information
+ is passed through the scope hierarchy. (From bottom to top.)
+ </para>
+
+ <para>
+ 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 <command>dLS</command>
framework,
+ namely discovery and query. The first step is locating
+ <emphasis>where</emphasis> information can be found. This
involves
+ asking semi direct questions regarding the well defined network
topology
+ in order to locate the <emphasis>vicinity</emphasis> of data.
The query
+ phase will then ask more esoteric questions once it locates the
proper
+ <command>LS</command> instances to ask. The discovery phase is
made
+ possible through the process of summarization, while the query
phase
+ remains similar to the current <command>LS</command>
functionality.
+ </para>
+
</section>

<section id="system_scope" xreflabel="Scope Formation">
@@ -306,7 +319,7 @@

<para>
When an <command>LS</command> instance comes online it must have
some
- knowledge of potential peers (both inter and intra domain). This
+ 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
@@ -810,6 +823,47 @@

</section>

+ <section id="bootstrapping" xreflabel="Bootstrapping">
+ <title>Bootstrapping</title>
+
+ <para>
+ Bootstrapping is the mechanism used by any
+ <emphasis>perfSONAR</emphasis> service to find the first
+ <command>LS</command> instance. Once any <command>LS</command>
+ instance is found, the <xref linkend="system_search" />
+ mechanism can be used to find specific ones as required.
+ (For example, a new <command>LS</command> instance will need
+ to look for any current <command>LS</command> instances in the
+ same scope to determine if it should join an existing scope, or
+ if it should create a new one.)
+ </para>
+ <para>
+ The following steps should be done in
+ order to find an <command>LS</command>:
+ <itemizedlist mark='numbered'>
+ <listitem>
+ <para>
+ Use an administratively defined <command>LS</command>
+ if it can be reached.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Use any <command>LS</command> instance that the
+ service has reached in the past. Services are
expected
+ to cache this information.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Contact the well known <command>LS</command> at
+ http://lsroot.perfsonar.net/.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
<section id="system_summarization" xreflabel="Summarization">
<title>Summarization</title>

@@ -1100,10 +1154,13 @@

<para>
The search operation is obviously critical to the
<command>LS</command>s
- function. It is envisioned that searching could take one of two
+ function. It is envisioned that searching will take two
major forms, iterative and recursive, analogous to those used in
DNS. This design will focus exclusively on iterative initially as
- the only method in the first versions of the <command>dLS</command>.
The
+ the only method in the first versions of the <command>dLS</command>.
+ Recursive (and performance enhancements via caching) can
transparently
+ be added in later given the design of the client server protocol
+ interaction. The
key act when searching is to find what eventTypes exist for a
particular
topology element or set of topology elements.
</para>
@@ -1111,9 +1168,11 @@
<para>
As outlined above, the full data that services register to an
<command>LS</command> is not expected to leave the scope of that
- <command>LS</command>. The information is summarized before wider
+ <command>LS</command> instance.
+ The information is summarized before wider
distribution. Therefore, a client needs to find an
<command>LS</command>
- in the scope of the <command>HLS</command> to make queries about the
+ in the scope of the <command>HLS</command> to make the more
+ specific queries about the
complete metadata. Specifically, a client wishing to locate
information
might specify a topology element in a query to locate the
<command>LS</command> instance (or instances) that contain the
relevant
@@ -1406,12 +1465,11 @@

<para>
The <command>LSRing</command> file represents the
- <emphasis>state</emphasis> of the <command>LS</command> cloud at
either
- level of hierarchy (we avoid using the terms
<emphasis>global</emphasis>
- and <emphasis>local</emphasis> here since the hierarchy may be
much
- larger). This file must start with some static values, and
will be
- added to/deleted from as time goes on. As such implementations
must
- ensure that this file is under database control of some sort.
+ <emphasis>state</emphasis> of the <command>LS</command> cloud at a
+ specific level of hierarchy. This file must start with some static
+ values, and will be added to/deleted from as time goes on.
+ As such implementations must ensure that this file is under
+ database control of some sort.
</para>

<section id="ls_ring_lower" xreflabel="Lower Level">
@@ -1420,7 +1478,7 @@
<para>
The <emphasis>lower</emphasis> level represents peer
<command>LS</command> instances that should represent the state
within
- our domain (or other hierarchical split).
+ our scope (for example, a domain).
</para>

<programlisting>


  • nmwg: r314 - trunk/nmwg/doc/dLS, svnlog, 12/20/2007

Archive powered by MHonArc 2.6.16.

Top of Page