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

Subject: perfsonar development work

List archive

nmwg: r336 - trunk/nmwg/doc/dLS

From:
To: ,
Subject: nmwg: r336 - trunk/nmwg/doc/dLS
Date: Fri, 4 Apr 2008 06:25:26 -0400

Author: mac
Date: 2008-04-04 06:25:26 -0400 (Fri, 04 Apr 2008)
New Revision: 336

Modified:
trunk/nmwg/doc/dLS/dLS_spec.html
trunk/nmwg/doc/dLS/dLS_spec_1.html
Log:
HTML generated

Modified: trunk/nmwg/doc/dLS/dLS_spec.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS_spec.html 2008-03-22 06:25:49 UTC (rev 335)
+++ trunk/nmwg/doc/dLS/dLS_spec.html 2008-04-04 10:25:26 UTC (rev 336)
@@ -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="id824766"></a>Distributed Lookup Service (dLS) in the perfSONAR
Framework</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author">J. Boote</h3></div><div class="author"><h3
class="author">M. Glowiak</h3></div><div class="author"><h3
class="author">M. Swany</h3></div><div class="author"><h3
class="author">J. Zurawski</h3></div></div></div><div>Copyright © 2006, 2007, 2008 Internet2, Poznan Supercomputing
and Networking Center, University of Delaware</div></div><hr /></div><div
class="toc">Table of Contents<dl><dt><a
href="#changes">1. Document Changes</a></dt><dt><a href="#introduction">2.
Introduction</a></dt><dt><a
href="#system_specific_operation">3. System Specific
Operation</a></dt><dd><dl><dt><a
href="#system_overview">3.1. Overview</a></dt><dt><a href="#system_scope">3.2. Scope
Formation</a></dt><dd><dl><dt><a
href="#scope_specification">3.2.1. Scope
Specification</a></dt><dt><a
href="#scope_hierarchy">3.2.2. Scope Hierarchy</a></dt><dt><a href="#scope_defaults">3.2.3. Scope
Defaults</a></dt><dt><a
href="#scope_algorithms">3
.2.4. Scope Algorithms</a></dt><dd><dl><dt><a href="#join_procedure">3.2.4.1. Join
Procedure</a></dt><dd><dl><dt><a
href="#join_alg">3.2.4.1.1.
Algorithm</a></dt></dl></dd></dl></dd><dt><a
href="#token_messages">3.2.5. Token Messages for Control and
Election</a></dt><dd><dl><dt><a
href="#leader_election">3.2.5.1. Leader Election</a></dt><dt><a href="#registration_control">3.2.5.2. Registration
Control</a></dt><dd><dl><dt><a
href="#passing_algorithm">3.2.5.2.1. Passing
Algorithm</a></dt><dt><a
href="#rotation_time_computation">3.2.5.2.2. Rotation Time
Computation</a></dt></dl></dd></dl></dd><dt><a
href="#summarization_messages">3.2.6. Summarization
Messages</a></dt></dl></dd><dt><a
href="#bootstrapping">3.3. Bootstrapping</a></dt><dt><a href="#system_summariz
ation">3.4. Summarization</a></dt><dd><dl><dt><a href="#system_summarization_lower">3.4.1. Lower
Scope</a></dt><dt><a
href="#system_summarization_upper">3.4.2. Upper
Scope</a></dt><dd><dl><dt><a
href="#system_summarization_upper_alg">3.4.2.1. IP Address
Algorithm</a></dt></dl></dd></dl></dd><dt><a
href="#system_search">3.5. Search</a></dt><dd><dl><dt><a href="#system_search_discovery_phase">3.5.1. Discovery
Phase</a></dt><dd><dl><dt><a
href="#system_search_discovery_algorithm">3.5.1.1.
Algorithm</a></dt></dl></dd><dt><a
href="#system_search_metadata_query_phase">3.5.2. Metadata Query
Phase</a></dt></dl></dd></dl></dd><dt><a
href="#structures_and_messages">4. Structures and
Messages</a></dt><dd><dl><dt><a href="#service
_metadata">4.1. Service Metadata Example</a></dt><dt>!
<a href="#lookup_info">4.2. Lookup
Information</a></dt><dt><a href="#ls_ring">4.3.
LS Ring File Structure</a></dt><dd><dl><dt><a
href="#ls_ring_lower">4.3.1. Lower Level</a></dt><dt><a href="#ls_ring_upper">4.3.2. Upper
Level</a></dt></dl></dd><dt><a
href="#ls_join">4.4. LS Join</a></dt><dd><dl><dt><a href="#ls_join_request">4.4.1.
Request</a></dt><dt><a
href="#ls_join_response">4.4.2. Response</a></dt></dl></dd><dt><a href="#ls_token_message">4.5. LS Token
Message</a></dt><dd><dl><dt><a
href="#ls_token_message_request">4.5.1. Request</a></dt><dt><a href="#ls_token_message_response">4.5.2.
Response</a></dt></dl></dd><dt><a
href="#ls_summary_message">4.6. LS Summary Message</a></dt><dd><dl><dt><a
href="#ls_summary_message_upper">4.6.1.
Upper</a></dt><dd><dl><dt><a
href="#ls_summary_message_upper_request">4.6.1.1.
Request</a></dt><dt><a
href="#ls_summary_message_upper_response">4.6.1.2.
Response</a></dt></dl></dd><dt><a
href="#ls_summary_message_lower">4.6.2.
Lower</a></dt><dd><dl><dt><a
href="#ls_summary_message_lower_request">4.6.2.1.
Request</a></dt><dt><a
href="#ls_summary_message_lower_response">4.6.2.2.
Response</a></dt></dl></dd></dl></dd><dt><a
href="#ls_leader_message">4.7. LS Leader
Message</a></dt><dd><dl><dt><a
href="#ls_leader_message_request">4.7.1. Request</a></dt><dt><a href="#ls_leader_message_response">4.7.2.
Response</a></dt></dl></dd><dt><a href
="#ls_discovery_message">4.8. LS Discovery Message</a></span!
></dt><d
d><dl><dt><a
href="#ls_discovery_message_request">4.8.1. Request</a></dt><dt><a href="#ls_discovery_message_response">4.8.2.
Response</a></dt></dl></dd></dl></dd><dt><a
href="#glossary">Terms</a></dt><dt><a
href="#bibliography">References</a></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>Table 1. Change Log<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><tr><td align="left">1.0</td><td align="left">1/7/2008</td><td
align="left">Addition/Correction of scope diagrams</td><td align="left">J.
Zurawski</td></tr></tbody></table></div></div> </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>
+<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.72.0" /></head><body><div class="article" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h1 class="title"><a
id="id2486774"></a>Distributed Lookup Service (dLS) in the perfSONAR
Framework</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author">J. Boote</h3></div><div class="author"><h3
class="author">M. Glowiak</h3></div><div class="author"><h3
class="author">M. Swany</h3></div><div class="author"><h3
class="author">J. Zurawski</h3></div></div></div><div>Copyright © 2006, 2007, 2008 Internet2, Poznan
Supercomputing and Networking Center, University of
Delaware</div></div><hr /></div><div class="toc">Table of
Contents<dl><dt><a href="#changes">1. Document
Changes</a></dt><dt><a href="#introduction">2.
Introduction</a></dt><dt><a
href="#system_specific_operation">3. System Specific
Operation</a></dt><dd><dl><dt><a
href="#system_overview">3.1. Overview</a></dt><dt><a href="#system_scope">3.2. Scope
Formation</a></dt><dd><dl><dt><a
href="#scope_specification">3.2.1. Scope
Specification</a></dt><dt><a
href="#scope_hierarchy">3.2.2. Scope Hierarchy</a></dt><dt><a href="#scope_defaults">3.2.3. Scope
Defaults</a></dt><dt><a href="#scope_algorithms">
3.2.4. Scope Algorithms</a></dt><dd><dl><dt><a href="#join_procedure">3.2.4.1. Join
Procedure</a></dt><dd><dl><dt><a
href="#join_alg">3.2.4.1.1.
Algorithm</a></dt></dl></dd></dl></dd><dt><a
href="#token_messages">3.2.5. Token Messages for Control and
Election</a></dt><dd><dl><dt><a
href="#leader_election">3.2.5.1. Leader Election</a></dt><dt><a href="#registration_control">3.2.5.2. Registration
Control</a></dt><dd><dl><dt><a
href="#passing_algorithm">3.2.5.2.1. Passing
Algorithm</a></dt><dt><a
href="#rotation_time_computation">3.2.5.2.2. Rotation Time
Computation</a></dt></dl></dd></dl></dd><dt><a
href="#summarization_messages">3.2.6. Summarization
Messages</a></dt></dl></dd><dt><a
href="#bootstrapping">3.3. Bootstrapping</a></dt><dt><a href="#system_summari
zation">3.4. Summarization</a></dt><dd><dl><dt><a href="#system_summarization_lower">3.4.1. Lower
Scope</a></dt><dt><a
href="#system_summarization_upper">3.4.2. Upper
Scope</a></dt><dd><dl><dt><a
href="#system_summarization_upper_alg">3.4.2.1. IP Address
Algorithm</a></dt></dl></dd></dl></dd><dt><a
href="#system_search">3.5. Search</a></dt><dd><dl><dt><a href="#system_search_discovery_phase">3.5.1. Discovery
Phase</a></dt><dd><dl><dt><a
href="#system_search_discovery_algorithm">3.5.1.1.
Algorithm</a></dt></dl></dd><dt><a
href="#system_search_metadata_query_phase">3.5.2. Metadata Query
Phase</a></dt></dl></dd></dl></dd><dt><a
href="#structures_and_messages">4. Structures and
Messages</a></dt><dd><dl><dt><a href="#servic
e_metadata">4.1. Service Metadata Example</a></dt><dt!
><a href="#lookup_info">4.2. Lookup
Information</a></dt><dt><a href="#ls_ring">4.3.
LS Ring File Structure</a></dt><dd><dl><dt><a
href="#ls_ring_lower">4.3.1. Lower Level</a></dt><dt><a href="#ls_ring_upper">4.3.2. Upper
Level</a></dt></dl></dd><dt><a
href="#ls_join">4.4. LS Join</a></dt><dd><dl><dt><a href="#ls_join_request">4.4.1.
Request</a></dt><dt><a
href="#ls_join_response">4.4.2. Response</a></dt></dl></dd><dt><a href="#ls_token_message">4.5. LS Token
Message</a></dt><dd><dl><dt><a
href="#ls_token_message_request">4.5.1. Request</a></dt><dt><a href="#ls_token_message_response">4.5.2.
Response</a></dt></dl></dd><dt><a
href="#ls_summary_message">4.6. LS Summary Message</a>
</dt><dd><dl><dt><a
href="#ls_summary_message_upper">4.6.1.
Upper</a></dt><dd><dl><dt><a
href="#ls_summary_message_upper_request">4.6.1.1.
Request</a></dt><dt><a
href="#ls_summary_message_upper_response">4.6.1.2.
Response</a></dt></dl></dd><dt><a
href="#ls_summary_message_lower">4.6.2.
Lower</a></dt><dd><dl><dt><a
href="#ls_summary_message_lower_request">4.6.2.1.
Request</a></dt><dt><a
href="#ls_summary_message_lower_response">4.6.2.2.
Response</a></dt></dl></dd></dl></dd><dt><a
href="#ls_leader_message">4.7. LS Leader
Message</a></dt><dd><dl><dt><a
href="#ls_leader_message_request">4.7.1. Request</a></dt><dt><a href="#ls_leader_message_response">4.7.2.
Response</a></dt></dl></dd><dt><a hre
f="#ls_discovery_message">4.8. LS Discovery Message</a></spa!
n></dt><
dd><dl><dt><a
href="#ls_discovery_message_request">4.8.1. Request</a></dt><dt><a href="#ls_discovery_message_response">4.8.2.
Response</a></dt></dl></dd></dl></dd><dt><a
href="#glossary">Terms</a></dt><dt><a
href="#bibliography">References</a></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>Table 1. Change Log<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">Initia
l 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><tr><td align="left">1.0</td><td align="left">1/7/2008</td><td
align="left">Addition/Correction of scope diagrams</td><td align="left">J.
Zurawski</td></tr></tbody></table></div></div> </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>
This document describes the
Distributed Lookup Service
(dLS)
- in the <a href="#id905683">perfSONAR</a> system. This modification
extends
+ in the [<a href="#id2540754">perfSONAR</a>] system. This modification extends
the basic Lookup Service
(LS)
functionality that has been present in the system for some time. The
basic LS supports the storage and querying of
@@ -61,15 +61,15 @@
metadata 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
+ <a href="#service_metadata" title="4.1. Service Metadata
Example">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>).
+ <a href="#lookup_info" title="4.2. Lookup Information">Lookup
Information</a>).

The idea is to move the metadata from a service-local
- <a href="#id905701">XML</a> data store to a specialized
+ [<a href="#id2540773">XML</a>]
data store to a specialized
LS with additional
searching capabilities. The
LS 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>)
+ <a href="#Berkeley DB XML" title="Berkeley DB XML"></a> or <a
href="#eXist XML DB" title="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
@@ -356,7 +356,8 @@
The default Scope
SHOULD be
determined by appending a URI
with the fully qualified hostname of the host running the
- LS to the
global ls.perfsonar.net domain
+ LS to the
global
+ perfsonar.net domain
that will be supported by the perfSONAR consortium.
For example,
a new LS
started on rnp.br would
@@ -405,7 +406,7 @@
based upon continents or countries. This optimizations
can be added in after the fact, without changing
Scope
specifications for already
- deployed LS
instances. (Already
+ deployed LS
instances. Already
deployed LS
instances would simply
jump over the geographic Scope
directly to the root Scope. This
@@ -416,7 +417,7 @@
of the dLS, no
matter which scope we are
talking about, are as follows:

- <div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><a href="#join_procedure">Join
Procedure</a> - Join Procedure</li><li style="list-style-type:
circle"><a href="#token_messages">Token Messages for Control and
Election</a> - Token Passing</li><li style="list-style-type:
circle"><a href="#summarization_messages">Summarization Messages</a> -
Summarization Notification</li></ul></div>
+ <div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><a href="#join_procedure"
title="3.2.4.1. Join Procedure">Join Procedure</a> - Join
Procedure</li><li style="list-style-type: circle"><a
href="#token_messages" title="3.2.5. Token Messages for Control and
Election">Token Messages for Control and Election</a> - Token
Passing</li><li style="list-style-type: circle"><a
href="#summarization_messages" title="3.2.6. Summarization
Messages">Summarization Messages</a> - Summarization
Notification</li></ul></div>

Each of these procedures is important to keeping members of
the
distributed service
functioning correctly. The
@@ -427,7 +428,7 @@
When an LS
instance comes online it must have some
knowledge of potential peers (both inter and intra
scope). This
information is contained in LSRing (see
- <a href="#ls_ring">LS Ring File Structure</a>) files.
The inter-domain knowledge (i.e.
+ <a href="#ls_ring" title="4.3. LS Ring File
Structure">LS Ring File Structure</a>) files. The inter-domain knowledge
(i.e.
lower) is used
first to establish a connection
to an already in progress grouping, or perhaps to start
a group that
may not exist yet.
@@ -436,7 +437,7 @@
LSRing
information and send an
LSControl message
to known LS
instances with a join
- eventType (see <a
href="#ls_join">LS Join</a>)
+ eventType (see <a
href="#ls_join" title="4.4. LS Join">LS Join</a>)
until a successful response is seen. The LS
candidate will then search through the successful
LSControlResponse
to this message and update its
@@ -461,7 +462,7 @@
After this initial warm-up the LS will observe the
rules of token etiquette and remain silent until it is
contacted with
a token, or it has not seen one in a very long time (see
- <a href="#token_messages">Token Messages for Control and
Election</a>).
+ <a href="#token_messages" title="3.2.5. Token Messages
for Control and Election">Token Messages for Control and Election</a>).
<div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="join_alg"></a>3.2.4.1.1. Algorithm</h6></div></div></div>
The algorithm for joining a logical group works as
follows. Some
steps have been simplified for the sake of the
diagram. Additional
@@ -494,7 +495,7 @@
and update it's own LSRing.
LS1 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
+ <a href="#rotation_time_computation"
title="3.2.5.2.2. Rotation Time Computation">Rotation Time Computation</a>)
until it is time
to speak to the group.
</li><li>
LS2 sends
@@ -536,7 +537,7 @@
</li><li>
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.
+ See <a href="#leader_election"
title="3.2.5.1. Leader Election">Leader Election</a> for more details.
</li><li>
Regular token exchange and summarization
notification will
resume in time.
@@ -564,14 +565,14 @@
</div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="token_messages"></a>3.2.5. Token Messages for Control and
Election</h4></div></div></div>
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
- <a href="#registration_control">Registration Control</a>. A
leader is necessary to
+ used for two purposes: <a href="#leader_election"
title="3.2.5.1. Leader Election">Leader Election</a> and
+ <a href="#registration_control" title="3.2.5.2. Registration
Control">Registration Control</a>. A leader is necessary to
circulate group updates, to start tokens to initiate registration,
and
to represent a given scope in an upper scope.

The token is an
LSControlMessage (see
- <a href="#ls_token_message">LS Token Message</a>) meant to be
passed around an
+ <a href="#ls_token_message" title="4.5. LS Token Message">LS Token
Message</a>) meant to be passed around an
LSRing to the
various members in some order. There
are various criteria that can be used in deciding how to order the
group so that everyone can predict where the token is, when they
might
@@ -610,7 +611,7 @@
mechanism, initiated by the current leader, with the current
leader
excluded. The Leader and
Vice-leader LS instances
- should exchange messages (see <a href="#ls_leader_message">LS
Leader Message</a>)
+ should exchange messages (see <a href="#ls_leader_message"
title="4.7. LS Leader Message">LS Leader Message</a>)
periodically to ensure that in the event of a failure the lower
level will still maintain a cached copy of the information at the
upper level. It should be noted that whenever a the
@@ -671,8 +672,8 @@
The token can be viewed as permission
to talk
and permits the holding LS to send its summary
information to all other available LS instances
- (see <a href="#ls_summary_message_lower">Lower</a> and
- <a href="#ls_summary_message_upper">Upper</a>). The responses
will
+ (see <a href="#ls_summary_message_lower"
title="4.6.2. Lower">Lower</a> and
+ <a href="#ls_summary_message_upper"
title="4.6.1. Upper">Upper</a>). The responses will
be parsed to get any useful updated information about current
dLS cloud state.
<div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="passing_algorithm"></a>3.2.5.2.1. Passing
Algorithm</h6></div></div></div>
@@ -702,7 +703,7 @@
with any new service info.
</li><li>
LS1 waits
- (see <a href="#rotation_time_computation">Rotation Time
Computation</a>).
+ (see <a href="#rotation_time_computation"
title="3.2.5.2.2. Rotation Time Computation">Rotation Time Computation</a>).
</li><li>
LS1 sends
token to next
LS
(LS2) from the
@@ -713,10 +714,10 @@

Each note in the local group is responsible for monitoring the
state of the token. If the internal timer (see
- <a href="#rotation_time_computation">Rotation Time
Computation</a>) expires without
+ <a href="#rotation_time_computation"
title="3.2.5.2.2. Rotation Time Computation">Rotation Time Computation</a>)
expires without
seeing a token a new token should be generated. If a token is
seen too soon (see
- <a href="#rotation_time_computation">Rotation Time
Computation</a>) it should be
+ <a href="#rotation_time_computation"
title="3.2.5.2.2. 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.
</div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="rotation_time_computation"></a>3.2.5.2.2. Rotation Time
Computation</h6></div></div></div>
@@ -739,8 +740,8 @@
initiated. Conversely if a token is seen too early (less than
half the calculated time) the token should be dropped.
</div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="summarization_messages"></a>3.2.6. Summarization
Messages</h4></div></div></div>
- <a href="#system_summarization_lower">Lower Scope</a> and
- <a href="#system_summarization_upper">Upper Scope</a> contain
examples of the
+ <a href="#system_summarization_lower" title="3.4.1. Lower
Scope">Lower Scope</a> and
+ <a href="#system_summarization_upper" title="3.4.2. Upper
Scope">Upper Scope</a> contain examples of the
message format for this exchange. It is left up to the
implementation when the summarization occurs (i.e. at message
send time, or also as a periodic event).
@@ -748,7 +749,7 @@
Bootstrapping is the mechanism used by any
perfSONAR service to find
the first
LS instance. Once
any LS
- instance is found, the <a href="#system_search">Search</a>
+ instance is found, the <a href="#system_search"
title="3.5. Search">Search</a>
mechanism can be used to find specific ones as required.
(For example, a new LS instance will need
to look for any current LS instances in the
@@ -784,7 +785,7 @@
LS cloud.

We start by making an observation that summarization is best based on
- scope (see also <a href="#system_scope">Scope Formation</a>). Simply
put, this
+ scope (see also <a href="#system_scope" title="3.2. Scope
Formation">Scope Formation</a>). Simply put, this
means that we should attempt to summarize more the
farther away from the
source that we get. This creates a smaller data set that travels
@@ -840,7 +841,7 @@
information to other LS instances to propagate the
appropriate information. Information exchange will be handled
using a
taking turns protocol such
as
- <a href="#Token Ring">Token Ring</a>. The holder of the token
will then
+ <a href="#Token Ring" title="Token Ring"></a>. The holder of the
token will then
perform the information exchange to other known instances. The
following diagram illustrates the exchange between
LS deployments.
@@ -866,7 +867,7 @@
LSs (generally
representing other domains) in
order to form a higher-level, or upper, scope.
The mechanics of how we learn who is the designated leader are
- discussed in <a href="#leader_election">Leader Election</a>. The
leader from
+ discussed in <a href="#leader_election" title="3.2.5.1. Leader
Election">Leader Election</a>. The leader from
each of the first layers of this hierarchy (and the designated
backup)
will be responsible for examining each member's summary information
and building a summarization/aggregation that represents the
contents
@@ -881,11 +882,11 @@
Summarization will be performed using specialized summary
algorithm.
Topology information such as IP addresses will be summarized using
algorithms based on Radix Tree (see
- <a href="#system_summarization_upper_alg">IP Address
Algorithm</a>).
+ <a href="#system_summarization_upper_alg" title="3.4.2.1. IP
Address Algorithm">IP Address Algorithm</a>).

Other information can be summarized in an easier manner through the
use of either Extensible Stylesheet Language Transformation
- (<a href="#XSLT">XSLT</a>) documents or the <a
href="#XQuery">XQuery</a>
+ (<a href="#XSLT" title="XSLT"></a>) documents or the <a
href="#XQuery" title="XQuery"></a>
language as discussed in the previous section.
These mechanisms will take into account the XML elements that
represent the network topology currently used in metadata subjects
as
@@ -895,8 +896,8 @@
service summary that
represents the breadth of
the original input. This consists minimally of IP networks and
addresses and the eventTypes which are stored and can be generated.
- See <a href="#ls_summary_message_lower">Lower</a> or
- <a href="#ls_summary_message_upper">Upper</a> for a mock-up of the
+ See <a href="#ls_summary_message_lower"
title="4.6.2. Lower">Lower</a> or
+ <a href="#ls_summary_message_upper" title="4.6.1. Upper">Upper</a>
for a mock-up of the
summary output. Additional transformations, while aggressive, will
strive to preserve as much information as possible to remain
useful
during the search procedures.
@@ -984,8 +985,8 @@
LS instance (or
instances) that contain the relevant
details. This separation of full data and summary data means the
overall
act of searching is broken down into two distinct phases -
- <a href="#system_search_discovery_phase">Discovery Phase</a> and
- <a href="#system_search_metadata_query_phase">Metadata Query
Phase</a>.
+ <a href="#system_search_discovery_phase" title="3.5.1. Discovery
Phase">Discovery Phase</a> and
+ <a href="#system_search_metadata_query_phase" title="3.5.2. Metadata
Query Phase">Metadata Query Phase</a>.
<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>
The discovery phase is used to locate the set of Authoritative
LS (or
LSs) for a given
@@ -995,87 +996,117 @@
of subject, eventType and Authoritative LS).
Either a specific API call and a pre-prepared query, or some
automatic
mechanism, must map the desired query into a query of the
Discovery
- info-set (see <a href="#ls_discovery_message">LS Discovery
Message</a>)
+ info-set (see <a href="#ls_discovery_message" title="4.8. LS
Discovery Message">LS Discovery Message</a>)
<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>
The discovery algorithm is as follows.

<div class="orderedlist"><ol type="1"><li>
- A client locates an LS of some sort (this
- may be known beforehand via a configuration value, or from
- bootstrapping).
+ A client locates any LS instance. This
+ SHOULD be one close to the client as possible for
+ efficiency.
</li><li>
The client should start by making a discovery query (see
- <a href="#ls_discovery_message">LS Discovery Message</a>)
to locate an
+ <a href="#ls_discovery_message" title="4.8. LS Discovery
Message">LS Discovery Message</a>) to locate an
LS that
contains the data it is interested
- in. The results of this query will be:
+ in. This query is used to find the authoritative
+ LS instances
for a set of
+ data (eventType) about a part of the network (topology).

- <div class="orderedlist"><ol type="1"><li>
- Failure: Returned if there is no
- LS at
a higher scope than the current
- one, and nothing was found in the summary info-set
that
- matches the query.
- </li><li>
- Referral: This is returned when there
- is no match other than a
- global
wildcard.
- 
- <div class="orderedlist"><ol type="1"><li>
- If this LS is not participating
- in the highest (upper) scope,
- then it returns the leader of its current scope
- (or a direct referral to an instance of the
- next-higher scope.) This is effectively a
- wildcard match saying I don't know the
- answer, but I know who might. This
is
- how the Metadata registered to an
- LS in another scope (domain)
- is found.
- </li></ol></div>
- </li><li>
- Success: We define success to mean at
- least one matching LS has been
- returned. The LS must return the
- following:
- 
- <div class="orderedlist"><ol type="1"><li>
- If this LS is an
- HLS for the discovery query, it
- returns itself.
- </li><li>
- This LS also returns any other
- HLS instances it has found that
- match. An LS instance will have
- summary information from other domains when it
is
- participating in a higher-level scope
(such as
- upper).
- </li><li>
- Note: this is where recursive searches would be
- added into the discovery phase. The trail up
the
- scope hierarchy would be followed by the
- LS itself instead of returning
- the leader LS. Ideally, this
- list would be iterated on by the
- LS so that only leaf
- LS instances are returned.
- </li></ol></div>
- </li></ol></div>
+ A successful result of this query will contain two parts:
+ 
+ <div class="orderedlist"><ol type="1"><li>
+ Referral:
+ 
+ This section
+ is used to return the list of all
+ LS
instances
+ that MUST be consulted in order to find the
+ complete set of authoratitive
+ LS
instances for the
+ given discovery request. This is not
+ necessarily the complete set since querying
+ these can lead to additional instances to check.
+ A client can
+ of course terminate this iteration earlier. For
+ instance, some clients could only want to find
+ a single source for a given set of data, and
+ may not care that another source exists.
+ 
+ If the LS is not at the
+ root scope, it MUST return the parent scope
+ in this list. (This is the only way to find
+ autoritative LS instances
+ in other scopes.)
+ 
+ The LS
MUST return any
+ peer LS
instances, and
+ any lower-scope LS instances
+ that match the summary-infoset query.
+ 
+ The Referral list can only be empty if this
+ LS is in
the root scope
+ and there are no matching records in the
+ summary scope.
+ 
+ Note: It will be a future optimization to allow
+ recursive searches in the discovery phase.
+ Therefore, eventually, it
+ will not be required for the
+ LS to
return the parent
+ scope if it is willing to make the query on
+ behalf of the client and return the results.
+ (Presumably caching them to optimize future
+ queries.)
+ </li><li>
+ Authoratative:
+ 
+ This section is used to return the list
+ of known authoratative LS
+ instances.
+ 
+ If the LS instance
+ is authoratative for the given query,
+ it will return itself.
+ 
+ Note: this is where recursive searches could
+ yeild additional authoritative LS
+ instances from queries it has made on behalf of
+ the client. If all participating
+ LS
instances supported
+ recursive mode discovery, this would allow the
+ response to the client to have a completely
+ empty referral section, and a complete
+ list of Authoratative
+ instances in this section.
+ However, for complete discovery to work, all clients
+ MUST support iterative queries. Recursive
+ queries are mearly an optimization.
+ </li></ol></div>
+ 
+ If both of these sections have empty lists, that
+ indicates that there is no data in the global
+ LS network
of services that matches the
+ given query.
</li><li>
- The client will need to iterate through the list of
returned
- LS
instances. If the LS
- returns itself, this LS can be used in the
- following Metadata query phase. If the returned
- LS is
different, a discovery query should
- be made to it.
+ The client will need to iterate through the list of all
+ returned referral instances to find all
+ Authoratative instances. Then, the
+ client will need to make
+ <a href="#system_search_metadata_query_phase"
title="3.5.2. Metadata Query Phase">Metadata Query Phase</a>
+ queries to each and every instance found in the discovery
+ phase to find the complete set of data that can
+ potentially match the query.
</li></ol></div>
</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>
The Metadata Query Phase with an individual LS is
the same as the query mechanism that is in place with the current
LS implementations.

- Once we have found the HLS (or
- HLSs) that contain
data in the range of our
- discovery query, we can pose Metadata Queries to each of them. The
- results will be failure or success.
+ Once we have found the complete list of
+ Authoritative
LS instances
+ from the discovery phase, we can pose Metadata Queries to each of
+ them. The results will be failure or success.
+
</div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h2 class="title"
style="clear: both"><a id="structures_and_messages"></a>4. Structures and
Messages</h2></div></div></div>
The following messages will be used as examples throughout this
document.
Descriptions are provided where applicable.
@@ -1711,6 +1742,18 @@
<nmwg:metadata id="metadata.1">


+ 

</nmwg:metadata>

@@ -1720,18 +1763,20 @@

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="ls_discovery_message_response"></a>4.8.2. Response</h4></div></div></div>
The response message will feature a status message, as described
- in <a href="#system_search_discovery_algorithm">Algorithm</a>.
+ in <a href="#system_search_discovery_algorithm"
title="3.5.1.1. Algorithm">Algorithm</a>.
<pre class="programlisting">

<nmwg:message type="LSDiscoveryResponse">

<nmwg:metadata id="metadata.1.r">
- 
- <nmwg:eventType>success</nmwg:eventType>

- <nmwg:eventType>failure</nmwg:eventType>
+ 
<nmwgr:datum value="some message" />

- 
+
+ 
+
<nmwg:metadata id="metadata.6">
<perfsonar:subject id="subject.6">
<psservice:service id="service.6">
@@ -1786,8 +1834,8 @@
A query language (with some programming language
features) that is designed to query collections of XML data. It
is semantically similar to SQL.
- </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="id905683"></a>[<abbr
class="abbrev">perfSONAR</abbr>] 
+ </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="id2540754"></a>[<abbr
class="abbrev">perfSONAR</abbr>] 
<a href="http://www.perfsonar.net"; target="_top">perfSONAR</a>
- . </div><div class="biblioentry"><a
id="id905701"></a>[<abbr class="abbrev">XML</abbr>] 
+ . </div><div class="biblioentry"><a
id="id2540773"></a>[<abbr class="abbrev">XML</abbr>] 
<a href="http://www.w3.org/XML"; target="_top">Extensible Markup
Language (XML)</a>
. </div></div></div></body></html>

Modified: trunk/nmwg/doc/dLS/dLS_spec_1.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS_spec_1.html 2008-03-22 06:25:49 UTC (rev 335)
+++ trunk/nmwg/doc/dLS/dLS_spec_1.html 2008-04-04 10:25:26 UTC (rev 336)
@@ -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="id824766"></a>Distributed Lookup Service (dLS) in the perfSONAR
Framework</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author">J. Boote</h3></div><div class="author"><h3
class="author">M. Glowiak</h3></div><div class="author"><h3
class="author">M. Swany</h3></div><div class="author"><h3
class="author">J. Zurawski</h3></div></div></div><div>Copyright © 2006, 2007, 2008 Internet2, Poznan Supercomputing
and Networking Center, University of Delaware</div></div><hr /></div><div
class="toc">Table of Contents<dl><dt><a
href="#changes">1. Document Changes</a></dt><dt><a href="#introduction">2.
Introduction</a></dt><dt><a
href="#system_specific_operation">3. System Specific
Operation</a></dt><dd><dl><dt><a
href="#system_overview">3.1. Overview</a></dt><dt><a href="#system_scope">3.2. Scope
Formation</a></dt><dd><dl><dt><a
href="#scope_specification">3.2.1. Scope
Specification</a></dt><dt><a
href="#scope_hierarchy">3.2.2. Scope Hierarchy</a></dt><dt><a href="#scope_defaults">3.2.3. Scope
Defaults</a></dt><dt><a
href="#scope_algorithms">3
.2.4. Scope Algorithms</a></dt><dd><dl><dt><a href="#join_procedure">3.2.4.1. Join
Procedure</a></dt><dd><dl><dt><a
href="#join_alg">3.2.4.1.1.
Algorithm</a></dt></dl></dd></dl></dd><dt><a
href="#token_messages">3.2.5. Token Messages for Control and
Election</a></dt><dd><dl><dt><a
href="#leader_election">3.2.5.1. Leader Election</a></dt><dt><a href="#registration_control">3.2.5.2. Registration
Control</a></dt><dd><dl><dt><a
href="#passing_algorithm">3.2.5.2.1. Passing
Algorithm</a></dt><dt><a
href="#rotation_time_computation">3.2.5.2.2. Rotation Time
Computation</a></dt></dl></dd></dl></dd><dt><a
href="#summarization_messages">3.2.6. Summarization
Messages</a></dt></dl></dd><dt><a
href="#bootstrapping">3.3. Bootstrapping</a></dt><dt><a href="#system_summariz
ation">3.4. Summarization</a></dt><dd><dl><dt><a href="#system_summarization_lower">3.4.1. Lower
Scope</a></dt><dt><a
href="#system_summarization_upper">3.4.2. Upper
Scope</a></dt><dd><dl><dt><a
href="#system_summarization_upper_alg">3.4.2.1. IP Address
Algorithm</a></dt></dl></dd></dl></dd><dt><a
href="#system_search">3.5. Search</a></dt><dd><dl><dt><a href="#system_search_discovery_phase">3.5.1. Discovery
Phase</a></dt><dd><dl><dt><a
href="#system_search_discovery_algorithm">3.5.1.1.
Algorithm</a></dt></dl></dd><dt><a
href="#system_search_metadata_query_phase">3.5.2. Metadata Query
Phase</a></dt></dl></dd></dl></dd><dt><a
href="#structures_and_messages">4. Structures and
Messages</a></dt><dd><dl><dt><a href="#service
_metadata">4.1. Service Metadata Example</a></dt><dt>!
<a href="#lookup_info">4.2. Lookup
Information</a></dt><dt><a href="#ls_ring">4.3.
LS Ring File Structure</a></dt><dd><dl><dt><a
href="#ls_ring_lower">4.3.1. Lower Level</a></dt><dt><a href="#ls_ring_upper">4.3.2. Upper
Level</a></dt></dl></dd><dt><a
href="#ls_join">4.4. LS Join</a></dt><dd><dl><dt><a href="#ls_join_request">4.4.1.
Request</a></dt><dt><a
href="#ls_join_response">4.4.2. Response</a></dt></dl></dd><dt><a href="#ls_token_message">4.5. LS Token
Message</a></dt><dd><dl><dt><a
href="#ls_token_message_request">4.5.1. Request</a></dt><dt><a href="#ls_token_message_response">4.5.2.
Response</a></dt></dl></dd><dt><a
href="#ls_summary_message">4.6. LS Summary Message</a></dt><dd><dl><dt><a
href="#ls_summary_message_upper">4.6.1.
Upper</a></dt><dd><dl><dt><a
href="#ls_summary_message_upper_request">4.6.1.1.
Request</a></dt><dt><a
href="#ls_summary_message_upper_response">4.6.1.2.
Response</a></dt></dl></dd><dt><a
href="#ls_summary_message_lower">4.6.2.
Lower</a></dt><dd><dl><dt><a
href="#ls_summary_message_lower_request">4.6.2.1.
Request</a></dt><dt><a
href="#ls_summary_message_lower_response">4.6.2.2.
Response</a></dt></dl></dd></dl></dd><dt><a
href="#ls_leader_message">4.7. LS Leader
Message</a></dt><dd><dl><dt><a
href="#ls_leader_message_request">4.7.1. Request</a></dt><dt><a href="#ls_leader_message_response">4.7.2.
Response</a></dt></dl></dd><dt><a href
="#ls_discovery_message">4.8. LS Discovery Message</a></span!
></dt><d
d><dl><dt><a
href="#ls_discovery_message_request">4.8.1. Request</a></dt><dt><a href="#ls_discovery_message_response">4.8.2.
Response</a></dt></dl></dd></dl></dd><dt><a
href="#glossary">Terms</a></dt><dt><a
href="#bibliography">References</a></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>Table 1. Change Log<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><tr><td align="left">1.0</td><td align="left">1/7/2008</td><td
align="left">Addition/Correction of scope diagrams</td><td align="left">J.
Zurawski</td></tr></tbody></table></div></div> </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>
+<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.72.0" /></head><body><div class="article" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h1 class="title"><a
id="id2486774"></a>Distributed Lookup Service (dLS) in the perfSONAR
Framework</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author">J. Boote</h3></div><div class="author"><h3
class="author">M. Glowiak</h3></div><div class="author"><h3
class="author">M. Swany</h3></div><div class="author"><h3
class="author">J. Zurawski</h3></div></div></div><div>Copyright © 2006, 2007, 2008 Internet2, Poznan
Supercomputing and Networking Center, University of
Delaware</div></div><hr /></div><div class="toc">Table of
Contents<dl><dt><a href="#changes">1. Document
Changes</a></dt><dt><a href="#introduction">2.
Introduction</a></dt><dt><a
href="#system_specific_operation">3. System Specific
Operation</a></dt><dd><dl><dt><a
href="#system_overview">3.1. Overview</a></dt><dt><a href="#system_scope">3.2. Scope
Formation</a></dt><dd><dl><dt><a
href="#scope_specification">3.2.1. Scope
Specification</a></dt><dt><a
href="#scope_hierarchy">3.2.2. Scope Hierarchy</a></dt><dt><a href="#scope_defaults">3.2.3. Scope
Defaults</a></dt><dt><a href="#scope_algorithms">
3.2.4. Scope Algorithms</a></dt><dd><dl><dt><a href="#join_procedure">3.2.4.1. Join
Procedure</a></dt><dd><dl><dt><a
href="#join_alg">3.2.4.1.1.
Algorithm</a></dt></dl></dd></dl></dd><dt><a
href="#token_messages">3.2.5. Token Messages for Control and
Election</a></dt><dd><dl><dt><a
href="#leader_election">3.2.5.1. Leader Election</a></dt><dt><a href="#registration_control">3.2.5.2. Registration
Control</a></dt><dd><dl><dt><a
href="#passing_algorithm">3.2.5.2.1. Passing
Algorithm</a></dt><dt><a
href="#rotation_time_computation">3.2.5.2.2. Rotation Time
Computation</a></dt></dl></dd></dl></dd><dt><a
href="#summarization_messages">3.2.6. Summarization
Messages</a></dt></dl></dd><dt><a
href="#bootstrapping">3.3. Bootstrapping</a></dt><dt><a href="#system_summari
zation">3.4. Summarization</a></dt><dd><dl><dt><a href="#system_summarization_lower">3.4.1. Lower
Scope</a></dt><dt><a
href="#system_summarization_upper">3.4.2. Upper
Scope</a></dt><dd><dl><dt><a
href="#system_summarization_upper_alg">3.4.2.1. IP Address
Algorithm</a></dt></dl></dd></dl></dd><dt><a
href="#system_search">3.5. Search</a></dt><dd><dl><dt><a href="#system_search_discovery_phase">3.5.1. Discovery
Phase</a></dt><dd><dl><dt><a
href="#system_search_discovery_algorithm">3.5.1.1.
Algorithm</a></dt></dl></dd><dt><a
href="#system_search_metadata_query_phase">3.5.2. Metadata Query
Phase</a></dt></dl></dd></dl></dd><dt><a
href="#structures_and_messages">4. Structures and
Messages</a></dt><dd><dl><dt><a href="#servic
e_metadata">4.1. Service Metadata Example</a></dt><dt!
><a href="#lookup_info">4.2. Lookup
Information</a></dt><dt><a href="#ls_ring">4.3.
LS Ring File Structure</a></dt><dd><dl><dt><a
href="#ls_ring_lower">4.3.1. Lower Level</a></dt><dt><a href="#ls_ring_upper">4.3.2. Upper
Level</a></dt></dl></dd><dt><a
href="#ls_join">4.4. LS Join</a></dt><dd><dl><dt><a href="#ls_join_request">4.4.1.
Request</a></dt><dt><a
href="#ls_join_response">4.4.2. Response</a></dt></dl></dd><dt><a href="#ls_token_message">4.5. LS Token
Message</a></dt><dd><dl><dt><a
href="#ls_token_message_request">4.5.1. Request</a></dt><dt><a href="#ls_token_message_response">4.5.2.
Response</a></dt></dl></dd><dt><a
href="#ls_summary_message">4.6. LS Summary Message</a>
</dt><dd><dl><dt><a
href="#ls_summary_message_upper">4.6.1.
Upper</a></dt><dd><dl><dt><a
href="#ls_summary_message_upper_request">4.6.1.1.
Request</a></dt><dt><a
href="#ls_summary_message_upper_response">4.6.1.2.
Response</a></dt></dl></dd><dt><a
href="#ls_summary_message_lower">4.6.2.
Lower</a></dt><dd><dl><dt><a
href="#ls_summary_message_lower_request">4.6.2.1.
Request</a></dt><dt><a
href="#ls_summary_message_lower_response">4.6.2.2.
Response</a></dt></dl></dd></dl></dd><dt><a
href="#ls_leader_message">4.7. LS Leader
Message</a></dt><dd><dl><dt><a
href="#ls_leader_message_request">4.7.1. Request</a></dt><dt><a href="#ls_leader_message_response">4.7.2.
Response</a></dt></dl></dd><dt><a hre
f="#ls_discovery_message">4.8. LS Discovery Message</a></spa!
n></dt><
dd><dl><dt><a
href="#ls_discovery_message_request">4.8.1. Request</a></dt><dt><a href="#ls_discovery_message_response">4.8.2.
Response</a></dt></dl></dd></dl></dd><dt><a
href="#glossary">Terms</a></dt><dt><a
href="#bibliography">References</a></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>Table 1. Change Log<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">Initia
l 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><tr><td align="left">1.0</td><td align="left">1/7/2008</td><td
align="left">Addition/Correction of scope diagrams</td><td align="left">J.
Zurawski</td></tr></tbody></table></div></div> </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>
This document describes the
Distributed Lookup Service
(dLS)
- in the <a href="#id905683">perfSONAR</a> system. This modification
extends
+ in the [<a href="#id2540754">perfSONAR</a>] system. This modification extends
the basic Lookup Service
(LS)
functionality that has been present in the system for some time. The
basic LS supports the storage and querying of
@@ -61,15 +61,15 @@
metadata 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
+ <a href="#service_metadata" title="4.1. Service Metadata
Example">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>).
+ <a href="#lookup_info" title="4.2. Lookup Information">Lookup
Information</a>).

The idea is to move the metadata from a service-local
- <a href="#id905701">XML</a> data store to a specialized
+ [<a href="#id2540773">XML</a>]
data store to a specialized
LS with additional
searching capabilities. The
LS 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>)
+ <a href="#Berkeley DB XML" title="Berkeley DB XML"></a> or <a
href="#eXist XML DB" title="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
@@ -356,7 +356,8 @@
The default Scope
SHOULD be
determined by appending a URI
with the fully qualified hostname of the host running the
- LS to the
global ls.perfsonar.net domain
+ LS to the
global
+ perfsonar.net domain
that will be supported by the perfSONAR consortium.
For example,
a new LS
started on rnp.br would
@@ -405,7 +406,7 @@
based upon continents or countries. This optimizations
can be added in after the fact, without changing
Scope
specifications for already
- deployed LS
instances. (Already
+ deployed LS
instances. Already
deployed LS
instances would simply
jump over the geographic Scope
directly to the root Scope. This
@@ -416,7 +417,7 @@
of the dLS, no
matter which scope we are
talking about, are as follows:

- <div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><a href="#join_procedure">Join
Procedure</a> - Join Procedure</li><li style="list-style-type:
circle"><a href="#token_messages">Token Messages for Control and
Election</a> - Token Passing</li><li style="list-style-type:
circle"><a href="#summarization_messages">Summarization Messages</a> -
Summarization Notification</li></ul></div>
+ <div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><a href="#join_procedure"
title="3.2.4.1. Join Procedure">Join Procedure</a> - Join
Procedure</li><li style="list-style-type: circle"><a
href="#token_messages" title="3.2.5. Token Messages for Control and
Election">Token Messages for Control and Election</a> - Token
Passing</li><li style="list-style-type: circle"><a
href="#summarization_messages" title="3.2.6. Summarization
Messages">Summarization Messages</a> - Summarization
Notification</li></ul></div>

Each of these procedures is important to keeping members of
the
distributed service
functioning correctly. The
@@ -427,7 +428,7 @@
When an LS
instance comes online it must have some
knowledge of potential peers (both inter and intra
scope). This
information is contained in LSRing (see
- <a href="#ls_ring">LS Ring File Structure</a>) files.
The inter-domain knowledge (i.e.
+ <a href="#ls_ring" title="4.3. LS Ring File
Structure">LS Ring File Structure</a>) files. The inter-domain knowledge
(i.e.
lower) is used
first to establish a connection
to an already in progress grouping, or perhaps to start
a group that
may not exist yet.
@@ -436,7 +437,7 @@
LSRing
information and send an
LSControl message
to known LS
instances with a join
- eventType (see <a
href="#ls_join">LS Join</a>)
+ eventType (see <a
href="#ls_join" title="4.4. LS Join">LS Join</a>)
until a successful response is seen. The LS
candidate will then search through the successful
LSControlResponse
to this message and update its
@@ -461,7 +462,7 @@
After this initial warm-up the LS will observe the
rules of token etiquette and remain silent until it is
contacted with
a token, or it has not seen one in a very long time (see
- <a href="#token_messages">Token Messages for Control and
Election</a>).
+ <a href="#token_messages" title="3.2.5. Token Messages
for Control and Election">Token Messages for Control and Election</a>).
<div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="join_alg"></a>3.2.4.1.1. Algorithm</h6></div></div></div>
The algorithm for joining a logical group works as
follows. Some
steps have been simplified for the sake of the
diagram. Additional
@@ -494,7 +495,7 @@
and update it's own LSRing.
LS1 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
+ <a href="#rotation_time_computation"
title="3.2.5.2.2. Rotation Time Computation">Rotation Time Computation</a>)
until it is time
to speak to the group.
</li><li>
LS2 sends
@@ -536,7 +537,7 @@
</li><li>
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.
+ See <a href="#leader_election"
title="3.2.5.1. Leader Election">Leader Election</a> for more details.
</li><li>
Regular token exchange and summarization
notification will
resume in time.
@@ -564,14 +565,14 @@
</div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="token_messages"></a>3.2.5. Token Messages for Control and
Election</h4></div></div></div>
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
- <a href="#registration_control">Registration Control</a>. A
leader is necessary to
+ used for two purposes: <a href="#leader_election"
title="3.2.5.1. Leader Election">Leader Election</a> and
+ <a href="#registration_control" title="3.2.5.2. Registration
Control">Registration Control</a>. A leader is necessary to
circulate group updates, to start tokens to initiate registration,
and
to represent a given scope in an upper scope.

The token is an
LSControlMessage (see
- <a href="#ls_token_message">LS Token Message</a>) meant to be
passed around an
+ <a href="#ls_token_message" title="4.5. LS Token Message">LS Token
Message</a>) meant to be passed around an
LSRing to the
various members in some order. There
are various criteria that can be used in deciding how to order the
group so that everyone can predict where the token is, when they
might
@@ -610,7 +611,7 @@
mechanism, initiated by the current leader, with the current
leader
excluded. The Leader and
Vice-leader LS instances
- should exchange messages (see <a href="#ls_leader_message">LS
Leader Message</a>)
+ should exchange messages (see <a href="#ls_leader_message"
title="4.7. LS Leader Message">LS Leader Message</a>)
periodically to ensure that in the event of a failure the lower
level will still maintain a cached copy of the information at the
upper level. It should be noted that whenever a the
@@ -671,8 +672,8 @@
The token can be viewed as permission
to talk
and permits the holding LS to send its summary
information to all other available LS instances
- (see <a href="#ls_summary_message_lower">Lower</a> and
- <a href="#ls_summary_message_upper">Upper</a>). The responses
will
+ (see <a href="#ls_summary_message_lower"
title="4.6.2. Lower">Lower</a> and
+ <a href="#ls_summary_message_upper"
title="4.6.1. Upper">Upper</a>). The responses will
be parsed to get any useful updated information about current
dLS cloud state.
<div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="passing_algorithm"></a>3.2.5.2.1. Passing
Algorithm</h6></div></div></div>
@@ -702,7 +703,7 @@
with any new service info.
</li><li>
LS1 waits
- (see <a href="#rotation_time_computation">Rotation Time
Computation</a>).
+ (see <a href="#rotation_time_computation"
title="3.2.5.2.2. Rotation Time Computation">Rotation Time Computation</a>).
</li><li>
LS1 sends
token to next
LS
(LS2) from the
@@ -713,10 +714,10 @@

Each note in the local group is responsible for monitoring the
state of the token. If the internal timer (see
- <a href="#rotation_time_computation">Rotation Time
Computation</a>) expires without
+ <a href="#rotation_time_computation"
title="3.2.5.2.2. Rotation Time Computation">Rotation Time Computation</a>)
expires without
seeing a token a new token should be generated. If a token is
seen too soon (see
- <a href="#rotation_time_computation">Rotation Time
Computation</a>) it should be
+ <a href="#rotation_time_computation"
title="3.2.5.2.2. 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.
</div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h6 class="title"><a
id="rotation_time_computation"></a>3.2.5.2.2. Rotation Time
Computation</h6></div></div></div>
@@ -739,8 +740,8 @@
initiated. Conversely if a token is seen too early (less than
half the calculated time) the token should be dropped.
</div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="summarization_messages"></a>3.2.6. Summarization
Messages</h4></div></div></div>
- <a href="#system_summarization_lower">Lower Scope</a> and
- <a href="#system_summarization_upper">Upper Scope</a> contain
examples of the
+ <a href="#system_summarization_lower" title="3.4.1. Lower
Scope">Lower Scope</a> and
+ <a href="#system_summarization_upper" title="3.4.2. Upper
Scope">Upper Scope</a> contain examples of the
message format for this exchange. It is left up to the
implementation when the summarization occurs (i.e. at message
send time, or also as a periodic event).
@@ -748,7 +749,7 @@
Bootstrapping is the mechanism used by any
perfSONAR service to find
the first
LS instance. Once
any LS
- instance is found, the <a href="#system_search">Search</a>
+ instance is found, the <a href="#system_search"
title="3.5. Search">Search</a>
mechanism can be used to find specific ones as required.
(For example, a new LS instance will need
to look for any current LS instances in the
@@ -784,7 +785,7 @@
LS cloud.

We start by making an observation that summarization is best based on
- scope (see also <a href="#system_scope">Scope Formation</a>). Simply
put, this
+ scope (see also <a href="#system_scope" title="3.2. Scope
Formation">Scope Formation</a>). Simply put, this
means that we should attempt to summarize more the
farther away from the
source that we get. This creates a smaller data set that travels
@@ -840,7 +841,7 @@
information to other LS instances to propagate the
appropriate information. Information exchange will be handled
using a
taking turns protocol such
as
- <a href="#Token Ring">Token Ring</a>. The holder of the token
will then
+ <a href="#Token Ring" title="Token Ring"></a>. The holder of the
token will then
perform the information exchange to other known instances. The
following diagram illustrates the exchange between
LS deployments.
@@ -866,7 +867,7 @@
LSs (generally
representing other domains) in
order to form a higher-level, or upper, scope.
The mechanics of how we learn who is the designated leader are
- discussed in <a href="#leader_election">Leader Election</a>. The
leader from
+ discussed in <a href="#leader_election" title="3.2.5.1. Leader
Election">Leader Election</a>. The leader from
each of the first layers of this hierarchy (and the designated
backup)
will be responsible for examining each member's summary information
and building a summarization/aggregation that represents the
contents
@@ -881,11 +882,11 @@
Summarization will be performed using specialized summary
algorithm.
Topology information such as IP addresses will be summarized using
algorithms based on Radix Tree (see
- <a href="#system_summarization_upper_alg">IP Address
Algorithm</a>).
+ <a href="#system_summarization_upper_alg" title="3.4.2.1. IP
Address Algorithm">IP Address Algorithm</a>).

Other information can be summarized in an easier manner through the
use of either Extensible Stylesheet Language Transformation
- (<a href="#XSLT">XSLT</a>) documents or the <a
href="#XQuery">XQuery</a>
+ (<a href="#XSLT" title="XSLT"></a>) documents or the <a
href="#XQuery" title="XQuery"></a>
language as discussed in the previous section.
These mechanisms will take into account the XML elements that
represent the network topology currently used in metadata subjects
as
@@ -895,8 +896,8 @@
service summary that
represents the breadth of
the original input. This consists minimally of IP networks and
addresses and the eventTypes which are stored and can be generated.
- See <a href="#ls_summary_message_lower">Lower</a> or
- <a href="#ls_summary_message_upper">Upper</a> for a mock-up of the
+ See <a href="#ls_summary_message_lower"
title="4.6.2. Lower">Lower</a> or
+ <a href="#ls_summary_message_upper" title="4.6.1. Upper">Upper</a>
for a mock-up of the
summary output. Additional transformations, while aggressive, will
strive to preserve as much information as possible to remain
useful
during the search procedures.
@@ -984,8 +985,8 @@
LS instance (or
instances) that contain the relevant
details. This separation of full data and summary data means the
overall
act of searching is broken down into two distinct phases -
- <a href="#system_search_discovery_phase">Discovery Phase</a> and
- <a href="#system_search_metadata_query_phase">Metadata Query
Phase</a>.
+ <a href="#system_search_discovery_phase" title="3.5.1. Discovery
Phase">Discovery Phase</a> and
+ <a href="#system_search_metadata_query_phase" title="3.5.2. Metadata
Query Phase">Metadata Query Phase</a>.
<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>
The discovery phase is used to locate the set of Authoritative
LS (or
LSs) for a given
@@ -995,87 +996,117 @@
of subject, eventType and Authoritative LS).
Either a specific API call and a pre-prepared query, or some
automatic
mechanism, must map the desired query into a query of the
Discovery
- info-set (see <a href="#ls_discovery_message">LS Discovery
Message</a>)
+ info-set (see <a href="#ls_discovery_message" title="4.8. LS
Discovery Message">LS Discovery Message</a>)
<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>
The discovery algorithm is as follows.

<div class="orderedlist"><ol type="1"><li>
- A client locates an LS of some sort (this
- may be known beforehand via a configuration value, or from
- bootstrapping).
+ A client locates any LS instance. This
+ SHOULD be one close to the client as possible for
+ efficiency.
</li><li>
The client should start by making a discovery query (see
- <a href="#ls_discovery_message">LS Discovery Message</a>)
to locate an
+ <a href="#ls_discovery_message" title="4.8. LS Discovery
Message">LS Discovery Message</a>) to locate an
LS that
contains the data it is interested
- in. The results of this query will be:
+ in. This query is used to find the authoritative
+ LS instances
for a set of
+ data (eventType) about a part of the network (topology).

- <div class="orderedlist"><ol type="1"><li>
- Failure: Returned if there is no
- LS at
a higher scope than the current
- one, and nothing was found in the summary info-set
that
- matches the query.
- </li><li>
- Referral: This is returned when there
- is no match other than a
- global
wildcard.
- 
- <div class="orderedlist"><ol type="1"><li>
- If this LS is not participating
- in the highest (upper) scope,
- then it returns the leader of its current scope
- (or a direct referral to an instance of the
- next-higher scope.) This is effectively a
- wildcard match saying I don't know the
- answer, but I know who might. This
is
- how the Metadata registered to an
- LS in another scope (domain)
- is found.
- </li></ol></div>
- </li><li>
- Success: We define success to mean at
- least one matching LS has been
- returned. The LS must return the
- following:
- 
- <div class="orderedlist"><ol type="1"><li>
- If this LS is an
- HLS for the discovery query, it
- returns itself.
- </li><li>
- This LS also returns any other
- HLS instances it has found that
- match. An LS instance will have
- summary information from other domains when it
is
- participating in a higher-level scope
(such as
- upper).
- </li><li>
- Note: this is where recursive searches would be
- added into the discovery phase. The trail up
the
- scope hierarchy would be followed by the
- LS itself instead of returning
- the leader LS. Ideally, this
- list would be iterated on by the
- LS so that only leaf
- LS instances are returned.
- </li></ol></div>
- </li></ol></div>
+ A successful result of this query will contain two parts:
+ 
+ <div class="orderedlist"><ol type="1"><li>
+ Referral:
+ 
+ This section
+ is used to return the list of all
+ LS
instances
+ that MUST be consulted in order to find the
+ complete set of authoratitive
+ LS
instances for the
+ given discovery request. This is not
+ necessarily the complete set since querying
+ these can lead to additional instances to check.
+ A client can
+ of course terminate this iteration earlier. For
+ instance, some clients could only want to find
+ a single source for a given set of data, and
+ may not care that another source exists.
+ 
+ If the LS is not at the
+ root scope, it MUST return the parent scope
+ in this list. (This is the only way to find
+ autoritative LS instances
+ in other scopes.)
+ 
+ The LS
MUST return any
+ peer LS
instances, and
+ any lower-scope LS instances
+ that match the summary-infoset query.
+ 
+ The Referral list can only be empty if this
+ LS is in
the root scope
+ and there are no matching records in the
+ summary scope.
+ 
+ Note: It will be a future optimization to allow
+ recursive searches in the discovery phase.
+ Therefore, eventually, it
+ will not be required for the
+ LS to
return the parent
+ scope if it is willing to make the query on
+ behalf of the client and return the results.
+ (Presumably caching them to optimize future
+ queries.)
+ </li><li>
+ Authoratative:
+ 
+ This section is used to return the list
+ of known authoratative LS
+ instances.
+ 
+ If the LS instance
+ is authoratative for the given query,
+ it will return itself.
+ 
+ Note: this is where recursive searches could
+ yeild additional authoritative LS
+ instances from queries it has made on behalf of
+ the client. If all participating
+ LS
instances supported
+ recursive mode discovery, this would allow the
+ response to the client to have a completely
+ empty referral section, and a complete
+ list of Authoratative
+ instances in this section.
+ However, for complete discovery to work, all clients
+ MUST support iterative queries. Recursive
+ queries are mearly an optimization.
+ </li></ol></div>
+ 
+ If both of these sections have empty lists, that
+ indicates that there is no data in the global
+ LS network
of services that matches the
+ given query.
</li><li>
- The client will need to iterate through the list of
returned
- LS
instances. If the LS
- returns itself, this LS can be used in the
- following Metadata query phase. If the returned
- LS is
different, a discovery query should
- be made to it.
+ The client will need to iterate through the list of all
+ returned referral instances to find all
+ Authoratative instances. Then, the
+ client will need to make
+ <a href="#system_search_metadata_query_phase"
title="3.5.2. Metadata Query Phase">Metadata Query Phase</a>
+ queries to each and every instance found in the discovery
+ phase to find the complete set of data that can
+ potentially match the query.
</li></ol></div>
</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>
The Metadata Query Phase with an individual LS is
the same as the query mechanism that is in place with the current
LS implementations.

- Once we have found the HLS (or
- HLSs) that contain
data in the range of our
- discovery query, we can pose Metadata Queries to each of them. The
- results will be failure or success.
+ Once we have found the complete list of
+ Authoritative
LS instances
+ from the discovery phase, we can pose Metadata Queries to each of
+ them. The results will be failure or success.
+
</div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h2 class="title"
style="clear: both"><a id="structures_and_messages"></a>4. Structures and
Messages</h2></div></div></div>
The following messages will be used as examples throughout this
document.
Descriptions are provided where applicable.
@@ -1087,32 +1118,32 @@
Layer 3.
<pre class="programlisting">

- <nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
id="m_ale-netutil-1">
- <netutil:subject
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/";
id="s_ale-netutil-1">
- <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
- <nmwgt:ifAddress
type="ipv4">128.4.133.165</nmwgt:ifAddress>
-
<nmwgt:hostName>ale.pc.cis.udel.edu</nmwgt:hostName>
- <nmwgt:ifName>eth0</nmwgt:ifName>
- <nmwgt:ifIndex>2</nmwgt:ifIndex>
- <nmwgt:direction>in</nmwgt:direction>
- <nmwgt:capacity>1000000000</nmwgt:capacity>
- </nmwgt:interface>
- </netutil:subject>
- <nmwg:eventType>
+ <nmwg:metadata
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; id="m_ale-netutil-1">
+ <netutil:subject
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/";
id="s_ale-netutil-1">
+ <nmwgt:interface xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";>
+ <nmwgt:ifAddress type="ipv4">128.4.133.165</nmwgt:ifAddress>
+ <nmwgt:hostName>ale.pc.cis.udel.edu</nmwgt:hostName>
+ <nmwgt:ifName>eth0</nmwgt:ifName>
+ <nmwgt:ifIndex>2</nmwgt:ifIndex>
+ <nmwgt:direction>in</nmwgt:direction>
+ <nmwgt:capacity>1000000000</nmwgt:capacity>
+ </nmwgt:interface>
+ </netutil:subject>
+ <nmwg:eventType>
http://ggf.org/ns/nmwg/tools/snmp/2.0
- </nmwg:eventType>
- <nmwg:eventType>
+ </nmwg:eventType>
+ <nmwg:eventType>
http://ggf.org/ns/nmwg/characteristic/utilization/2.0
- </nmwg:eventType>
- <nmwg:parameters id="p_ale-netutil-1">
- <nmwg:parameter name="supportedEventType">
+ </nmwg:eventType>
+ <nmwg:parameters id="p_ale-netutil-1">
+ <nmwg:parameter name="supportedEventType">
http://ggf.org/ns/nmwg/tools/snmp/2.0
- </nmwg:parameter>
- <nmwg:parameter name="supportedEventType">
+ </nmwg:parameter>
+ <nmwg:parameter name="supportedEventType">
http://ggf.org/ns/nmwg/characteristic/utilization/2.0
- </nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
+ </nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="lookup_info"></a>4.2. Lookup Information</h3></div></div></div>
Example Lookup Information from a Measurement Archive
@@ -1121,51 +1152,51 @@
metadata from the MA.
<pre class="programlisting">

- <nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
id="http://newcastle.pc.cis.udel.edu:6767/perfSONAR_PS/services/snmpMA">
- <perfsonar:subject id="subject.15977808">
- <psservice:service id="service.16283379">
- <psservice:serviceName>UDel perfSONAR-PS SNMP
MA</psservice:serviceName>
- <psservice:accessPoint>
+ <nmwg:metadata
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
id="http://newcastle.pc.cis.udel.edu:6767/perfSONAR_PS/services/snmpMA";>
+ <perfsonar:subject id="subject.15977808">
+ <psservice:service id="service.16283379">
+ <psservice:serviceName>UDel perfSONAR-PS SNMP
MA</psservice:serviceName>
+ <psservice:accessPoint>

http://newcastle.pc.cis.udel.edu:6767/perfSONAR_PS/services/snmpMA
- </psservice:accessPoint>
- <psservice:serviceType>MA</psservice:serviceType>
- <psservice:serviceDescription>
+ </psservice:accessPoint>
+ <psservice:serviceType>MA</psservice:serviceType>
+ <psservice:serviceDescription>
perfSPNAR-PS SNMP MA deployed at UDel, Newark DE, USA
- </psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- </nmwg:metadata>
+ </psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ </nmwg:metadata>

<nmwg:data xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";

id="http://newcastle.pc.cis.udel.edu:6666/perfSONAR_PS/services/LS/1177595435/1";

metadataIdRef="http://newcastle.pc.cis.udel.edu:6767/perfSONAR_PS/services/snmpMA">
- <nmwg:metadata id="m_ale-netutil-1">
- <netutil:subject
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/";
id="s_ale-netutil-1">
- <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
- <nmwgt:ifAddress
type="ipv4">128.4.133.165</nmwgt:ifAddress>
-
<nmwgt:hostName>ale.pc.cis.udel.edu</nmwgt:hostName>
- <nmwgt:ifName>eth0</nmwgt:ifName>
- <nmwgt:ifIndex>2</nmwgt:ifIndex>
- <nmwgt:direction>in</nmwgt:direction>
- <nmwgt:capacity>1000000000</nmwgt:capacity>
- </nmwgt:interface>
- </netutil:subject>
- <nmwg:eventType>
+ <nmwg:metadata id="m_ale-netutil-1">
+ <netutil:subject
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/";
id="s_ale-netutil-1">
+ <nmwgt:interface xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";>
+ <nmwgt:ifAddress type="ipv4">128.4.133.165</nmwgt:ifAddress>
+ <nmwgt:hostName>ale.pc.cis.udel.edu</nmwgt:hostName>
+ <nmwgt:ifName>eth0</nmwgt:ifName>
+ <nmwgt:ifIndex>2</nmwgt:ifIndex>
+ <nmwgt:direction>in</nmwgt:direction>
+ <nmwgt:capacity>1000000000</nmwgt:capacity>
+ </nmwgt:interface>
+ </netutil:subject>
+ <nmwg:eventType>
http://ggf.org/ns/nmwg/tools/snmp/2.0
- </nmwg:eventType>
- <nmwg:eventType>
+ </nmwg:eventType>
+ <nmwg:eventType>
http://ggf.org/ns/nmwg/characteristic/utilization/2.0
- </nmwg:eventType>
- <nmwg:parameters id="p_ale-netutil-1">
- <nmwg:parameter name="supportedEventType">
+ </nmwg:eventType>
+ <nmwg:parameters id="p_ale-netutil-1">
+ <nmwg:parameter name="supportedEventType">
http://ggf.org/ns/nmwg/tools/snmp/2.0
- </nmwg:parameter>
- <nmwg:parameter name="supportedEventType">
+ </nmwg:parameter>
+ <nmwg:parameter name="supportedEventType">
http://ggf.org/ns/nmwg/characteristic/utilization/2.0
- </nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
- </nmwg:data>
+ </nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>
+ </nmwg:data>

</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>
The LSRing file
represents the
@@ -1180,71 +1211,71 @@
our scope (for example, a domain).
<pre class="programlisting">

- <nmwg:store type="LSRing-lower">
+ <nmwg:store
type="LSRing-lower">

- 
+ 

- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="active">0</nmwg:parameter>
- <nmwg:parameter
name="leader">0</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
+ <psservice:serviceName>Internet2 LS #2</psservice:serviceName>
+ <psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:parameters>
+ <nmwg:parameter name="active">0</nmwg:parameter>
+ <nmwg:parameter name="leader">0</nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>

- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter>
- <nmwg:parameter
name="leader">0</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.6">
+ <perfsonar:subject id="subject.6">
+ <psservice:service id="service.6">
+ <psservice:serviceName>Internet2 LS #6</psservice:serviceName>
+ <psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:parameters>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="leader">0</nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>

- <nmwg:metadata id="metadata.1">
- <perfsonar:subject id="subject.1">
- <psservice:service id="service.1">
- <psservice:serviceName>Internet2 LS
#1</psservice:serviceName>
-
<psservice:accessPoint>http://patdev0.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter>
- <nmwg:parameter
name="leader">1</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.1">
+ <perfsonar:subject id="subject.1">
+ <psservice:service id="service.1">
+ <psservice:serviceName>Internet2 LS #1</psservice:serviceName>
+ <psservice:accessPoint>http://patdev0.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:parameters>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="leader">1</nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>

- <nmwg:metadata id="metadata.9">
- <perfsonar:subject id="subject.9">
- <psservice:service id="service.9">
- <psservice:serviceName>Internet2 LS
#9</psservice:serviceName>
-
<psservice:accessPoint>http://thunderbird.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter>
- <nmwg:parameter
name="leader">0</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.9">
+ <perfsonar:subject id="subject.9">
+ <psservice:service id="service.9">
+ <psservice:serviceName>Internet2 LS #9</psservice:serviceName>
+ <psservice:accessPoint>http://thunderbird.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:parameters>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="leader">0</nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>

- </nmwg:store>
+ </nmwg:store>

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="ls_ring_upper"></a>4.3.2. Upper Level</h4></div></div></div>
The upper level represents
the interaction
@@ -1252,41 +1283,41 @@
split).
<pre class="programlisting">

- <nmwg:store type="LSRing-upper">
+ <nmwg:store
type="LSRing-upper">

- 
+ 

- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>ESnet LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://mea1.es.net:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter>
- <nmwg:parameter
name="leader">0</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
+ <psservice:serviceName>ESnet LS #2</psservice:serviceName>
+ <psservice:accessPoint>http://mea1.es.net:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:parameters>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="leader">0</nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>

- <nmwg:metadata id="metadata.1">
- <perfsonar:subject id="subject.1">
- <psservice:service id="service.1">
- <psservice:serviceName>Geant LS
#1</psservice:serviceName>
-
<psservice:accessPoint>http://ls.perfsonar.pionier.net.pl:8080/XML-LS-1.1.1/services/LookupService</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter>
- <nmwg:parameter
name="leader">1</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.1">
+ <perfsonar:subject id="subject.1">
+ <psservice:service id="service.1">
+ <psservice:serviceName>Geant LS #1</psservice:serviceName>
+ <psservice:accessPoint>http://ls.perfsonar.pionier.net.pl:8080/XML-LS-1.1.1/services/LookupService</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:parameters>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="leader">1</nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>

- </nmwg:store>
+ </nmwg:store>

</pre></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a id="ls_join"></a>4.4. LS
Join</h3></div></div></div>
The LSJoin messages
are used by a service to
@@ -1300,23 +1331,23 @@
contain service information.
<pre class="programlisting">

- <nmwg:message type="LSControlRequest">
+ <nmwg:message type="LSControlRequest">

- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/join</nmwg:eventType>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
+ <psservice:serviceName>Internet2 LS #2</psservice:serviceName>
+ <psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/join</nmwg:eventType>
+ </nmwg:metadata>

- <nmwg:data id="data.2" metadataIdRef="metadata.2" />
+ <nmwg:data
id="data.2" metadataIdRef="metadata.2" />

- </nmwg:message>
+ </nmwg:message>

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="ls_join_response"></a>4.4.2. Response</h4></div></div></div>
The response message should indicate success or failure via the
@@ -1328,45 +1359,45 @@
snapshot of the group.
<pre class="programlisting">

- <nmwg:message type="LSControlResponse">
+ <nmwg:message type="LSControlResponse">

- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/join/success</nmwg:eventType>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.6">
+ <perfsonar:subject id="subject.6">
+ <psservice:service id="service.6">
+ <psservice:serviceName>Internet2 LS #6</psservice:serviceName>
+ <psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/join/success</nmwg:eventType>
+ </nmwg:metadata>

- <nmwg:data id="data.6" metadataIdRef="metadata.6">
- <nmwg:metadata id="metadata.1">
- <perfsonar:subject id="subject.1">
- <psservice:service id="service.1">
- <psservice:serviceName>Internet2 LS
#1</psservice:serviceName>
-
<psservice:accessPoint>http://patdev0.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- </nmwg:metadata>
+ <nmwg:data
id="data.6" metadataIdRef="metadata.6">
+ <nmwg:metadata id="metadata.1">
+ <perfsonar:subject id="subject.1">
+ <psservice:service id="service.1">
+ <psservice:serviceName>Internet2 LS #1</psservice:serviceName>
+ <psservice:accessPoint>http://patdev0.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ </nmwg:metadata>

- <nmwg:metadata id="metadata.9">
- <perfsonar:subject id="subject.9">
- <psservice:service id="service.9">
- <psservice:serviceName>Internet2 LS
#9</psservice:serviceName>
-
<psservice:accessPoint>http://thunderbird.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- </nmwg:metadata>
- </nmwg:data>
+ <nmwg:metadata id="metadata.9">
+ <perfsonar:subject id="subject.9">
+ <psservice:service id="service.9">
+ <psservice:serviceName>Internet2 LS #9</psservice:serviceName>
+ <psservice:accessPoint>http://thunderbird.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ </nmwg:metadata>
+ </nmwg:data>

- </nmwg:message>
+ </nmwg:message>

</pre></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="ls_token_message"></a>4.5. LS Token Message</h3></div></div></div>
This message exchange represents the token that is passed between
@@ -1379,77 +1410,77 @@
upper depending on the
token we are exchanging).
<pre class="programlisting">

- <nmwg:message type="LSControlRequest">
+ <nmwg:message
type="LSControlRequest">

- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/token/lower</nmwg:eventType>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.6">
+ <perfsonar:subject id="subject.6">
+ <psservice:service id="service.6">
+ <psservice:serviceName>Internet2 LS #6</psservice:serviceName>
+ <psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/token/lower</nmwg:eventType>
+ </nmwg:metadata>

- <nmwg:data id="data.6" metadataIdRef="metadata.6">
+ <nmwg:data
id="data.6" metadataIdRef="metadata.6">

- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter>
- <nmwg:parameter
name="leader">0</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
+ <psservice:serviceName>Internet2 LS #2</psservice:serviceName>
+ <psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:parameters>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="leader">0</nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>

- <nmwg:metadata id="metadata.1">
- 
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.1">
+ 
+ </nmwg:metadata>

- <nmwg:metadata id="metadata.9">
- 
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.9">
+ 
+ </nmwg:metadata>

- </nmwg:data>
+ </nmwg:data>

- </nmwg:message>
+ </nmwg:message>

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="ls_token_message_response"></a>4.5.2. Response</h4></div></div></div>
The response to this message should indicate success or failure.
Failure and timeouts should trigger a resend.
<pre class="programlisting">

- <nmwg:message type="LSControlResponse">
+ <nmwg:message type="LSControlResponse">

- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/token/lower/success</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter>
- <nmwg:parameter
name="leader">0</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
+ <psservice:serviceName>Internet2 LS #2</psservice:serviceName>
+ <psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/token/lower/success</nmwg:eventType>
+ <nmwg:parameters>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="leader">0</nmwg:parameter>
+ </nmwg:parameters>
+ </nmwg:metadata>

- <nmwg:data id="data.2" metadataIdRef="metadata.2">
- <nmwgr:datum value="some sort of message?">
- </nmwg:data>
+ <nmwg:data
id="data.2" metadataIdRef="metadata.2">
+ <nmwgr:datum value="some sort of message?">
+ </nmwg:data>

- </nmwg:message>
+ </nmwg:message>

</pre></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="ls_summary_message"></a>4.6. LS Summary Message</h3></div></div></div>
The summary message
represents one
@@ -1467,35 +1498,35 @@
is the summary info.
<pre class="programlisting">

- <nmwg:message type="LSControlRequest">
+ <nmwg:message type="LSControlRequest">

- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/summary/upper</nmwg:eventType>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
+ <psservice:serviceName>Internet2 LS #2</psservice:serviceName>
+ <psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/summary/upper</nmwg:eventType>
+ </nmwg:metadata>

- <nmwg:data id="data.2" metadataIdRef="metadata.2">
- <nmwg:metadata>
- <summary:subject
xmlns:summary="http://ggf.org/ns/nmwg/summary/2.0/">
- <nmtl3:network>
-
<nmtl3:ipAddress>128.4.10.0/16</nmtl3:ipAddress>
- </nmtl3:network>
- </summary:subject>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- </nmwg:metadata>
+ <nmwg:data id="data.2" metadataIdRef="metadata.2">
+ <nmwg:metadata>
+ <summary:subject
xmlns:summary="http://ggf.org/ns/nmwg/summary/2.0/";>
+ <nmtl3:network>
+ <nmtl3:ipAddress>128.4.10.0/16</nmtl3:ipAddress>
+ </nmtl3:network>
+ </summary:subject>
+ <nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
+ <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
+ <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
+ </nmwg:metadata>

- </nmwg:data>
+ </nmwg:data>

- </nmwg:message>
+ </nmwg:message>

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="ls_summary_message_upper_response"></a>4.6.1.2. Response</h5></div></div></div>
The response message should indicate success or failure via
@@ -1517,26 +1548,26 @@
</li></ul></div>
<pre class="programlisting">

- <nmwg:message type="LSControlResponse">
+ <nmwg:message type="LSControlResponse">

- 
- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/summary/upper/success</nmwg:eventType>
- </nmwg:metadata>
+ 
+ <nmwg:metadata id="metadata.6">
+ <perfsonar:subject id="subject.6">
+ <psservice:service id="service.6">
+ <psservice:serviceName>Internet2 LS #6</psservice:serviceName>
+ <psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/summary/upper/success</nmwg:eventType>
+ </nmwg:metadata>

- <nmwg:data id="data.6" metadataIdRef="metadata.6">
- <nmwgr:datum value="some sort of message?">
- </nmwg:data>
+ <nmwg:data id="data.6" metadataIdRef="metadata.6">
+ <nmwgr:datum value="some sort of message?">
+ </nmwg:data>

- </nmwg:message>
+ </nmwg:message>

</pre></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a
id="ls_summary_message_lower"></a>4.6.2. Lower</h4></div></div></div>
This message exchange represents when an LS instance is holding
@@ -1549,33 +1580,33 @@
parameters) summary.
<pre class="programlisting">

- <nmwg:message type="LSControlRequest">
+ <nmwg:message type="LSControlRequest">

- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/summary/lower</nmwg:eventType>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
+ <psservice:serviceName>Internet2 LS #2</psservice:serviceName>
+ <psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/summary/lower</nmwg:eventType>
+ </nmwg:metadata>

- <nmwg:data id="data.2" metadataIdRef="metadata.2">
+ <nmwg:data id="data.2" metadataIdRef="metadata.2">

- <nmwg:metadata>
- 
- </nmwg:metadata>
+ <nmwg:metadata>
+ 
+ </nmwg:metadata>

- <nmwg:metadata>
- 
- </nmwg:metadata>
+ <nmwg:metadata>
+ 
+ </nmwg:metadata>

- </nmwg:data>
+ </nmwg:data>

- </nmwg:message>
+ </nmwg:message>

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h5 class="title"><a
id="ls_summary_message_lower_response"></a>4.6.2.2. Response</h5></div></div></div>
The response message should indicate success or failure via
@@ -1597,26 +1628,26 @@
</li></ul></div>
<pre class="programlisting">

- <nmwg:message type="LSControlResponse">
+ <nmwg:message type="LSControlResponse">

- 
- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/summary/lower/success</nmwg:eventType>
- </nmwg:metadata>
+ 
+ <nmwg:metadata id="metadata.6">
+ <perfsonar:subject id="subject.6">
+ <psservice:service id="service.6">
+ <psservice:serviceName>Internet2 LS #6</psservice:serviceName>
+ <psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/summary/lower/success</nmwg:eventType>
+ </nmwg:metadata>

- <nmwg:data id="data.6" metadataIdRef="metadata.6">
- <nmwgr:datum value="some sort of message?">
- </nmwg:data>
+ <nmwg:data id="data.6" metadataIdRef="metadata.6">
+ <nmwgr:datum value="some sort of message?">
+ </nmwg:data>

- </nmwg:message>
+ </nmwg:message>

</pre></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a
id="ls_leader_message"></a>4.7. LS Leader Message</h3></div></div></div>
This message exchange will be conducted between the Leader and
@@ -1635,67 +1666,67 @@
well as the summary data.
<pre class="programlisting">

- <nmwg:message type="LSControlRequest">
+ <nmwg:message type="LSControlRequest">

- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/leader</nmwg:eventType>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.6">
+ <perfsonar:subject id="subject.6">
+ <psservice:service id="service.6">
+ <psservice:serviceName>Internet2 LS #6</psservice:serviceName>
+ <psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/leader</nmwg:eventType>
+ </nmwg:metadata>

- <nmwg:data id="data.6" metadataIdRef="metadata.6">
+ <nmwg:data
id="data.6" metadataIdRef="metadata.6">

- 
+ 

- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>ESnet LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://mea1.es.net:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/summary</nmwg:eventType>
- </nmwg:metadata>
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
+ <psservice:serviceName>ESnet LS #2</psservice:serviceName>
+ <psservice:accessPoint>http://mea1.es.net:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ <nmwg:eventType>http://perfsonar.net/services/LS/summary</nmwg:eventType>
+ </nmwg:metadata>

- 
+ 

- <nmwg:data id="data.2" metadataIdRef="metadata.2">
- <nmwg:metadata>
- <summary:subject
xmlns:summary="http://ggf.org/ns/nmwg/summary/2.0/">
- <nmtl3:network>
-
<nmtl3:ipAddress>128.4.10.0/16</nmtl3:ipAddress>
- </nmtl3:network>
- </summary:subject>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- </nmwg:metadata>
+ <nmwg:data id="data.2" metadataIdRef="metadata.2">
+ <nmwg:metadata>
+ <summary:subject
xmlns:summary="http://ggf.org/ns/nmwg/summary/2.0/";>
+ <nmtl3:network>
+ <nmtl3:ipAddress>128.4.10.0/16</nmtl3:ipAddress>
+ </nmtl3:network>
+ </summary:subject>
+ <nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
+ <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
+ <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
+ </nmwg:metadata>

- </nmwg:data>
+ </nmwg:data>

- 
+ 

- </nmwg:data>
+ </nmwg:data>

- </nmwg:message>
+ </nmwg:message>

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="ls_leader_message_response"></a>4.7.2. Response</h4></div></div></div>
The response message will contain the results (success or
failure).
<pre class="programlisting">

- <nmwg:message type="LSControlRequest">
+ <nmwg:message type="LSControlRequest">

- 
+ 

- </nmwg:message>
+ </nmwg:message>

</pre></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="ls_discovery_message"></a>4.8. LS Discovery
Message</h3></div></div></div>
The discovery message represents the step used to find the
@@ -1706,54 +1737,71 @@
section with some identifying features.
<pre class="programlisting">

- <nmwg:message type="LSDiscoveryRequest">
+ <nmwg:message type="LSDiscoveryRequest">

- <nmwg:metadata id="metadata.1">
+ <nmwg:metadata id="metadata.1">

- 
+ 
+ 

- </nmwg:metadata>
+ </nmwg:metadata>

- <nmwg:data id="data.1" metadataIdRef="metadata.1" />
+ <nmwg:data
id="data.1" metadataIdRef="metadata.1" />

- </nmwg:message>
+ </nmwg:message>

</pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="ls_discovery_message_response"></a>4.8.2. Response</h4></div></div></div>
The response message will feature a status message, as described
- in <a href="#system_search_discovery_algorithm">Algorithm</a>.
+ in <a href="#system_search_discovery_algorithm"
title="3.5.1.1. Algorithm">Algorithm</a>.
<pre class="programlisting">

- <nmwg:message type="LSDiscoveryResponse">
+ <nmwg:message type="LSDiscoveryResponse">

- <nmwg:metadata id="metadata.1.r">
- 
- <nmwg:eventType>success</nmwg:eventType>
+ <nmwg:metadata id="metadata.1.r">

- <nmwg:eventType>failure</nmwg:eventType>
+ 
- <nmwgr:datum value="some message" />
+ 
+ <nmwgr:datum value="some message" />

- 
- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
-
<psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- </nmwg:metadata>
+
+ 
+
+ <nmwg:metadata id="metadata.6">
+ <perfsonar:subject id="subject.6">
+ <psservice:service id="service.6">
+ <psservice:serviceName>Internet2 LS #6</psservice:serviceName>
+ <psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
+ <psservice:serviceType>LS</psservice:serviceType>
+ <psservice:serviceDescription>...</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ </nmwg:metadata>

- </nmwg:data>
+ </nmwg:data>

- </nmwg:message>
+ </nmwg:message>

</pre></div></div></div><div class="glossary"><div
class="titlepage"><div><div><h2 class="title"><a
id="glossary"></a>Terms</h2></div></div></div><div class="glossdiv"><h3
class="title">A</h3><dl><dt><a id=""></a></dt><dd>
</dd></dl></div><div class="glossdiv"><h3
class="title">B</h3><dl><dt><a id="Berkeley DB XML"></a>Berkeley DB
XML</dt><dd>
@@ -1786,8 +1834,8 @@
A query language (with some programming language
features) that is designed to query collections of XML data. It
is semantically similar to SQL.
- </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="id905683"></a>[<abbr
class="abbrev">perfSONAR</abbr>] 
+ </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="id2540754"></a>[<abbr
class="abbrev">perfSONAR</abbr>] 
<a href="http://www.perfsonar.net"; target="_top">perfSONAR</a>
- . </div><div class="biblioentry"><a
id="id905701"></a>[<abbr class="abbrev">XML</abbr>] 
+ . </div><div class="biblioentry"><a
id="id2540773"></a>[<abbr class="abbrev">XML</abbr>] 
<a href="http://www.w3.org/XML"; target="_top">Extensible Markup
Language (XML)</a>
. </div></div></div></body></html>

nmwg: r336 - trunk/nmwg/doc/dLS, svnlog, 04/04/2008

List archive

nmwg: r336 - trunk/nmwg/doc/dLS