perfsonar-dev - nmwg: r361 - in trunk/nmwg/doc/dLS/gLS: . examples

Subject: perfsonar development work

List archive

nmwg: r361 - in trunk/nmwg/doc/dLS/gLS: . examples

From:
To: ,
Subject: nmwg: r361 - in trunk/nmwg/doc/dLS/gLS: . examples
Date: Sun, 15 Jun 2008 22:41:55 -0400

Author: zurawski
Date: 2008-06-15 22:41:55 -0400 (Sun, 15 Jun 2008)
New Revision: 361

Added:
trunk/nmwg/doc/dLS/gLS/examples/discovery_ex.xml
trunk/nmwg/doc/dLS/gLS/examples/discovery_ex_resp.xml
Modified:
trunk/nmwg/doc/dLS/gLS/phase_1.html
trunk/nmwg/doc/dLS/gLS/phase_1.xml
trunk/nmwg/doc/dLS/gLS/phase_1_color.html
Log:
Adding in additional language about Discovery Queries.

-jason

Added: trunk/nmwg/doc/dLS/gLS/examples/discovery_ex.xml

Added: trunk/nmwg/doc/dLS/gLS/examples/discovery_ex_resp.xml

Modified: trunk/nmwg/doc/dLS/gLS/phase_1.html
===================================================================
--- trunk/nmwg/doc/dLS/gLS/phase_1.html 2008-06-09 13:58:42 UTC (rev 360)
+++ trunk/nmwg/doc/dLS/gLS/phase_1.html 2008-06-16 02:41:55 UTC (rev 361)
@@ -1,7 +1,7 @@
<?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>dLS
Implementation Phase 1 -- The Rise of the gLS</title><meta name="generator"
content="DocBook XSL Stylesheets V1.71.0" /></head><body><div class="article"
lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a
id="id2478927"></a>dLS Implementation Phase 1 -- The Rise of the
gLS</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Boote</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Glowiak</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Swany</span></h3></div><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Zurawski</span></h3></div></div></div></div><hr /></div><div
class="
toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a
href="#changes">1. Document Changes</a></span></dt><dt><span
class="section"><a href="#introduction">2.
Introduction</a></span></dt><dt><span class="section"><a
href="#architecture">3. Architecture</a></span></dt><dd><dl><dt><span
class="section"><a href="#gLS_instances">3.1. gLS
Instances</a></span></dt><dt><span class="section"><a
href="#bootstrapping">3.2. Bootstrapping</a></span></dt><dt><span
class="section"><a href="#synchronization">3.3.
Synchronization</a></span></dt><dt><span class="section"><a
href="#hLS_instances">3.4. hLS Instances</a></span></dt><dt><span
class="section"><a href="#registration">3.5. Multiple
Registration</a></span></dt><dt><span class="section"><a
href="#interaction">3.6. Interaction</a></span></dt></dl></dd><dt><span
class="section"><a href="#api">4. API</a></span></dt><dd><dl><dt><span
class="section"><a href="#level0_api">4.1. Level 0
API</a></span></dt><dt><span class="sect
ion"><a href="#level1_api">4.2. Level 1 API</a></span></dt><!
dd><dl><
dt><span class="section"><a href="#level1_api_ext">4.2.1. Level 1 API
Extension</a></span></dt></dl></dd><dt><span class="section"><a
href="#level2_api">4.3. Level 2 API</a></span></dt><dd><dl><dt><span
class="section"><a href="#level2_api_ext">4.3.1. Level 2 API
Extension</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#operation">5. Operation</a></span></dt><dt><span class="section"><a
href="#implementation">6. Implementation</a></span></dt><dd><dl><dt><span
class="section"><a href="#implementation_general">6.1. Overall
Considerations</a></span></dt><dt><span class="section"><a
href="#implementation_java">6.2. Java Considerations</a></span></dt><dt><span
class="section"><a href="#implementation_perl">6.3. Perl
Considerations</a></span></dt><dd><dl><dt><span class="section"><a
href="#implementation_perl_mode">6.3.1. gLS and hLS Operation
Differences</a></span></dt><dt><span class="section"><a
href="#implementation_perl_summarization">6.3.2. Summarizing
Registered Data</a></span></dt><dt><span class="section"><a
href="#implementation_perl_storage">6.3.3. Storage
Reorganization</a></span></dt><dt><span class="section"><a
href="#implementation_perl_registration">6.3.4. Multiple and Self
Registration</a></span></dt><dt><span class="section"><a
href="#implementation_perl_ets">6.3.5.
EventTypes</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#appendix">7. Appendix</a></span></dt><dd><dl><dt><span
class="section"><a href="#appendix_summary">7.1. Summary Message
Example</a></span></dt><dt><span class="section"><a
href="#appendix_summarization_source">7.2. Summarization Source
Code</a></span></dt><dd><dl><dt><span class="section"><a
href="#appendix_summarization_source_java">7.2.1. Summarization Source Code
(Java)</a></span></dt><dt><span class="section"><a
href="#appendix_summarization_source_perl">7.2.2. Summarization Source Code
(Perl)</a></span></dt></dl></dd><dt><span class="section"><a
href="#appendix_sy
nch">7.3. Synchronization Example</a></span></dt></dl></dd><!
dt><span
class="glossary"><a href="#glossary">Terms</a></span></dt><dt><span
class="bibliography"><a
href="#bibliography">References</a></span></dt></dl></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2
class="title" style="clear: both"><a id="changes"></a>1. Document
Changes</h2></div></div></div><div class="table"><a id="table.1"></a><p
class="title"><b>Table 1. Change Log</b></p><div
class="table-contents"><table summary="Change Log" border="1"><colgroup><col
align="left" /></colgroup><thead><tr><th align="left">Version</th><th
align="left">Date</th><th align="left">Description</th><th
align="left">Author(s)</th></tr></thead><tbody><tr><td
align="left">1.00</td><td align="left">05/11/2007</td><td
align="left">Initial Preparation</td><td align="left">J.
Zurawski</td></tr><tr><td align="left">1.01</td><td
align="left">05/18/2007</td><td align="left">EventType Clarifications</td><td
align="left">J. Zurawski</td></tr><tr><td align="left">1.02</
td><td align="left">05/20/2007</td><td align="left">Summarization
Clarification/Algorithm Change</td><td align="left">J.
Zurawski</td></tr></tbody></table></div></div><br class="table-break"
/></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="introduction"></a>2. Introduction</h2></div></div></div><p>
- This document builds upon the work described in <a
href="#id2531864">dLS Design Document</a>
+<html xmlns="http://www.w3.org/1999/xhtml";><head><meta
http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>dLS
Implementation Phase 1 -- The Rise of the gLS</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="id2486755"></a>dLS Implementation Phase 1 -- The Rise of the
gLS</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Boote</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Glowiak</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Swany</span></h3></div><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Zurawski</span></h3></div></div></div></div><hr /></div><div
class="
toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a
href="#changes">1. Document Changes</a></span></dt><dt><span
class="section"><a href="#introduction">2.
Introduction</a></span></dt><dt><span class="section"><a
href="#preliminaries">3. Preliminaries</a></span></dt><dd><dl><dt><span
class="section"><a href="#preliminaries-service">3.1. Service
Definition</a></span></dt><dt><span class="section"><a
href="#preliminaries-registration">3.2. Registration</a></span></dt><dt><span
class="section"><a href="#preliminaries-prop">3.3. Information
Dissemination</a></span></dt></dl></dd><dt><span class="section"><a
href="#architecture">4. Architecture</a></span></dt><dd><dl><dt><span
class="section"><a href="#gLS_instances">4.1. gLS
Instances</a></span></dt><dt><span class="section"><a
href="#bootstrapping">4.2. Bootstrapping</a></span></dt><dt><span
class="section"><a href="#synchronization">4.3.
Synchronization</a></span></dt><dt><span class="section"><a href="#hLS_in
stances">4.4. hLS Instances</a></span></dt><dt><span class="!
section"
><a href="#registration">4.5. Multiple Registration</a></span></dt><dt><span
>class="section"><a href="#interaction">4.6.
>Interaction</a></span></dt></dl></dd><dt><span class="section"><a
>href="#api">5. API</a></span></dt><dd><dl><dt><span class="section"><a
>href="#level0_api">5.1. Level 0 API</a></span></dt><dt><span
>class="section"><a href="#level1_api">5.2. Level 1
>API</a></span></dt><dd><dl><dt><span class="section"><a
>href="#level1_api_ext">5.2.1. Level 1 API
>Extension</a></span></dt></dl></dd><dt><span class="section"><a
>href="#level2_api">5.3. Level 2 API</a></span></dt><dd><dl><dt><span
>class="section"><a href="#level2_api_ext">5.3.1. Level 2 API
>Extension</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
>href="#operation">6. Operation</a></span></dt><dt><span class="section"><a
>href="#implementation">7. Implementation</a></span></dt><dd><dl><dt><span
>class="section"><a href="#implementation_general">7.1. Overall
>Considerations</a></span></dt><dt><span cl
ass="section"><a href="#implementation_java">7.2. Java
Considerations</a></span></dt><dt><span class="section"><a
href="#implementation_perl">7.3. Perl
Considerations</a></span></dt><dd><dl><dt><span class="section"><a
href="#implementation_perl_mode">7.3.1. gLS and hLS Operation
Differences</a></span></dt><dt><span class="section"><a
href="#implementation_perl_summarization">7.3.2. Summarizing Registered
Data</a></span></dt><dt><span class="section"><a
href="#implementation_perl_storage">7.3.3. Storage
Reorganization</a></span></dt><dt><span class="section"><a
href="#implementation_perl_registration">7.3.4. Multiple and Self
Registration</a></span></dt><dt><span class="section"><a
href="#implementation_perl_ets">7.3.5.
EventTypes</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#appendix">8. Appendix</a></span></dt><dd><dl><dt><span
class="section"><a href="#appendix_summary">8.1. Summary Message
Example</a></span></dt><dt><span class="section"><a href=
"#appendix_summary_request">8.2. LSQuery Request (Discovery)!
Example
</a></span></dt><dt><span class="section"><a
href="#appendix_summary_response">8.3. LSQuery Response (Discovery)
Example</a></span></dt><dt><span class="section"><a
href="#appendix_summarization_source">8.4. Summarization Source
Code</a></span></dt><dd><dl><dt><span class="section"><a
href="#appendix_summarization_source_java">8.4.1. Summarization Source Code
(Java)</a></span></dt><dt><span class="section"><a
href="#appendix_summarization_source_perl">8.4.2. Summarization Source Code
(Perl)</a></span></dt></dl></dd><dt><span class="section"><a
href="#appendix_synch">8.5. Synchronization
Example</a></span></dt></dl></dd><dt><span class="glossary"><a
href="#glossary">Terms</a></span></dt><dt><span class="bibliography"><a
href="#bibliography">References</a></span></dt></dl></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2
class="title" style="clear: both"><a id="changes"></a>1. Document
Changes</h2></div></div></div><div class="table"><a id
="table.1"></a><p class="title"><b>Table 1. Change Log</b></p><div
class="table-contents"><table summary="Change Log" border="1"><colgroup><col
align="left" /></colgroup><thead><tr><th align="left">Version</th><th
align="left">Date</th><th align="left">Description</th><th
align="left">Author(s)</th></tr></thead><tbody><tr><td
align="left">1.00</td><td align="left">05/11/2007</td><td
align="left">Initial Preparation</td><td align="left">J.
Zurawski</td></tr><tr><td align="left">1.01</td><td
align="left">05/18/2007</td><td align="left">EventType Clarifications</td><td
align="left">J. Zurawski</td></tr><tr><td align="left">1.02</td><td
align="left">05/20/2007</td><td align="left">Summarization
Clarification/Algorithm Change</td><td align="left">J.
Zurawski</td></tr><tr><td align="left">1.03</td><td
align="left">06/12/2007</td><td align="left">LSRegistration
Primer/Development Lessons Learned</td><td align="left">J.
Zurawski</td></tr></tbody></table></div></div><br class="tabl
e-break" /></div><div class="section" lang="en" xml:lang="en!
"><div c
lass="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="introduction"></a>2. Introduction</h2></div></div></div><p>
+ This document builds upon the work described in [<a
href="#id2542823"><span class="citation">dLS</span></a>]
to create <span><strong class="command">Phase 1</strong></span> of the
proposed distributed
information service. This document will describe concrete details of
the
plan, prescribing both the overall structure of the system as well as
@@ -25,54 +25,66 @@
information.
</p><p>
The remainder of the document is structured as follows:
- <a href="#architecture">Architecture</a> will go into details of the
system as
- viewed from afar. Issues such as communication and individual service
- behavior will be discussed. <a href="#api">API</a> will describe the
- interface service developers will implement to interact with this
system.
- <a href="#operation">Operation</a> will lay out some common use cases
and
- examples. <a href="#implementation">Implementation</a> will discuss
some
- algorithms and specific considerations that the both reference
- implementations will need to take into account. Finally
- <a href="#appendix">Appendix</a> details some XML and code examples to
be used
- in the construction of this service.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="architecture"></a>3. Architecture</h2></div></div></div><p>
+ in <a href="#preliminaries" title="3. Preliminaries">Preliminaries</a>
the basics of LSRegistration for
+ services will be briefly discussed. <a href="#architecture"
title="4. Architecture">Architecture</a> will
+ go into details of the system as viewed from afar. Issues such as
+ communication and individual service behavior will be discussed.
+ <a href="#api" title="5. API">API</a> will describe the interface
service developers will
+ implement to interact with this system. <a href="#operation"
title="6. Operation">Operation</a> will
+ lay out some common use cases and examples.
+ <a href="#implementation" title="7. Implementation">Implementation</a>
will discuss some algorithms and
+ specific considerations that the both reference implementations will
need
+ to take into account. Finally <a href="#appendix"
title="8. Appendix">Appendix</a> details some
+ XML and code examples to be used in the construction of this service.
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="preliminaries"></a>3. Preliminaries</h2></div></div></div><p>
+ To motivate the discussion of a <span
class="emphasis"><em>Global</em></span> resource
+ discovery system, we must first mention the resources that are
available
+ and the steps they <span class="emphasis"><em>must</em></span> take to
make themselves known
+ to the framework at large. We will first begin in
+ <a href="#preliminaries-service" title="3.1. Service
Definition">Service Definition</a> with a discussion of what defines
+ a <span class="emphasis"><em>perfSONAR</em></span> service.
+ <a href="#preliminaries-registration"
title="3.2. Registration">Registration</a> talks about a minimum set of
+ necessary information that can be used to idenfity and describe a
service.
+ Finally, <a href="#preliminaries-prop" title="3.3. Information
Dissemination">Information Dissemination</a> explores what is desirable
+ for spreading this information to interested parties.
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="preliminaries-service"></a>3.1. Service
Definition</h3></div></div></div><p>TBD</p></div><div class="section"
lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a
id="preliminaries-registration"></a>3.2. Registration</h3></div></div></div><p>TBD</p></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3
class="title"><a id="preliminaries-prop"></a>3.3. Information
Dissemination</h3></div></div></div><p>TBD</p></div></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2
class="title" style="clear: both"><a
id="architecture"></a>4. Architecture</h2></div></div></div><p>
The following schematic shows the overall architecture of this system.
</p><p>
</p><div class="mediaobject"><img src="images/architecture.png"
/></div><p>
</p><p>
We will now explain some key features of this architecture:
</p><p>
- </p><div class="orderedlist"><ol type="1"><li><p><a
href="#gLS_instances">gLS Instances</a> - Global,
+ </p><div class="orderedlist"><ol type="1"><li><p><a
href="#gLS_instances" title="4.1. gLS Instances">gLS Instances</a> - Global,
<span class="emphasis"><em>well known</em></span>, LS instances
that will serve as
the <span class="emphasis"><em>top level</em></span> of the
hierarchy. Under normal
conditions <span><strong class="command">only</strong></span>
manage the registration of
<span class="emphasis"><em>hLS</em></span> instances and not other
forms of
- <span class="emphasis"><em>perfSONAR</em></span>
service.</p></li><li><p><a href="#bootstrapping">Bootstrapping</a> - Finding
gLS instances can
+ <span class="emphasis"><em>perfSONAR</em></span>
service.</p></li><li><p><a href="#bootstrapping"
title="4.2. Bootstrapping">Bootstrapping</a> - Finding gLS instances can
be challenging, and we <span><strong class="command">should
not</strong></span> rely only on
well known values. We propose a simple method for this
implementation
phase that will allow other <span
class="emphasis"><em>gLS</em></span> instances,
<span class="emphasis"><em>hLS</em></span>s, and anyone using the
API a chance to
find and communicate with root <span
class="emphasis"><em>gLS</em></span> instances.
- </p></li><li><p><a href="#synchronization">Synchronization</a> -
To ease the burden of
+ </p></li><li><p><a href="#synchronization"
title="4.3. Synchronization">Synchronization</a> - To ease the burden of
discovery, the top level <span
class="emphasis"><em>gLS</em></span> instances should
regularly synchronize their summary sets to ensure that any
discovery
query posed anywhere in the framework can be answered correctly.
- </p></li><li><p><a href="#hLS_instances">hLS Instances</a> - Local
LS instances that
+ </p></li><li><p><a href="#hLS_instances" title="4.4. hLS
Instances">hLS Instances</a> - Local LS instances that
manage the registration of individual services and communicate a
- summary of information to the upper level.</p></li><li><p><a
href="#registration">Multiple Registration</a> - Services may require
+ summary of information to the upper level.</p></li><li><p><a
href="#registration" title="4.5. Multiple Registration">Multiple
Registration</a> - Services may require
modifications to support interaction with more than one LS
instance to
foster both reliability and balancing of load.
- </p></li><li><p><a href="#interaction">Interaction</a> - To use
this new framework,
+ </p></li><li><p><a href="#interaction"
title="4.6. Interaction">Interaction</a> - To use this new framework,
clients and services require a unified access method. This access
requires two components: Discovery (e.g. <span
class="emphasis"><em>where</em></span>
information can be found) and Query (e.g. <span
class="emphasis"><em>what</em></span>
specifically can I find).</p></li></ol></div><p>
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="gLS_instances"></a>3.1. gLS Instances</h3></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="gLS_instances"></a>4.1. gLS Instances</h3></div></div></div><p>
The <span class="emphasis"><em>perfSONAR</em></span> project
partners (e.g.
- <a href="#id2531884">ESnet</a>, <a href="#id2531902">Geant2</a>,
- <a href="#id2531920">Internet2</a>, and <a
href="#id2532214">RNP</a>) are
+ [<a href="#id2542842"><span class="citation">ESnet</span></a>], [<a
href="#id2542860"><span class="citation">Geant2</span></a>],
+ [<a href="#id2542879"><span class="citation">Internet2</span></a>],
and [<a href="#id2542898"><span class="citation">RNP</span></a>]) are
expected to stand up and maintain <span
class="emphasis"><em>root</em></span>
- <a href="#gLS">gLS</a> instances. As the driving force behind
+ <a href="#gLS" title="gLS">gLS</a> instances. As the driving force
behind
<span class="emphasis"><em>perfSONAR</em></span>, this contribution
serves as the basis
for all distributed information discovery. The purpose of these LS
instances is similar to the function of the DNS root servers: well
known
@@ -97,15 +109,15 @@
point of contact with regards to locating information; therefore
each
root should know the complete contents at any given time. To
accomplish
the goals of <span class="emphasis"><em>gLS</em></span> discovery we
rely on some
- <a href="#bootstrapping">Bootstrapping</a> techniques that allow
service and
+ <a href="#bootstrapping"
title="4.2. Bootstrapping">Bootstrapping</a> techniques that allow service and
client applications alike the ability to access the
<span class="emphasis"><em>upper layer</em></span> consisting of
<span class="emphasis"><em>gLS</em></span>
deployments. To ensure that <span
class="emphasis"><em>gLS</em></span> instances are
- relevant, an additional data <a
href="#synchronization">Synchronization</a> step is
+ relevant, an additional data <a href="#synchronization"
title="4.3. Synchronization">Synchronization</a> step is
also required.
</p><p>
- The <a href="#bootstrapping">Bootstrapping</a> and
- <a href="#synchronization">Synchronization</a> ensure that a
+ The <a href="#bootstrapping"
title="4.2. Bootstrapping">Bootstrapping</a> and
+ <a href="#synchronization"
title="4.3. Synchronization">Synchronization</a> ensure that a
<span class="emphasis"><em>Discovery</em></span> query posed to any
root is able to be
completed. In addition to the process to propagate registration
information through <span
class="emphasis"><em>synchronization</em></span> the
@@ -127,7 +139,7 @@
any summarization and discovery activities (unless the
<span class="emphasis"><em>gLS</em></span> summarizes itself, and is
able to include this
information in the discovery phase).
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="bootstrapping"></a>3.2. Bootstrapping</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="bootstrapping"></a>4.2. Bootstrapping</h3></div></div></div><p>
The deployment locations of the <span
class="emphasis"><em>gLS</em></span> may be broadly
known, but the specific contact information will probably not be. It
will be necessary for the <span class="emphasis"><em>gLS</em></span>
instances,
@@ -159,7 +171,7 @@
It is expected that the first option will be implemented immediately,
with the prospects of the second option to follow. The third option
will be depend on participation from the perfSONAR partners.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="synchronization"></a>3.3. Synchronization</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="synchronization"></a>4.3. Synchronization</h3></div></div></div><p>
There are two possible approaches to information discovery using the
<span class="emphasis"><em>gLS</em></span> deployment scenario.
</p><p>
@@ -195,9 +207,9 @@
overloading <span class="emphasis"><em>gLS</em></span> instances or
if it may be able to
function as an on-demand service when new summarizations are
available.
</p><p>
- See <a href="#appendix_synch">Synchronization Example</a> for an
example of a naive
+ See <a href="#appendix_synch" title="8.5. Synchronization
Example">Synchronization Example</a> for an example of a naive
synchronization between LS instances.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="hLS_instances"></a>3.4. hLS Instances</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="hLS_instances"></a>4.4. hLS Instances</h3></div></div></div><p>
This service resembles the current LS implementation. Aside from the
changes that allow the <span class="emphasis"><em>hLS</em></span>
itself to register with
a <span class="emphasis"><em>gLS</em></span> and the addition of the
API, there is little
@@ -235,7 +247,7 @@
incorporate the <span class="emphasis"><em>Patricia
Trie</em></span> data structure to
naively find <span class="emphasis"><em>K Dominators</em></span>
from a list of
addresses. See also
- <a href="#appendix_summarization_source">Summarization Source
Code</a>.</p></li><li style="list-style-type: circle"><p><span><strong
class="command">Host/Domain Names</strong></span> - Similar to IP
+ <a href="#appendix_summarization_source"
title="8.4. Summarization Source Code">Summarization Source
Code</a>.</p></li><li style="list-style-type: circle"><p><span><strong
class="command">Host/Domain Names</strong></span> - Similar to IP
Addresses, the hostname of each service will be extracted and
broken into sub elements (e.g.
<span class="emphasis"><em>stout.pc.cis.udel.edu</em></span> is
really an
@@ -264,7 +276,7 @@
due to code reuse it is understood that any given deployment may be a
<span class="emphasis"><em>gLS</em></span> or <span
class="emphasis"><em>hLS</em></span> so the necessary
tooling to do either approach would be available.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="registration"></a>3.5. Multiple Registration</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="registration"></a>4.5. Multiple Registration</h3></div></div></div><p>
The following diagram illustrates the procedure of an
<span class="emphasis"><em>hLS</em></span> instance registering with
two distinct
<span class="emphasis"><em>gLS</em></span> instances.
@@ -291,10 +303,10 @@
</p><p>
We leave the option of multiple registration up to the individual
service designers.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="interaction"></a>3.6. Interaction</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="interaction"></a>4.6. Interaction</h3></div></div></div><p>
Currently, services and clients only have a single way to query an
- <span class="emphasis"><em>LS</em></span> instance for data: <a
href="#id2532250">XQuery</a>
- or <a href="#id2532232">XPath</a> statements. While useful to
individuals
+ <span class="emphasis"><em>LS</em></span> instance for data: [<a
href="#id2542934"><span class="citation">XQuery</span></a>]
+ or [<a href="#id2542915"><span class="citation">XPath</span></a>]
statements. While useful to individuals
with an intimate knowledge of the data storage structure and the
query
language syntax, this leaves other services and client applications
frustrated and out of luck when it comes to lookup.
@@ -325,8 +337,8 @@
range, eventType, or other specific features that pertain to the
data and service type.</p></li></ul></div><p>
</p><p>
- The API will be specified in <a href="#api">API</a>.
- </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="api"></a>4. API</h2></div></div></div><p>
+ The API will be specified in <a href="#api" title="5. API">API</a>.
+ </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="api"></a>5. API</h2></div></div></div><p>
To effectively navigate through the distributed information service, an
effective and complete API is necessary. This API should offer ways
to
perform two important tasks (together, and separately as needed):
@@ -355,15 +367,16 @@
lower level functionality that is able to expose more primitive
operations
should remain available. The following breakdown isolates the various
functions:
- </p><div class="table"><a id="table.2"></a><p
class="title"><b>Table 2. LS API</b></p><div class="table-contents"><table
summary="LS API" border="1"><colgroup><col align="left"
/></colgroup><thead><tr><th align="left">API Level</th><th
align="left">Message Type</th><th align="left">Event Type</th><th
align="left">Input</th><th align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td rowspan="4"
align="center" valign="middle"><a href="#level0_api">0</a></td><td
rowspan="8" align="left" valign="middle">LSQueryRequest</td><td
align="left">service.lookup.xquery</td><td rowspan="4" align="left"
valign="middle">XQuery</td><td rowspan="4" align="left" valign="middle">Raw
XML</td><td rowspan="4" align="left" valign="middle">Most primitive
call.</td></tr><tr><td
align="left">http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/xquery/1.0</td></tr><tr><td

align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td>
</tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td></tr><tr><td
rowspan="2" align="center" valign="middle"><a
href="#level1_api">1</a></td><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td><td
align="left">IP, Domain, eventType, Service Data</td><td align="left">hLS
URL Array</td><td align="left">Standalone Discovery</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td><td
align="left">hLS, IP, Domain, eventType, Service Data</td><td
align="left">Metadata (e.g. Service/Measurement based) Array</td><td
align="left">Standalone Query</td></tr><tr><td rowspan="2" align="center"
valign="middle"><a href="#level2_api">2</a></td><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td><td
rowspan="2" align="left" valign="middle">IP, Domain, eventType, Service
Data</td><td rowspan="2"
align="left" valign="middle">Metadata (e.g. Service/Measure!
ment bas
ed) Array</td><td rowspan="2" align="left" valign="middle">Complete
Discovery/Query</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td></tr></tbody></table></div></div><br
class="table-break" /><p>
+ </p><div class="table"><a id="table.2"></a><p
class="title"><b>Table 2. LS API</b></p><div class="table-contents"><table
summary="LS API" border="1"><colgroup><col align="left"
/></colgroup><thead><tr><th align="left">API Level</th><th
align="left">Message Type</th><th align="left">Event Type</th><th
align="left">Input</th><th align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td rowspan="4"
align="center" valign="middle"><a href="#level0_api" title="5.1. Level 0
API">0</a></td><td rowspan="10" align="left"
valign="middle">LSQueryRequest</td><td
align="left">service.lookup.xquery</td><td rowspan="4" align="left"
valign="middle">XQuery</td><td rowspan="4" align="left" valign="middle">Raw
XML</td><td rowspan="4" align="left" valign="middle">Most primitive
call.</td></tr><tr><td
align="left">http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/xquery/1.0</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/looku
p/discovery/xquery/2.0</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td></tr><tr><td
rowspan="3" align="center" valign="middle"><a href="#level1_api"
title="5.2. Level 1 API">1</a></td><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td><td
rowspan="2" align="left" valign="middle">IP, Domain, eventType, Service
Data</td><td rowspan="2" align="left" valign="middle">hLS URL Array</td><td
rowspan="2" align="left" valign="middle">Standalone
Discovery</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</td></tr><tr><td

align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td><td
align="left">hLS, IP, Domain, eventType, Service Data</td><td
align="left">Metadata (e.g. Service/Measurement based) Array</td><td
align="left">Standalone Query</td></tr><tr><td rowspan="3" align="center" v
align="middle"><a href="#level2_api" title="5.3. Level 2 AP!
I">2</a>
</td><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td><td
rowspan="3" align="left" valign="middle">IP, Domain, eventType, Service
Data</td><td rowspan="3" align="left" valign="middle">Metadata (e.g.
Service/Measurement based) Array</td><td rowspan="3" align="left"
valign="middle">Complete Discovery/Query</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td></tr><tr><td

align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</td></tr></tbody></table></div></div><br
class="table-break" /><p>
We will now explain in greater detail the expected format of the API
for
the various levels, including function names, parameter lists, as well
as expected behaviors.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level0_api"></a>4.1. Level 0 API</h3></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level0_api"></a>5.1. Level 0 API</h3></div></div></div><p>
The Level 0 API is based on the current query method used in the
<span class="emphasis"><em>LS</em></span>: <span><strong
class="command">LSQueryRequest</strong></span> messages
- sending a raw <span><strong class="command">XQuery</strong></span>
string. We would like to keep
- this base functionality for two reasons:
+ sending a raw <span><strong class="command">XQuery</strong></span>
string sent directly to the
+ LSQuery interface. We would like to keep this base functionality for
+ two reasons:
</p><p>
</p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p>
This method will serve as the base that upper levels of this
API
@@ -376,7 +389,7 @@
</p><p>
There are only minor modifications that must be made to the existing
<span><strong class="command">LSQueryRequest</strong></span>
functionality, mainly the addition of
- two new <span class="emphasis"><em>eventType</em></span>s. These
+ three new <span class="emphasis"><em>eventType</em></span>s. These
<span class="emphasis"><em>eventType</em></span>s will not only help
this level isolate
the specific dataset to query, but provided needed functionality to
the
abstractions built on top of Level 0:
@@ -391,14 +404,14 @@
backend storage holding registered information.
</p></li></ul></div><p>
</p><p>
- These <span class="emphasis"><em>eventType</em></span>s are more of
an
+ These two <span class="emphasis"><em>eventType</em></span>s are more
of an
<span class="emphasis"><em>ease of design</em></span> feature for
the implementers of the
<span class="emphasis"><em>gLS</em></span> and <span
class="emphasis"><em>hLS</em></span> due to the nature
of the backend storage mechanisms. The existing
<span class="emphasis"><em>eventType</em></span>s, as well as
message structure regarding
subject and parameters, will remain unchanged.
</p><p>
- Addtional considerations for this level of the API revolve around the
+ Additional considerations for this level of the API revolve around
the
internal representation of when data is set to expire, namely the
<span class="emphasis"><em>LS*-control</em></span> structure. It is
desirable to
have access to this when providing status reports about registered
@@ -415,8 +428,13 @@
backend storage holding registered control information.
</p></li></ul></div><p>
</p><p>
- An API breakdown follows:
- </p><div class="table"><a id="table.api.l0"></a><p
class="title"><b>Table 3. Level 0 API Calls</b></p><div
class="table-contents"><table summary="Level 0 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSDiscoveryRaw</td><td rowspan="2" align="left"
valign="middle">LS & XQuery String</td><td rowspan="2" align="left"
valign="middle">Raw XML (e.g. XML elements in an array)</td><td
align="left">Send XQuery for results in the <span
class="emphasis"><em>Summary</em></span> storage only.</td></tr><tr><td
align="left">getLSQueryRaw</td><td align="left">Send XQuery for results in
the <span class="emphasis"><em>Registered</em></span> storage
only.</td></tr><tr><td align="left">getLSSummaryControlRaw</td><td
rowspan="2" align="left" valign="middle">LS & XQuery String</td><td
rowspan=
"2" align="left" valign="middle">Raw XML (e.g. XML elements in an
array)</td><td align="left">Send XQuery for results from the <span
class="emphasis"><em>Summary</em></span> control storage
only.</td></tr><tr><td align="left">getLSRegistrationControlRaw</td><td
align="left">Send XQuery for results from the <span
class="emphasis"><em>Registered</em></span> control storage
only.</td></tr></tbody></table></div></div><br class="table-break"
/></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level1_api"></a>4.2. Level 1 API</h3></div></div></div><p>
+ While desirable, these two <span
class="emphasis"><em>eventType</em></span>s remain
+ optional and services should report their ability to use or not use
them
+ when queried.
+ </p><p>
+ An implementation of an API to access this data can be broken down as
+ follows:
+ </p><div class="table"><a id="table.api.l0"></a><p
class="title"><b>Table 3. Level 0 API Calls</b></p><div
class="table-contents"><table summary="Level 0 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSDiscoveryRaw</td><td rowspan="2" align="left"
valign="middle">LS & XQuery String</td><td rowspan="2" align="left"
valign="middle">Raw XML (e.g. XML elements in an array)</td><td
align="left">Send XQuery for results in the <span
class="emphasis"><em>Summary</em></span> storage only.</td></tr><tr><td
align="left">getLSQueryRaw</td><td align="left">Send XQuery for results in
the <span class="emphasis"><em>Registered</em></span> storage
only.</td></tr><tr><td align="left">getLSSummaryControlRaw</td><td
rowspan="2" align="left" valign="middle">LS & XQuery String</td><td
rowspan=
"2" align="left" valign="middle">Raw XML (e.g. XML elements in an
array)</td><td align="left">Send XQuery for results from the <span
class="emphasis"><em>Summary</em></span> control storage
only.</td></tr><tr><td align="left">getLSRegistrationControlRaw</td><td
align="left">Send XQuery for results from the <span
class="emphasis"><em>Registered</em></span> control storage
only.</td></tr></tbody></table></div></div><br class="table-break"
/></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level1_api"></a>5.2. Level 1 API</h3></div></div></div><p>
The Level 1 API offers a the first true way of abstracting the
queries
to the LS by identifying a series of well defined parameters as input
as well as structured output. This particular portion of the API
will
@@ -426,13 +444,44 @@
level will not require any additional modifications to be made to the
<span><strong class="command">LSQueryRequest</strong></span>, as it
will utilize Level 0 API calls.
</p><p>
- An API breakdown follows:
- </p><div class="table"><a id="table.api.l1"></a><p
class="title"><b>Table 4. Level 1 API Calls</b></p><div
class="table-contents"><table summary="Level 1 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSDiscovery</td><td align="left">(IP Address | Domain) |
eventType | Service Type</td><td align="left">hLS URL Array</td><td
align="left">Given several input parameters, return a list of <span
class="emphasis"><em>hLS</em></span>s</td></tr><tr><td
align="left">getLSQueryLocation</td><td rowspan="2" align="left"
valign="left">hLS & ((IP Address | Domain) | eventType | Service
Type)</td><td align="left">Service Metadata Array</td><td align="left">Given
several input parameters, return a list of <span
class="emphasis"><em>Service</em></span> metadata elements.</td></tr><tr><td
align
="left">getLSQueryContent</td><td align="left">Measurement Metadata
Array</td><td align="left">Given several input parameters, return a list of
<span class="emphasis"><em>Measurement</em></span> metadata
elements.</td></tr></tbody></table></div></div><br class="table-break" /><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4
class="title"><a id="level1_api_ext"></a>4.2.1. Level 1 API
Extension</h4></div></div></div><p>
+ In addition to the aforementioned <span
class="emphasis"><em>XQuery</em></span>
+ interfaces from <span><strong class="command">Level
0</strong></span>, it is desirable to create
+ a higher level Message that has direct access to the summarized
+ information, without needing to worry about the exact structure
+ (<span><strong class="command">N.B.</strong></span> this allows
implementations the ability
+ to construct higher speed caching and summarization procedures that
do
+ not need to involve <span class="emphasis"><em>XML</em></span>). We
introduce a new
+ evnet type that serves as a conduit to this particular interface:
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</strong></span>
+ An example message that takes advantage can be seen in
+ <a href="#appendix_summary_request" title="8.2. LSQuery Request
(Discovery) Example">LSQuery Request (Discovery) Example</a>. The response
to this
+ message can be seen in <a href="#appendix_summary_response"
title="8.3. LSQuery Response (Discovery) Example">LSQuery Response
(Discovery) Example</a>.
+ </p><p>
+ The following <span class="emphasis"><em>eventType</em></span>s are
used in this Level of
+ the API:
+ </p><p>
+ </p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/control/xquery/2.0</strong></span>
+ - Discussed in <a href="#level0_api" title="5.1. Level 0
API">0</a>
+ </p></li><li style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/control/xquery/2.0</strong></span>
+ - Discussed in <a href="#level0_api" title="5.1. Level 0
API">0</a>
+ </p></li><li style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</strong></span>
+ - Allows a specially crafted query (independent of
+ <span class="emphasis"><em>XQuery</em></span> language) to
query the summarized dataset
+ of a gLS (or in some cases an hLS, although this is less
common).
+ </p></li></ul></div><p>
+ </p><p>
+ An implementation of an API to access this data can be broken down as
+ follows:
+ </p><div class="table"><a id="table.api.l1"></a><p
class="title"><b>Table 4. Level 1 API Calls</b></p><div
class="table-contents"><table summary="Level 1 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSDiscovery</td><td align="left">(IP Address | Domain) |
eventType | Service Type</td><td align="left">hLS URL Array</td><td
align="left">Given several input parameters, return a list of <span
class="emphasis"><em>hLS</em></span>s</td></tr><tr><td
align="left">getLSQueryLocation</td><td rowspan="2" align="left"
valign="left">hLS & ((IP Address | Domain) | eventType | Service
Type)</td><td align="left">Service Metadata Array</td><td align="left">Given
several input parameters, return a list of <span
class="emphasis"><em>Service</em></span> metadata elements.</td></tr><tr><td
align
="left">getLSQueryContent</td><td align="left">Measurement Metadata
Array</td><td align="left">Given several input parameters, return a list of
<span class="emphasis"><em>Measurement</em></span> metadata
elements.</td></tr></tbody></table></div></div><br class="table-break" /><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4
class="title"><a id="level1_api_ext"></a>5.2.1. Level 1 API
Extension</h4></div></div></div><p>
The following extension may be made to the <span><strong
class="command">Level 0</strong></span>
functions dealing with access to the
<span class="emphasis"><em>LS*-control</em></span> structures.
These formats are
presented mearly as a suggestion as they are optional to the
overall
- success of the framework.
+ success of the framework. Services should note if they do or do
not
+ implement these calls.
</p><p>
Note there is not an implicit <span
class="emphasis"><em>Discovery</em></span> step, the
specific query you are interested must be posed directly to a given
@@ -443,28 +492,44 @@
<span><strong class="command">Level 0</strong></span>.
</p><p>
An API breakdown follows:
- </p><div class="table"><a id="table.api.l1.c"></a><p
class="title"><b>Table 5. Additional Level 1 API Calls</b></p><div
class="table-contents"><table summary="Additional Level 1 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSSummaryControlDirect</td><td rowspan="2" align="left"
valign="left">LS & (Service Type | Name | AccessPoint)</td><td
rowspan="2" align="left" valign="middle">Time Array</td><td
align="left">Given an LS instance and service information, return array of
times from the <span class="emphasis"><em>Summarization</em></span> control
storage only.</td></tr><tr><td
align="left">getLSRegistrationControlDirect</td><td align="left">Given an LS
instance and service information, return array of times from the <span
class="emphasis"><em>Registered</em></span> control
storage only.</td></tr></tbody></table></div></div><br class="table-break"
/></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level2_api"></a>4.3. Level 2 API</h3></div></div></div><p>
+ </p><div class="table"><a id="table.api.l1.c"></a><p
class="title"><b>Table 5. Additional Level 1 API Calls</b></p><div
class="table-contents"><table summary="Additional Level 1 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSSummaryControlDirect</td><td rowspan="2" align="left"
valign="left">LS & (Service Type | Name | AccessPoint)</td><td
rowspan="2" align="left" valign="middle">Time Array</td><td
align="left">Given an LS instance and service information, return array of
times from the <span class="emphasis"><em>Summarization</em></span> control
storage only.</td></tr><tr><td
align="left">getLSRegistrationControlDirect</td><td align="left">Given an LS
instance and service information, return array of times from the <span
class="emphasis"><em>Registered</em></span> control
storage only.</td></tr></tbody></table></div></div><br class="table-break"
/></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level2_api"></a>5.3. Level 2 API</h3></div></div></div><p>
The highest level of this API will perform all work with regards to
discovery and query in a single call. It is expected that services
and
client applications will make use of this API instead of manually
using
the previous 2 layers.
+ </p><p>
+ The following <span class="emphasis"><em>eventType</em></span>s are
used in this Level of
+ the API:
</p><p>
- An API breakdown follows:
- </p><div class="table"><a id="table.api.l2"></a><p
class="title"><b>Table 6. Level 2 API Calls</b></p><div
class="table-contents"><table summary="Level 2 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSLocation</td><td rowspan="2" align="left" valign="left">(IP
Address | Domain) | eventType | Service Type</td><td align="left">Service
Metadata Array</td><td align="left">Given several input parameters, return a
list of <span class="emphasis"><em>Service</em></span> metadata
elements.</td></tr><tr><td align="left">getLSContent</td><td
align="left">Measurement Metadata Array</td><td align="left">Given several
input parameters, return a list of <span
class="emphasis"><em>Measurement</em></span> metadata
elements.</td></tr></tbody></table></div></div><br class="table-break" /><div
clas
s="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4
class="title"><a id="level2_api_ext"></a>4.3.1. Level 2 API
Extension</h4></div></div></div><p>
+ </p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/control/xquery/2.0</strong></span>
+ - Discussed in <a href="#level0_api" title="5.1. Level 0
API">0</a>
+ </p></li><li style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/control/xquery/2.0</strong></span>
+ - Discussed in <a href="#level0_api" title="5.1. Level 0
API">0</a>
+ </p></li><li style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</strong></span>
+ - Discussed in <a href="#level1_api" title="5.2. Level 1
API">1</a>
+ </p></li></ul></div><p>
+ </p><p>
+ An implementation of an API to access this data can be broken down as
+ follows:
+ </p><div class="table"><a id="table.api.l2"></a><p
class="title"><b>Table 6. Level 2 API Calls</b></p><div
class="table-contents"><table summary="Level 2 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSLocation</td><td rowspan="2" align="left" valign="left">(IP
Address | Domain) | eventType | Service Type</td><td align="left">Service
Metadata Array</td><td align="left">Given several input parameters, return a
list of <span class="emphasis"><em>Service</em></span> metadata
elements.</td></tr><tr><td align="left">getLSContent</td><td
align="left">Measurement Metadata Array</td><td align="left">Given several
input parameters, return a list of <span
class="emphasis"><em>Measurement</em></span> metadata
elements.</td></tr></tbody></table></div></div><br class="table-break" /><div
clas
s="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4
class="title"><a id="level2_api_ext"></a>5.3.1. Level 2 API
Extension</h4></div></div></div><p>
The following extension may be made to the <span><strong
class="command">Level 0</strong></span>
and <span><strong class="command">Level 1</strong></span>
functions dealing with access to the
<span class="emphasis"><em>LSStore-control</em></span> structures.
These formats are
presented mearly as a suggestion as they are optional to the
overall
- success of the framework.
+ success of the framework. Services should indicate if they support
+ these calls.
</p><p>
An API breakdown follows:
- </p><div class="table"><a id="table.api.l2.c"></a><p
class="title"><b>Table 7. Additional Level 2 API Calls</b></p><div
class="table-contents"><table summary="Additional Level 2 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSSummaryControl</td><td rowspan="2" align="left"
valign="left">Service Type | Name | AccessPoint</td><td rowspan="2"
align="left" valign="middle">Time Array</td><td align="left">Given an LS
instance and service information, return array of times from the <span
class="emphasis"><em>Summarization</em></span> control storage
only.</td></tr><tr><td align="left">getLSRegistrationControl</td><td
align="left">Given an LS instance and service information, return array of
times from the <span class="emphasis"><em>Registered</em></span> control
storage only.</td></tr
></tbody></table></div></div><br class="table-break"
>/></div></div></div><div class="section" lang="en" xml:lang="en"><div
>class="titlepage"><div><div><h2 class="title" style="clear: both"><a
>id="operation"></a>5. Operation</h2></div></div></div><p>
+ </p><div class="table"><a id="table.api.l2.c"></a><p
class="title"><b>Table 7. Additional Level 2 API Calls</b></p><div
class="table-contents"><table summary="Additional Level 2 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSSummaryControl</td><td rowspan="2" align="left"
valign="left">Service Type | Name | AccessPoint</td><td rowspan="2"
align="left" valign="middle">Time Array</td><td align="left">Given an LS
instance and service information, return array of times from the <span
class="emphasis"><em>Summarization</em></span> control storage
only.</td></tr><tr><td align="left">getLSRegistrationControl</td><td
align="left">Given an LS instance and service information, return array of
times from the <span class="emphasis"><em>Registered</em></span> control
storage only.</td></tr
></tbody></table></div></div><br class="table-break"
>/></div></div></div><div class="section" lang="en" xml:lang="en"><div
>class="titlepage"><div><div><h2 class="title" style="clear: both"><a
>id="operation"></a>6. Operation</h2></div></div></div><p>
<span><strong class="command">TBD</strong></span>
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="implementation"></a>6. Implementation</h2></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="implementation"></a>7. Implementation</h2></div></div></div><p>
The following sections detail notes on implementation. These will
change
as the development effort progresses, and eventually will be moved
into individual service documentation.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_general"></a>6.1. Overall
Considerations</h3></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_general"></a>7.1. Overall
Considerations</h3></div></div></div><p>
The following <span class="emphasis"><em>eventType</em></span>s
should begin to be
introduced into <span class="emphasis"><em>hLS</em></span> and <span
class="emphasis"><em>gLS</em></span>
exchanges to allow the ability to query the individual data-sets
(e.g.
@@ -496,31 +561,31 @@
following <span class="emphasis"><em>eventType</em></span>s:
</p><p>
</p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type:
circle"><p>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/key/summary/2.0</p></li><li
style="list-style-type:
circle"><p>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/key/service/2.0</p></li></ul></div><p>
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_java"></a>6.2. Java
Considerations</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_java"></a>7.2. Java
Considerations</h3></div></div></div><p>
<span><strong class="command">TBD</strong></span>
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_perl"></a>6.3. Perl
Considerations</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_perl"></a>7.3. Perl
Considerations</h3></div></div></div><p>
The following represents a list of changes that must be made to the
Perl implementation along with related commentary.
</p><p>
</p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p>
- <a href="#implementation_perl_mode">gLS and hLS Operation
Differences</a> - The
+ <a href="#implementation_perl_mode" title="7.3.1. gLS and hLS
Operation Differences">gLS and hLS Operation Differences</a> - The
<span class="emphasis"><em>gLS</em></span> will have special
functionality beyond
the <span class="emphasis"><em>hLS</em></span> and vice versa.
</p></li><li style="list-style-type: circle"><p>
- <a href="#implementation_perl_summarization">Summarizing
Registered Data</a> - The data
+ <a href="#implementation_perl_summarization"
title="7.3.2. Summarizing Registered Data">Summarizing Registered Data</a> -
The data
must be summarized in some way and conveyed to the
<span class="emphasis"><em>gLS</em></span> layer.
</p></li><li style="list-style-type: circle"><p>
- <a href="#implementation_perl_storage">Storage
Reorganization</a> - The summarized
+ <a href="#implementation_perl_storage" title="7.3.3. Storage
Reorganization">Storage Reorganization</a> - The summarized
data must be stored somewhere.
</p></li><li style="list-style-type: circle"><p>
- <a href="#implementation_perl_registration">Multiple and Self
Registration</a> - Changes to
+ <a href="#implementation_perl_registration"
title="7.3.4. Multiple and Self Registration">Multiple and Self
Registration</a> - Changes to
how we treat the act of registration.
</p></li><li style="list-style-type: circle"><p>
- <a href="#implementation_perl_ets">EventTypes</a> - Several new
+ <a href="#implementation_perl_ets"
title="7.3.5. EventTypes">EventTypes</a> - Several new
eventTypes are necessary.
</p></li></ul></div><p>
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_mode"></a>6.3.1. gLS and hLS Operation
Differences</h4></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_mode"></a>7.3.1. gLS and hLS Operation
Differences</h4></div></div></div><p>
The <span class="emphasis"><em>gLS</em></span> must contain the
following functionality
that is not currently found (or should be turned off in) in the LS:
</p><p>
@@ -559,9 +624,9 @@
<span class="emphasis"><em>hLS</em></span>). To enable the <span
class="emphasis"><em>gLS</em></span>
mode the switch will manually need to be edited in the
<span><strong class="command">daemon.conf</strong></span> file.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_summarization"></a>6.3.2. Summarizing Registered
Data</h4></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_summarization"></a>7.3.2. Summarizing Registered
Data</h4></div></div></div><p>
Using the example code in
- <a href="#appendix_summarization_source_perl">Summarization Source
Code (Perl)</a>, a summarization
+ <a href="#appendix_summarization_source_perl"
title="8.4.2. Summarization Source Code (Perl)">Summarization Source Code
(Perl)</a>, a summarization
of the registered data should be completed on-demand (e.g. If new
information is registered, the summary should be re-run and the
information re-registered with the <span
class="emphasis"><em>gLS</em></span> layer.
@@ -575,7 +640,7 @@
standpoint to keep all summarized info together, but having a
faster
<span class="emphasis"><em>cache</em></span> of your own summary
may prove to be
worthwhile.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_storage"></a>6.3.3. Storage
Reorganization</h4></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_storage"></a>7.3.3. Storage
Reorganization</h4></div></div></div><p>
Currently it is an option to specify the name of the collection
that
the registered data will reside in (e.g.
<span class="emphasis"><em>store.dbxml</em></span> or similar).
We will require the
@@ -592,7 +657,7 @@
is much easier to query than checking the configuration for the
exact container name, and modifying the existing
<span class="emphasis"><em>XQuery</em></span> to take this into
consideration.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_registration"></a>6.3.4. Multiple and Self
Registration</h4></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_registration"></a>7.3.4. Multiple and Self
Registration</h4></div></div></div><p>
Currently the tooling to support registration to multiple LS
instances
is not as error resistant as it should be. The operation works,
but
does not do much in the way of checking the result codes of each
@@ -602,14 +667,14 @@
own summary information. This will mean using the accessPoint as
a <span class="emphasis"><em>default</em></span> LS instance.
This will also mean
addressing the storage issue discussed in
- <a href="#implementation_perl_storage">Storage Reorganization</a>.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_ets"></a>6.3.5. EventTypes</h4></div></div></div><p>
- See <a href="#implementation_general">Overall Considerations</a>
for a list. The
+ <a href="#implementation_perl_storage" title="7.3.3. Storage
Reorganization">Storage Reorganization</a>.
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_ets"></a>7.3.5. EventTypes</h4></div></div></div><p>
+ See <a href="#implementation_general" title="7.1. Overall
Considerations">Overall Considerations</a> for a list. The
immediate plan may avoid use of the time extension.
- </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h2 class="title"
style="clear: both"><a id="appendix"></a>7. Appendix</h2></div></div></div><p>
+ </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h2 class="title"
style="clear: both"><a id="appendix"></a>8. Appendix</h2></div></div></div><p>
The following sections describe some of the more concreate details of
this
implementation when applicable.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_summary"></a>7.1. Summary Message
Example</h3></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_summary"></a>8.1. Summary Message
Example</h3></div></div></div><p>
Each <span class="emphasis"><em>hLS</em></span> instance must
register a summary of the
data it is aware of with the <span
class="emphasis"><em>gLS</em></span> or
<span class="emphasis"><em>gLS</em></span>s it communicates with.
This summary should
@@ -737,14 +802,143 @@



- </pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_summarization_source"></a>7.2. Summarization Source
Code</h3></div></div></div><p>
+ </pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_summary_request"></a>8.2. LSQuery Request (Discovery)
Example</h3></div></div></div><p>
+ The following example demonstrates the use of the
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</strong></span>
+ <span class="emphasis"><em>eventType</em></span> to offer a
structured query for summarization
+ information. The metadata <span><strong
class="command">MUST</strong></span> contain a summary
+ subject and the proper <span
class="emphasis"><em>eventType</em></span> value. The
+ summary subject can contain any number of <span
class="emphasis"><em>address</em></span>,
+ <span class="emphasis"><em>domain</em></span>, and <span
class="emphasis"><em>eventType</em></span> elements
+ that are used to find information in a summary set.
+ </p><p>
+ It is important to note that as more <span
class="emphasis"><em>address</em></span>,
+ <span class="emphasis"><em>domain</em></span>, and <span
class="emphasis"><em>eventType</em></span> elements
+ are added these should be treated as an <span><strong
class="command">OR</strong></span> operation
+ inside of the service. The collective groups of elements (e.g. all
+ eventTypes, all adddresses, all domains) are treated as an
+ <span><strong class="command">AND</strong></span> operation.
+ </p><p>
+ The <a href="#appendix_summary_response" title="8.3. LSQuery
Response (Discovery) Example">LSQuery Response (Discovery) Example</a> can be
seen below.
+ </p><pre class="programlisting">
+
+
+
+<?xml version='1.0' encoding='UTF-8'?>
+<nmwg:message type="LSQueryRequest"
+ id="LSDiscoveryRequest"
+
xmlns:perfsonar="http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/";
+ xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
+
xmlns:psservice="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/1.0/";
+ xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";
+
xmlns:summary="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/summarization/2.0/";
+
xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070828/";
+
xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20070828/">
+
+ <nmwg:metadata id="meta1">
+ <summary:subject
xmlns:summary="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/summarization/2.0/";
id="subject.1">
+
+
+ <nmtb:address
xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070828/";
type="ipv4">128.4.133.167</nmtb:address>
+ <nmtb:address
xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070828/"type="ipv4">128.4.100.45</nmtb:address>
+
+ <nmtb:domain
xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070828/">
+ <nmtb:name type="dns">edu</nmtb:name>
+ </nmtb:domain>
+
+ <nmtb:domain
xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070828/">
+ <nmtb:name type="dns">udel.edu</nmtb:name>
+ </nmtb:domain>
+
+
<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>
+
+
+
+ </summary:subject>
+
+ 
+
<nmwg:eventType>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</nmwg:eventType>

+
+ </nmwg:metadata>
+
+ <nmwg:data metadataIdRef="meta1" id="d1"/>
+
+</nmwg:message>
+
+
+
+ </pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_summary_response"></a>8.3. LSQuery Response (Discovery)
Example</h3></div></div></div><p>
+ The response should contain a verbatim inclusion of the initial
metadata
+ and a data contain (possibly many) metadata elements. An error is
+ indicated by a result coded datum element.
+ </p><p>
+ The <a href="#appendix_summary_request" title="8.2. LSQuery Request
(Discovery) Example">LSQuery Request (Discovery) Example</a> can be seen
above.
+ </p><pre class="programlisting">
+
+
+
+<?xml version='1.0' encoding='UTF-8'?>
+<nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
+ messageIdRef="LSDiscoveryRequest"
+ id="message.11606947"
+ type="LSQueryResponse">
+
+
+ <nmwg:metadata metadataIdRef="meta1" id="metadata.4352753">
+ <summary:subject
xmlns:summary="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/summarization/2.0/";
id="subject.1">
+ <nmtb:address
xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070828/";
type="ipv4">128.4.133.167</nmtb:address>
+ <nmtb:address
xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070828/";
type="ipv4">128.4.100.45</nmtb:address>
+ <nmtb:domain
xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070828/">
+ <nmtb:name type="dns">edu</nmtb:name>
+ </nmtb:domain>
+ <nmtb:domain
xmlns:nmtb="http://ogf.org/schema/network/topology/base/20070828/">
+ <nmtb:name type="dns">udel.edu</nmtb:name>
+ </nmtb:domain>
+
<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>
+ </summary:subject>
+
<nmwg:eventType>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</nmwg:eventType>
+ </nmwg:metadata>
+
+ 
+
+ <nmwg:data metadataIdRef="metadata.4352753" id="data.16097906">
+
+ 
+
+ <nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
id="9fe2a44e68fb22a51249f9b3e67137d0">
+ <perfsonar:subject
xmlns:perfsonar="http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/";
id="commonParameters2">
+ <psservice:service
xmlns:psservice="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/1.0/";
id="serviceParameters2">
+
<psservice:serviceName>My_test_MA2</psservice:serviceName>
+
<psservice:accessPoint>http://localhost:8081/axis/services/snmpMA</psservice:accessPoint>
+ <psservice:serviceType>MA</psservice:serviceType>
+ <psservice:serviceDescription>This is my testing
MA2</psservice:serviceDescription>
+ </psservice:service>
+ </perfsonar:subject>
+ </nmwg:metadata>
+ </nmwg:data>
+
+</nmwg:message>
+
+
+
+ </pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_summarization_source"></a>8.4. Summarization Source
Code</h3></div></div></div><p>
As a proof of concept to performing a rudimentary
<span class="emphasis"><em>K Dominators</em></span> identification
of the IP addresses an
<span class="emphasis"><em>hLS</em></span> will know of, consider
the following source
code written in both Java and Perl.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="appendix_summarization_source_java"></a>7.2.1. Summarization Source Code
(Java)</h4></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="appendix_summarization_source_java"></a>8.4.1. Summarization Source Code
(Java)</h4></div></div></div><p>
<span><strong class="command">TBD</strong></span>
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="appendix_summarization_source_perl"></a>7.2.2. Summarization Source Code
(Perl)</h4></div></div></div><pre class="programlisting">
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="appendix_summarization_source_perl"></a>8.4.2. Summarization Source Code
(Perl)</h4></div></div></div><pre class="programlisting">

# Begin

@@ -788,14 +982,15 @@
# IP Trie Data Structure (similar to Net::Patricia)
my $tr = Net::IPTrie->new( version => 4 );

-# I need to be able to do my own manipulations
+# I need to be able to do my own manipulations (e.g. IPTrie is not really
+# that great...)
my %tree = ();

# Ensure that each child only has one parent (IPTrie data structure
# uses a strange internal representation).
my %claim = ();

-# starting list of IPs [UDel addresses from all over the domain]
+# starting list of IPs

my @map = ("128.175.13.92",
"128.175.13.74",
@@ -818,17 +1013,22 @@
# "80.15.11.2",
# "80.15.11.3");

+#my @map = ("64.57.25.15",
+# "64.57.27.4",
+# "64.57.27.138",
+# "128.4.12.12",
+# "128.4.13.1",
+# "160.135.1.1",
+# "207.75.165.151",
+# "207.72.226.18",
+# "206.72.224.1");
+
my $vote =
getCDIRSummaries(\@map);
$tr =
makePatriciaTrie(\@map,
$vote, $tr);
-manipulatePatriciaTrie($tr);
+manipulatePatriciaTrie(\@map,
$tr);
genGraph(\%tree);
-my $final = listMinDoms();
+listMinDoms();

-print "Min Dominators:\n\n";
-foreach my $f (@{$final}) {
- print $f , "\n";
-}
-
exit(1);

=head2 getCDIRSummaries($map)
@@ -842,30 +1042,17 @@
sub getCDIRSummaries {
my($map) = @_;

- # We can get ALL applicable CIDR summaries for each (in order of least to
- # greatest).
-
- my %vote = ();
+ my %tally = ();
foreach my $host (@{$map}) {
my @list = Net::CIDR::addr2cidr($host);
foreach my $range (@list) {
- $vote{$range}++ if defined $vote{$range};
- $vote{$range} = 1 if not defined $vote{$range};
- }
- }
+
+ # we want to ingore the wildcard addresses...
+ next if $range =~ m/^0\./;

- # organize the votes into popularity groups
-
- my %tally = ();
- foreach my $range (sort keys %vote) {
- if(defined $tally{$vote{$range}}) {
- push @{$tally{$vote{$range}}}, $range;
+ $tally{$range}++ if defined $tally{$range};
+ $tally{$range} = 1 if not defined $tally{$range};
}
- else {
- my @temp = ();
- push @temp, $range;
- $tally{$vote{$range}} =
\@temp;
- }
}

return \%tally;
@@ -881,7 +1068,7 @@
=cut

sub makePatriciaTrie {
- my($map, $votes, $tr) = @_;
+ my($map, $tally, $tr) = @_;

# Start to make the IPTrie data structure. First we add in all
# of the 'base' addresses
@@ -890,24 +1077,37 @@
$tr->add( address => $host, prefix => "32" );
}

- # Now we add in the summaries. We should try to find the
- # dominators in each 'vote' group first. This will ensure
- # we are closer to a minimal set
+ # Now we add in the summaries.

- foreach my $t (keys %{$votes}) {
- my @total = ();
- foreach my $addr (@{$votes->{$t}}) {
- @total = Net::CIDR::cidradd($addr, @total);
- }
- foreach my $t2 (@total) {
- my @parts = split(/\//,$t2);
- $tr->add( address => $parts[0], prefix => $parts[1] );
- }
+ foreach my $t (sort keys %{$tally}) {
+ my @parts = split(/\//,$t);
+ $tr->add( address => $parts[0], prefix => $parts[1] );
}

return $tr;
}

+=head2 extract($parent, $node, $status, $side)
+
+This aux function recursively walks the nodes of the IPTrie structure
+and creates a more usefriendly tree that we will use for manipulation
+and final display.
+
+=cut
+
+sub extract {
+ my($parent, $node, $status, $side) = @_;
+ my $me = "";
+ $me = $node->[3]."/".$node->[5] if defined $node->[3] and defined
$node->[5];
+ if($me and $side and (not $claim{$me})) {
+ push @{$tree{$parent}{"C"}}, $me;
+ $claim{$me} = 1;
+ }
+ $status = extract($parent, $node->[1], $status, "L") if $node->[1]
and (not $status->{"L"});
+ $status = extract($parent, $node->[2], $status, "R") if $node->[2]
and (not $status->{"R"});
+ return $status;
+}
+
=head2 manipulatePatriciaTrie($tr)

Given the IPTrie structure, we need to manually manipulate the nodes into
@@ -916,12 +1116,19 @@
=cut

sub manipulatePatriciaTrie {
- my($tr) = @_;
+ my($map, $tr) = @_;

my $list = ();
my $code = sub { push @$list, shift @_; };
my $count = $tr->traverse( code => $code );

+ # hacky root pointer (gives us unification if the whild card [0.*]
+ # was really needed)
+
+ my @temp = ();
+ $tree{"Root"}{"C"} =
\@temp;
+ $tree{"Root"}{"U"} = "NULL";
+
# we need to go backwards when looking at the IPTrie print out, this is
# is really to be sure children aren't all claimed by the root (the
internal
# structure is a little strange) so this ensures we hit the root last.
@@ -946,102 +1153,79 @@
extract($me, $node, \%status, "");
}

- # link all the parent information
+ # link all the parent information for each node and child
+
foreach my $item (keys %tree) {
foreach my $c (@{$tree{$item}{"C"}}) {
$tree{$c}{"U"} = $item if $c and $item;
}
}

- # No we get to do some manual mainpulation of the tree we just created,
- # there are two cases we should watch out for:
- #
- # 1) Node with only one child, child has children
- # 2) Node with only one child, child is a terminal
- #
- # Based on these two cases we will search the tree searching for
- # candidates. When we find one, be sure to move all the 'pointers'
- # around, and mark the node for deletion

- my @delete = ();
- foreach my $item (keys %tree) {
- if($#{$tree{$item}{"C"}} == 0 and
$#{$tree{$tree{$item}{"C"}->[0]}{"C"}} >= -1) {
- my @size = ($#{$tree{$item}{"C"}},
$#{$tree{$tree{$item}{"C"}->[0]}{"C"}});
-
- # we either look at the node and child, or node and parent as the
- # candidates for replacement.
- my @items = ();
- if($size[1] == -1) {
- @items = ($tree{$item}{"U"}, $item);
+ # First step: Start at the leaves and walk toward the root.
+ # - Every time we see a node with a sinle child, collapse it into the
parent
+ # (we are pruning the tree)
+
+ foreach my $host (@{$map}) {
+ my $current = $host."/32";
+ while($current) {
+ my $delete = "";
+ if($#{$tree{$tree{$current}{"U"}}{"C"}} == 0 and
+ not($current =~ m/\/32$/) and
+ $#{$tree{$current}{"C"}} == 0) {
+ $delete = $current;
+ foreach my $child (@{$tree{$current}{"C"}}) {
+ $tree{$child}{"U"} = $tree{$current}{"U"};
+ }
+ $tree{$tree{$current}{"U"}}{"C"} = $tree{$current}{"C"};
+ delete $tree{$delete}{"C"};
}
- else {
- @items = ($item, $tree{$item}{"C"}->[0]);
- }
+ $current = $tree{$current}{"U"};
+ delete $tree{$delete} if $delete;
+ }
+ }

- # We are assuming this will give us the most dominant
- # node (and that there will only be one).
- my @total = ();
- @total = Net::CIDR::cidradd($items[0], @total);
- @total = Net::CIDR::cidradd($items[1], @total);
+ # Second step: Start at the leaves and walk toward the root.
+ # - Every time we see a single child node, collapse it into the child (this
+ # is the opposite of what we just did, but this handles branching much
+ # better, this is also a form of pruning).

- # move the children
- if($size[1] == -1) {
- push @{$tree{$items[0]}{"C"}}, @{$tree{$items[1]}{"C"}};
+ foreach my $host (@{$map}) {
+ my $current = $host."/32";
+ while($current) {
+ my $delete = "";
+ if($#{$tree{$current}{"C"}} == 0) {
+ $delete = $current;
+ foreach my $child (@{$tree{$delete}{"C"}}) {
+ $tree{$child}{"U"} = $tree{$delete}{"U"};
+ push @{$tree{$tree{$delete}{"U"}}{"C"}}, $child;
+ }
+
my $counter = 0;
- foreach my $c (@{$tree{$items[0]}{"C"}}) {
- if($c eq $items[1]) {
- splice(@{$tree{$items[0]}{"C"}}, $counter, 1);
- last;
+ foreach my $child (@{$tree{$tree{$delete}{"U"}}{"C"}}) {
+ if($child eq $current) {
+ my $remove =
splice(@{$tree{$tree{$delete}{"U"}}{"C"}},$counter,1);
}
$counter++;
}
}
- else {
- $tree{$items[0]}{"C"} = $tree{$items[1]}{"C"};
- }
-
- # mark the node for deletion
- push @delete, $items[1];
-
- # Re-map the children (if any) to the new parent
- foreach my $c (@{$tree{$items[0]}{"C"}}) {
- $tree{$c}{"U"} = $items[0] if $c and $items[0];
- }
+ $current = $tree{$current}{"U"};
+ delete $tree{$delete} if $delete;
}
- }
+ }

- # Get rid of dead nodes identified above (perl doesn't like you deleting
from
- # and 'in use' data structure so deleting needs to be done out of the
- # above loop)
+ # finally link the tree(s) to the root pointer

- foreach my $d (@delete) {
- delete $tree{$d};
+ foreach my $node (keys %tree) {
+ unless($tree{$node}{"U"}) {
+ $tree{$node}{"U"} = "Root";
+ push @{$tree{"Root"}{"C"}}, $node;
+ }
}

return;
}

-=head2 extract($parent, $node, $status, $side)
-
-This aux function recursively walks the nodes of the IPTrie structure
-and creates a more usefriendly tree that we will use for manipulation
-and final display.
-
-=cut
-
-sub extract {
- my($parent, $node, $status, $side) = @_;
- my $me = "";
- $me = $node->[3]."/".$node->[5] if defined $node->[3] and defined
$node->[5];
- if($me and $side and (not $claim{$me})) {
- push @{$tree{$parent}{"C"}}, $me;
- $claim{$me} = 1;
- }
- $status = extract($parent, $node->[1], $status, "L") if $node->[1]
and (not $status->{"L"});
- $status = extract($parent, $node->[2], $status, "R") if $node->[2]
and (not $status->{"R"});
- return $status;
-}
-
=head2 genGraph

Outputs the contents of the tree structure into a "Graphviz" formated
@@ -1056,18 +1240,27 @@

foreach my $item (keys %tree) {
next unless $item;
- my @array = ();
- @array =split(/\//, $item);
+ if($item =~ m/\/\d+$/) {
+ my @array = ();
+ @array =split(/\//, $item);

- # color the terminal elements so we know they are not dominators
- if($array[1] eq "32") {
- print DOT "\t\"" , $item , "\"[ color=crimson, style=filled ];\n";
+ # color the terminal elements so we know they are not dominators
+ if($array[1] eq "32") {
+ print DOT "\t\"" , $item , "\"[ color=crimson, style=filled ];\n";
+ }
+ else {
+ print DOT "\t\"" , $item , "\";\n";
+ }
}
else {
- print DOT "\t\"" , $item , "\";\n";
+ # this is the root...
+
+ print DOT "\t\"" , $item , "\"[ color=yellow, style=filled ];\n";
}
}

+ # output the linkings
+
foreach my $item (keys %tree) {
next unless $item;
foreach my $c (@{$tree{$item}{"C"}}) {
@@ -1097,14 +1290,12 @@
# First locate the root in the tree

my @expand = ();
- foreach my $node (keys %tree) {
- unless($tree{$node}{"U"}) {
+ foreach my $node (sort keys %tree) {
+ if($node and $tree{$node}{"U"} eq "Root") {
# add the root the 'expand' list so we can
# examine it (and it's children, etc.) then
# exit
-
push @expand, $node;
- last;
}
}

@@ -1120,6 +1311,7 @@
while($expand[$counter]) {
my $minDomFlag = 0;
my $expandFlag = 0;
+
foreach my $child (sort @{$tree{$expand[$counter]}{"C"}}) {
my @array = split(/\//, $child);

@@ -1150,7 +1342,12 @@
$counter++;
}

- return
\@minDoms;
+ print "Min Dominators:\n\n";
+ foreach my $f (@minDoms) {
+ print $f , "\n";
+ }
+
+ return;
}

__END__
@@ -1205,7 +1402,7 @@
<span class="emphasis"><em>Net::IPTrie</em></span>) to solve
this problem. Similar
libraries may not be available in Java, but can easily be
re-created.</p></li><li style="list-style-type: circle"><p>The
output (shown below) is currently used to create a
- <a href="#id2532268">Graphviz</a> formated image. The script
can be
+ [<a href="#id2542952"><span
class="citation">Graphviz</span></a>] formated image. The script can be
modified to output the tree in different formats (including
directly into a summarization message).</p></li><li
style="list-style-type: circle"><p>This script does not allow one to specifiy
a set value for
<span class="emphasis"><em>K</em></span> and return only those
dominators. The
@@ -1221,39 +1418,41 @@
# Begin

digraph g {
- "128.0.0.0/9";
+ "128.4.133.163/32"[ color=crimson, style=filled ];
+ "128.175.13.74/32"[ color=crimson, style=filled ];
"128.4.131.23/32"[ color=crimson, style=filled ];
- "128.4.133.163/32"[ color=crimson, style=filled ];
+ "Root"[ color=yellow, style=filled ];
+ "128.175.13.64/27";
+ "128.4.0.0/16";
+ "128.4.40.0/27";
+ "128.0.0.0/8";
+ "128.4.40.17/32"[ color=crimson, style=filled ];
+ "128.4.40.12/32"[ color=crimson, style=filled ];
+ "128.4.133.167/32"[ color=crimson, style=filled ];
+ "128.4.128.0/21";
"128.175.13.92/32"[ color=crimson, style=filled ];
- "128.4.40.0/28";
- "128.4.128.0/17";
- "0.0.0.0/0";
- "128.4.40.17/32"[ color=crimson, style=filled ];
"128.4.133.164/30";
- "128.4.40.12/32"[ color=crimson, style=filled ];
- "128.128.0.0/9";
"128.4.133.164/32"[ color=crimson, style=filled ];
- "128.4.133.167/32"[ color=crimson, style=filled ];
- "128.4.132.0/22";
- "128.4.0.0/17";
- "128.175.13.74/32"[ color=crimson, style=filled ];
+ "128.4.133.160/29";
+ "128.4.40.8/29";
"128.4.40.10/32"[ color=crimson, style=filled ];
- "128.0.0.0/9" -> "128.4.0.0/17";
- "128.0.0.0/9" -> "128.4.128.0/17";
- "128.4.40.0/28" -> "128.4.40.10/32";
- "128.4.40.0/28" -> "128.4.40.12/32";
- "128.4.128.0/17" -> "128.4.132.0/22";
- "128.4.128.0/17" -> "128.4.131.23/32";
- "0.0.0.0/0" -> "128.0.0.0/9";
- "0.0.0.0/0" -> "128.128.0.0/9";
+ "Root" -> "128.0.0.0/8";
+ "128.175.13.64/27" -> "128.175.13.92/32";
+ "128.175.13.64/27" -> "128.175.13.74/32";
+ "128.4.0.0/16" -> "128.4.40.0/27";
+ "128.4.0.0/16" -> "128.4.128.0/21";
+ "128.4.40.0/27" -> "128.4.40.8/29";
+ "128.4.40.0/27" -> "128.4.40.17/32";
+ "128.0.0.0/8" -> "128.175.13.64/27";
+ "128.0.0.0/8" -> "128.4.0.0/16";
+ "128.4.128.0/21" -> "128.4.131.23/32";
+ "128.4.128.0/21" -> "128.4.133.160/29";
+ "128.4.133.164/30" -> "128.4.133.167/32";
"128.4.133.164/30" -> "128.4.133.164/32";
- "128.4.133.164/30" -> "128.4.133.167/32";
- "128.128.0.0/9" -> "128.175.13.74/32";
- "128.128.0.0/9" -> "128.175.13.92/32";
- "128.4.132.0/22" -> "128.4.133.163/32";
- "128.4.132.0/22" -> "128.4.133.164/30";
- "128.4.0.0/17" -> "128.4.40.0/28";
- "128.4.0.0/17" -> "128.4.40.17/32";
+ "128.4.133.160/29" -> "128.4.133.164/30";
+ "128.4.133.160/29" -> "128.4.133.163/32";
+ "128.4.40.8/29" -> "128.4.40.10/32";
+ "128.4.40.8/29" -> "128.4.40.12/32";
}

# End
@@ -1278,7 +1477,7 @@
pick out the top (3 in this case) dominating elements.
</p><p>
</p><div class="mediaobject"><img src="images/graph2.png"
/></div><p>
- </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_synch"></a>7.3. Synchronization Example</h3></div></div></div><p>
+ </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_synch"></a>8.5. Synchronization Example</h3></div></div></div><p>
The following example illustrates synchronization using the
perfSONAR-PS framework mainly for backup up <span
class="emphasis"><em>DCN</em></span>
registered information. This small snippet of code is currently used
@@ -1568,20 +1767,20 @@
A <span class="emphasis"><em>globally</em></span> acessible
Lookup Service.
</p></dd></dl></div><div class="glossdiv"><h3
class="title">H</h3><dl><dt><a id="hLS"></a>hLS</dt><dd><p>
The <span class="emphasis"><em>home</em></span> Lookup Service.
- </p></dd></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></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="id2531864"></a><p>[<abbr
class="abbrev">dLS</abbr>] <span class="title"><i>
+ </p></dd></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></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="id2542823"></a><p>[<abbr
class="abbrev">dLS</abbr>] <span class="title"><i>
<a
href="http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/doc/dLS/dLS_spec_1.html";

target="_top">http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/doc/dLS/dLS_spec_1.html</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2531884"></a><p>[<abbr class="abbrev">ESnet</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542842"></a><p>[<abbr class="abbrev">ESnet</abbr>] <span
class="title"><i>
<a href="http://www.es.net"; target="_top">http://www.es.net</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2531902"></a><p>[<abbr class="abbrev">Geant2</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542860"></a><p>[<abbr class="abbrev">Geant2</abbr>] <span
class="title"><i>
<a href="http://www.geant2.net";
target="_top">http://www.geant2.net</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2531920"></a><p>[<abbr class="abbrev">Internet2</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542879"></a><p>[<abbr class="abbrev">Internet2</abbr>] <span
class="title"><i>
<a href="http://www.internet2.edu";
target="_top">http://www.internet2.edu</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2532214"></a><p>[<abbr class="abbrev">RNP</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542898"></a><p>[<abbr class="abbrev">RNP</abbr>] <span
class="title"><i>
<a href="http://www.rnp.br/en"; target="_top">http://www.rnp.br/en</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2532232"></a><p>[<abbr class="abbrev">XPath</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542915"></a><p>[<abbr class="abbrev">XPath</abbr>] <span
class="title"><i>
<a href="http://www.w3.org/TR/xpath"; target="_top">XPath</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2532250"></a><p>[<abbr class="abbrev">XQuery</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542934"></a><p>[<abbr class="abbrev">XQuery</abbr>] <span
class="title"><i>
<a href="http://www.w3.org/TR/xquery/"; target="_top">XQuery</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2532268"></a><p>[<abbr class="abbrev">Graphviz</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542952"></a><p>[<abbr class="abbrev">Graphviz</abbr>] <span
class="title"><i>
<a href="http://www.graphviz.org/"; target="_top">Graphviz</a>
</i>. </span></p></div></div></div></body></html>

Modified: trunk/nmwg/doc/dLS/gLS/phase_1.xml
===================================================================
--- trunk/nmwg/doc/dLS/gLS/phase_1.xml 2008-06-09 13:58:42 UTC (rev 360)
+++ trunk/nmwg/doc/dLS/gLS/phase_1.xml 2008-06-16 02:41:55 UTC (rev 361)
@@ -66,6 +66,12 @@
<entry>Summarization Clarification/Algorithm Change</entry>
<entry>J. Zurawski</entry>
</row>
+ <row>
+ <entry>1.03</entry>
+ <entry>06/12/2007</entry>
+ <entry>LSRegistration Primer/Development Lessons Learned</entry>
+ <entry>J. Zurawski</entry>
+ </row>
</tbody>
</tgroup>
</table>
@@ -115,20 +121,55 @@

<para>
The remainder of the document is structured as follows:
- <xref linkend="architecture" /> will go into details of the system as
- viewed from afar. Issues such as communication and individual service
- behavior will be discussed. <xref linkend="api" /> will describe the
- interface service developers will implement to interact with this
system.
- <xref linkend="operation" /> will lay out some common use cases and
- examples. <xref linkend="implementation" /> will discuss some
- algorithms and specific considerations that the both reference
- implementations will need to take into account. Finally
- <xref linkend="appendix" /> details some XML and code examples to be
used
- in the construction of this service.
+ in <xref linkend="preliminaries" /> the basics of LSRegistration for
+ services will be briefly discussed. <xref linkend="architecture" />
will
+ go into details of the system as viewed from afar. Issues such as
+ communication and individual service behavior will be discussed.
+ <xref linkend="api" /> will describe the interface service developers
will
+ implement to interact with this system. <xref linkend="operation" />
will
+ lay out some common use cases and examples.
+ <xref linkend="implementation" /> will discuss some algorithms and
+ specific considerations that the both reference implementations will
need
+ to take into account. Finally <xref linkend="appendix" /> details some
+ XML and code examples to be used in the construction of this service.
</para>

</section>

+ <section id="preliminaries" xreflabel="Preliminaries">
+ <title>Preliminaries</title>
+
+ <para>
+ To motivate the discussion of a <emphasis>Global</emphasis> resource
+ discovery system, we must first mention the resources that are
available
+ and the steps they <emphasis>must</emphasis> take to make themselves
known
+ to the framework at large. We will first begin in
+ <xref linkend="preliminaries-service" /> with a discussion of what
defines
+ a <emphasis>perfSONAR</emphasis> service.
+ <xref linkend="preliminaries-registration" /> talks about a minimum
set of
+ necessary information that can be used to idenfity and describe a
service.
+ Finally, <xref linkend="preliminaries-prop" /> explores what is
desirable
+ for spreading this information to interested parties.
+ </para>
+
+ <section id="preliminaries-service" xreflabel="Service Definition">
+ <title>Service Definition</title>
+ <para>TBD</para>
+ </section>
+
+ <section id="preliminaries-registration" xreflabel="Registration">
+ <title>Registration</title>
+ <para>TBD</para>
+ </section>
+
+ <section id="preliminaries-prop" xreflabel="Information Dissemination">
+ <title>Information Dissemination</title>
+
+ <para>TBD</para>
+ </section>
+
+ </section>
+
<section id="architecture" xreflabel="Architecture">
<title>Architecture</title>

@@ -625,7 +666,7 @@
</section>

</section>
-
+
<section id="api" xreflabel="API">
<title>API</title>

@@ -691,7 +732,7 @@
<tbody>
<row>
<entry morerows="3" valign="middle" align="center"><xref
linkend="level0_api" /></entry>
- <entry morerows="7" valign="middle">LSQueryRequest</entry>
+ <entry morerows="9" valign="middle">LSQueryRequest</entry>
<entry>service.lookup.xquery</entry>
<entry morerows="3" valign="middle">XQuery</entry>
<entry morerows="3" valign="middle">Raw XML</entry>
@@ -707,28 +748,34 @@

<entry>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</entry>
</row>
<row>
- <entry morerows="1" valign="middle" align="center"><xref
linkend="level1_api" /></entry>
+ <entry morerows="2" valign="middle" align="center"><xref
linkend="level1_api" /></entry>

<entry>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</entry>
- <entry>IP, Domain, eventType, Service Data</entry>
- <entry>hLS URL Array</entry>
- <entry>Standalone Discovery</entry>
+ <entry morerows="1" valign="middle">IP, Domain, eventType,
Service Data</entry>
+ <entry morerows="1" valign="middle">hLS URL Array</entry>
+ <entry morerows="1" valign="middle">Standalone Discovery</entry>
</row>
<row>
+
<entry>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</entry>
+ </row>
+ <row>

<entry>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</entry>
<entry>hLS, IP, Domain, eventType, Service Data</entry>
<entry>Metadata (e.g. Service/Measurement based) Array</entry>
<entry>Standalone Query</entry>
</row>
<row>
- <entry morerows="1" valign="middle" align="center"><xref
linkend="level2_api" /></entry>
+ <entry morerows="2" valign="middle" align="center"><xref
linkend="level2_api" /></entry>

<entry>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</entry>
- <entry morerows="1" valign="middle">IP, Domain, eventType,
Service Data</entry>
- <entry morerows="1" valign="middle">Metadata (e.g.
Service/Measurement based) Array</entry>
- <entry morerows="1" valign="middle">Complete
Discovery/Query</entry>
+ <entry morerows="2" valign="middle">IP, Domain, eventType,
Service Data</entry>
+ <entry morerows="2" valign="middle">Metadata (e.g.
Service/Measurement based) Array</entry>
+ <entry morerows="2" valign="middle">Complete
Discovery/Query</entry>
</row>
<row>

<entry>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</entry>
</row>
+ <row>
+
<entry>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</entry>
+ </row>
</tbody>
</tgroup>
</table>
@@ -745,8 +792,9 @@
<para>
The Level 0 API is based on the current query method used in the
<emphasis>LS</emphasis>: <command>LSQueryRequest</command> messages
- sending a raw <command>XQuery</command> string. We would like to
keep
- this base functionality for two reasons:
+ sending a raw <command>XQuery</command> string sent directly to the
+ LSQuery interface. We would like to keep this base functionality for
+ two reasons:
</para>

<para>
@@ -766,11 +814,11 @@
</listitem>
</itemizedlist>
</para>
-
+
<para>
There are only minor modifications that must be made to the existing
<command>LSQueryRequest</command> functionality, mainly the addition
of
- two new <emphasis>eventType</emphasis>s. These
+ three new <emphasis>eventType</emphasis>s. These
<emphasis>eventType</emphasis>s will not only help this level isolate
the specific dataset to query, but provided needed functionality to
the
abstractions built on top of Level 0:
@@ -794,9 +842,9 @@
</listitem>
</itemizedlist>
</para>
-
+
<para>
- These <emphasis>eventType</emphasis>s are more of an
+ These two <emphasis>eventType</emphasis>s are more of an
<emphasis>ease of design</emphasis> feature for the implementers of
the
<emphasis>gLS</emphasis> and <emphasis>hLS</emphasis> due to the
nature
of the backend storage mechanisms. The existing
@@ -805,7 +853,7 @@
</para>

<para>
- Addtional considerations for this level of the API revolve around the
+ Additional considerations for this level of the API revolve around
the
internal representation of when data is set to expire, namely the
<emphasis>LS*-control</emphasis> structure. It is desirable to
have access to this when providing status reports about registered
@@ -833,9 +881,16 @@
</para>

<para>
- An API breakdown follows:
+ While desirable, these two <emphasis>eventType</emphasis>s remain
+ optional and services should report their ability to use or not use
them
+ when queried.
</para>

+ <para>
+ An implementation of an API to access this data can be broken down as
+ follows:
+ </para>
+
<table frame="all" align="center" halign="center" width="80%"
id="table.api.l0">
<title>Level 0 API Calls</title>
<tgroup cols="1" align="left" colsep="1" rowsep="1">
@@ -892,9 +947,55 @@
</para>

<para>
- An API breakdown follows:
+ In addition to the aforementioned <emphasis>XQuery</emphasis>
+ interfaces from <command>Level 0</command>, it is desirable to create
+ a higher level Message that has direct access to the summarized
+ information, without needing to worry about the exact structure
+ (<command>N.B.</command> this allows implementations the ability
+ to construct higher speed caching and summarization procedures that
do
+ not need to involve <emphasis>XML</emphasis>). We introduce a new
+ evnet type that serves as a conduit to this particular interface:
+
<command>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</command>
+ An example message that takes advantage can be seen in
+ <xref linkend ="appendix_summary_request" />. The response to this
+ message can be seen in <xref linkend="appendix_summary_response" />.
</para>

+ <para>
+ The following <emphasis>eventType</emphasis>s are used in this Level
of
+ the API:
+ </para>
+
+ <para>
+ <itemizedlist mark='opencircle'>
+ <listitem>
+ <para>
+
<command>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/control/xquery/2.0</command>
+ - Discussed in <xref linkend="level0_api" />
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
<command>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/control/xquery/2.0</command>
+ - Discussed in <xref linkend="level0_api" />
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
<command>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</command>
+ - Allows a specially crafted query (independent of
+ <emphasis>XQuery</emphasis> language) to query the summarized
dataset
+ of a gLS (or in some cases an hLS, although this is less
common).
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ An implementation of an API to access this data can be broken down as
+ follows:
+ </para>
+
<table frame="all" align="center" halign="center" width="80%"
id="table.api.l1">
<title>Level 1 API Calls</title>
<tgroup cols="1" align="left" colsep="1" rowsep="1">
@@ -939,7 +1040,8 @@
functions dealing with access to the
<emphasis>LS*-control</emphasis> structures. These formats are
presented mearly as a suggestion as they are optional to the
overall
- success of the framework.
+ success of the framework. Services should note if they do or do
not
+ implement these calls.
</para>

<para>
@@ -998,9 +1100,38 @@
client applications will make use of this API instead of manually
using
the previous 2 layers.
</para>
+
+ <para>
+ The following <emphasis>eventType</emphasis>s are used in this Level
of
+ the API:
+ </para>
+
+ <para>
+ <itemizedlist mark='opencircle'>
+ <listitem>
+ <para>
+
<command>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/control/xquery/2.0</command>
+ - Discussed in <xref linkend="level0_api" />
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
<command>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/control/xquery/2.0</command>
+ - Discussed in <xref linkend="level0_api" />
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
<command>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</command>
+ - Discussed in <xref linkend="level1_api" />
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>

<para>
- An API breakdown follows:
+ An implementation of an API to access this data can be broken down as
+ follows:
</para>

<table frame="all" align="center" halign="center" width="80%"
id="table.api.l2">
@@ -1041,7 +1172,8 @@
and <command>Level 1</command> functions dealing with access to the
<emphasis>LSStore-control</emphasis> structures. These formats are
presented mearly as a suggestion as they are optional to the
overall
- success of the framework.
+ success of the framework. Services should indicate if they support
+ these calls.
</para>

<para>
@@ -1467,6 +1599,62 @@

</section>

+ <section id="appendix_summary_request" xreflabel="LSQuery Request
(Discovery) Example">
+ <title>LSQuery Request (Discovery) Example</title>
+
+ <para>
+ The following example demonstrates the use of the
+
<command>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</command>
+ <emphasis>eventType</emphasis> to offer a structured query for
summarization
+ information. The metadata <command>MUST</command> contain a summary
+ subject and the proper <emphasis>eventType</emphasis> value. The
+ summary subject can contain any number of
<emphasis>address</emphasis>,
+ <emphasis>domain</emphasis>, and <emphasis>eventType</emphasis>
elements
+ that are used to find information in a summary set.
+ </para>
+
+ <para>
+ It is important to note that as more <emphasis>address</emphasis>,
+ <emphasis>domain</emphasis>, and <emphasis>eventType</emphasis>
elements
+ are added these should be treated as an <command>OR</command>
operation
+ inside of the service. The collective groups of elements (e.g. all
+ eventTypes, all adddresses, all domains) are treated as an
+ <command>AND</command> operation.
+ </para>
+
+ <para>
+ The <xref linkend="appendix_summary_response" /> can be seen below.
+ </para>
+
+ <programlisting>
+ <![CDATA[
+ <inlinexml file="examples/discovery_ex.xml"/>
+ ]]>
+ </programlisting>
+
+ </section>
+
+ <section id="appendix_summary_response" xreflabel="LSQuery Response
(Discovery) Example">
+ <title>LSQuery Response (Discovery) Example</title>
+
+ <para>
+ The response should contain a verbatim inclusion of the initial
metadata
+ and a data contain (possibly many) metadata elements. An error is
+ indicated by a result coded datum element.
+ </para>
+
+ <para>
+ The <xref linkend="appendix_summary_request" /> can be seen above.
+ </para>
+
+ <programlisting>
+ <![CDATA[
+ <inlinexml file="examples/discovery_ex_resp.xml"/>
+ ]]>
+ </programlisting>
+
+ </section>
+
<section id="appendix_summarization_source" xreflabel="Summarization
Source Code">
<title>Summarization Source Code</title>

Modified: trunk/nmwg/doc/dLS/gLS/phase_1_color.html
===================================================================
--- trunk/nmwg/doc/dLS/gLS/phase_1_color.html 2008-06-09 13:58:42 UTC (rev
360)
+++ trunk/nmwg/doc/dLS/gLS/phase_1_color.html 2008-06-16 02:41:55 UTC (rev
361)
@@ -1,7 +1,7 @@
<?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>dLS
Implementation Phase 1 -- The Rise of the gLS</title><meta name="generator"
content="DocBook XSL Stylesheets V1.71.0" /></head><body><div class="article"
lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a
id="id2478927"></a>dLS Implementation Phase 1 -- The Rise of the
gLS</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Boote</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Glowiak</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Swany</span></h3></div><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Zurawski</span></h3></div></div></div></div><hr /></div><div
class="
toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a
href="#changes">1. Document Changes</a></span></dt><dt><span
class="section"><a href="#introduction">2.
Introduction</a></span></dt><dt><span class="section"><a
href="#architecture">3. Architecture</a></span></dt><dd><dl><dt><span
class="section"><a href="#gLS_instances">3.1. gLS
Instances</a></span></dt><dt><span class="section"><a
href="#bootstrapping">3.2. Bootstrapping</a></span></dt><dt><span
class="section"><a href="#synchronization">3.3.
Synchronization</a></span></dt><dt><span class="section"><a
href="#hLS_instances">3.4. hLS Instances</a></span></dt><dt><span
class="section"><a href="#registration">3.5. Multiple
Registration</a></span></dt><dt><span class="section"><a
href="#interaction">3.6. Interaction</a></span></dt></dl></dd><dt><span
class="section"><a href="#api">4. API</a></span></dt><dd><dl><dt><span
class="section"><a href="#level0_api">4.1. Level 0
API</a></span></dt><dt><span class="sect
ion"><a href="#level1_api">4.2. Level 1 API</a></span></dt><!
dd><dl><
dt><span class="section"><a href="#level1_api_ext">4.2.1. Level 1 API
Extension</a></span></dt></dl></dd><dt><span class="section"><a
href="#level2_api">4.3. Level 2 API</a></span></dt><dd><dl><dt><span
class="section"><a href="#level2_api_ext">4.3.1. Level 2 API
Extension</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#operation">5. Operation</a></span></dt><dt><span class="section"><a
href="#implementation">6. Implementation</a></span></dt><dd><dl><dt><span
class="section"><a href="#implementation_general">6.1. Overall
Considerations</a></span></dt><dt><span class="section"><a
href="#implementation_java">6.2. Java Considerations</a></span></dt><dt><span
class="section"><a href="#implementation_perl">6.3. Perl
Considerations</a></span></dt><dd><dl><dt><span class="section"><a
href="#implementation_perl_mode">6.3.1. gLS and hLS Operation
Differences</a></span></dt><dt><span class="section"><a
href="#implementation_perl_summarization">6.3.2. Summarizing
Registered Data</a></span></dt><dt><span class="section"><a
href="#implementation_perl_storage">6.3.3. Storage
Reorganization</a></span></dt><dt><span class="section"><a
href="#implementation_perl_registration">6.3.4. Multiple and Self
Registration</a></span></dt><dt><span class="section"><a
href="#implementation_perl_ets">6.3.5.
EventTypes</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#appendix">7. Appendix</a></span></dt><dd><dl><dt><span
class="section"><a href="#appendix_summary">7.1. Summary Message
Example</a></span></dt><dt><span class="section"><a
href="#appendix_summarization_source">7.2. Summarization Source
Code</a></span></dt><dd><dl><dt><span class="section"><a
href="#appendix_summarization_source_java">7.2.1. Summarization Source Code
(Java)</a></span></dt><dt><span class="section"><a
href="#appendix_summarization_source_perl">7.2.2. Summarization Source Code
(Perl)</a></span></dt></dl></dd><dt><span class="section"><a
href="#appendix_sy
nch">7.3. Synchronization Example</a></span></dt></dl></dd><!
dt><span
class="glossary"><a href="#glossary">Terms</a></span></dt><dt><span
class="bibliography"><a
href="#bibliography">References</a></span></dt></dl></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2
class="title" style="clear: both"><a id="changes"></a>1. Document
Changes</h2></div></div></div><div class="table"><a id="table.1"></a><p
class="title"><b>Table 1. Change Log</b></p><div
class="table-contents"><table summary="Change Log" border="1"><colgroup><col
align="left" /></colgroup><thead><tr><th align="left">Version</th><th
align="left">Date</th><th align="left">Description</th><th
align="left">Author(s)</th></tr></thead><tbody><tr><td
align="left">1.00</td><td align="left">05/11/2007</td><td
align="left">Initial Preparation</td><td align="left">J.
Zurawski</td></tr><tr><td align="left">1.01</td><td
align="left">05/18/2007</td><td align="left">EventType Clarifications</td><td
align="left">J. Zurawski</td></tr><tr><td align="left">1.02</
td><td align="left">05/20/2007</td><td align="left">Summarization
Clarification/Algorithm Change</td><td align="left">J.
Zurawski</td></tr></tbody></table></div></div><br class="table-break"
/></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="introduction"></a>2. Introduction</h2></div></div></div><p>
- This document builds upon the work described in <a
href="#id2531864">dLS Design Document</a>
+<html xmlns="http://www.w3.org/1999/xhtml";><head><meta
http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>dLS
Implementation Phase 1 -- The Rise of the gLS</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="id2486755"></a>dLS Implementation Phase 1 -- The Rise of the
gLS</h1></div><div><div class="authorgroup"><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Boote</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Glowiak</span></h3></div><div class="author"><h3
class="author"><span class="firstname">M.</span> <span
class="surname">Swany</span></h3></div><div class="author"><h3
class="author"><span class="firstname">J.</span> <span
class="surname">Zurawski</span></h3></div></div></div></div><hr /></div><div
class="
toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a
href="#changes">1. Document Changes</a></span></dt><dt><span
class="section"><a href="#introduction">2.
Introduction</a></span></dt><dt><span class="section"><a
href="#preliminaries">3. Preliminaries</a></span></dt><dd><dl><dt><span
class="section"><a href="#preliminaries-service">3.1. Service
Definition</a></span></dt><dt><span class="section"><a
href="#preliminaries-registration">3.2. Registration</a></span></dt><dt><span
class="section"><a href="#preliminaries-prop">3.3. Information
Dissemination</a></span></dt></dl></dd><dt><span class="section"><a
href="#architecture">4. Architecture</a></span></dt><dd><dl><dt><span
class="section"><a href="#gLS_instances">4.1. gLS
Instances</a></span></dt><dt><span class="section"><a
href="#bootstrapping">4.2. Bootstrapping</a></span></dt><dt><span
class="section"><a href="#synchronization">4.3.
Synchronization</a></span></dt><dt><span class="section"><a href="#hLS_in
stances">4.4. hLS Instances</a></span></dt><dt><span class="!
section"
><a href="#registration">4.5. Multiple Registration</a></span></dt><dt><span
>class="section"><a href="#interaction">4.6.
>Interaction</a></span></dt></dl></dd><dt><span class="section"><a
>href="#api">5. API</a></span></dt><dd><dl><dt><span class="section"><a
>href="#level0_api">5.1. Level 0 API</a></span></dt><dt><span
>class="section"><a href="#level1_api">5.2. Level 1
>API</a></span></dt><dd><dl><dt><span class="section"><a
>href="#level1_api_ext">5.2.1. Level 1 API
>Extension</a></span></dt></dl></dd><dt><span class="section"><a
>href="#level2_api">5.3. Level 2 API</a></span></dt><dd><dl><dt><span
>class="section"><a href="#level2_api_ext">5.3.1. Level 2 API
>Extension</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
>href="#operation">6. Operation</a></span></dt><dt><span class="section"><a
>href="#implementation">7. Implementation</a></span></dt><dd><dl><dt><span
>class="section"><a href="#implementation_general">7.1. Overall
>Considerations</a></span></dt><dt><span cl
ass="section"><a href="#implementation_java">7.2. Java
Considerations</a></span></dt><dt><span class="section"><a
href="#implementation_perl">7.3. Perl
Considerations</a></span></dt><dd><dl><dt><span class="section"><a
href="#implementation_perl_mode">7.3.1. gLS and hLS Operation
Differences</a></span></dt><dt><span class="section"><a
href="#implementation_perl_summarization">7.3.2. Summarizing Registered
Data</a></span></dt><dt><span class="section"><a
href="#implementation_perl_storage">7.3.3. Storage
Reorganization</a></span></dt><dt><span class="section"><a
href="#implementation_perl_registration">7.3.4. Multiple and Self
Registration</a></span></dt><dt><span class="section"><a
href="#implementation_perl_ets">7.3.5.
EventTypes</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a
href="#appendix">8. Appendix</a></span></dt><dd><dl><dt><span
class="section"><a href="#appendix_summary">8.1. Summary Message
Example</a></span></dt><dt><span class="section"><a href=
"#appendix_summary_request">8.2. LSQuery Request (Discovery)!
Example
</a></span></dt><dt><span class="section"><a
href="#appendix_summary_response">8.3. LSQuery Response (Discovery)
Example</a></span></dt><dt><span class="section"><a
href="#appendix_summarization_source">8.4. Summarization Source
Code</a></span></dt><dd><dl><dt><span class="section"><a
href="#appendix_summarization_source_java">8.4.1. Summarization Source Code
(Java)</a></span></dt><dt><span class="section"><a
href="#appendix_summarization_source_perl">8.4.2. Summarization Source Code
(Perl)</a></span></dt></dl></dd><dt><span class="section"><a
href="#appendix_synch">8.5. Synchronization
Example</a></span></dt></dl></dd><dt><span class="glossary"><a
href="#glossary">Terms</a></span></dt><dt><span class="bibliography"><a
href="#bibliography">References</a></span></dt></dl></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2
class="title" style="clear: both"><a id="changes"></a>1. Document
Changes</h2></div></div></div><div class="table"><a id
="table.1"></a><p class="title"><b>Table 1. Change Log</b></p><div
class="table-contents"><table summary="Change Log" border="1"><colgroup><col
align="left" /></colgroup><thead><tr><th align="left">Version</th><th
align="left">Date</th><th align="left">Description</th><th
align="left">Author(s)</th></tr></thead><tbody><tr><td
align="left">1.00</td><td align="left">05/11/2007</td><td
align="left">Initial Preparation</td><td align="left">J.
Zurawski</td></tr><tr><td align="left">1.01</td><td
align="left">05/18/2007</td><td align="left">EventType Clarifications</td><td
align="left">J. Zurawski</td></tr><tr><td align="left">1.02</td><td
align="left">05/20/2007</td><td align="left">Summarization
Clarification/Algorithm Change</td><td align="left">J.
Zurawski</td></tr><tr><td align="left">1.03</td><td
align="left">06/12/2007</td><td align="left">LSRegistration
Primer/Development Lessons Learned</td><td align="left">J.
Zurawski</td></tr></tbody></table></div></div><br class="tabl
e-break" /></div><div class="section" lang="en" xml:lang="en!
"><div c
lass="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="introduction"></a>2. Introduction</h2></div></div></div><p>
+ This document builds upon the work described in [<a
href="#id2542823"><span class="citation">dLS</span></a>]
to create <span><strong class="command">Phase 1</strong></span> of the
proposed distributed
information service. This document will describe concrete details of
the
plan, prescribing both the overall structure of the system as well as
@@ -25,54 +25,66 @@
information.
</p><p>
The remainder of the document is structured as follows:
- <a href="#architecture">Architecture</a> will go into details of the
system as
- viewed from afar. Issues such as communication and individual service
- behavior will be discussed. <a href="#api">API</a> will describe the
- interface service developers will implement to interact with this
system.
- <a href="#operation">Operation</a> will lay out some common use cases
and
- examples. <a href="#implementation">Implementation</a> will discuss
some
- algorithms and specific considerations that the both reference
- implementations will need to take into account. Finally
- <a href="#appendix">Appendix</a> details some XML and code examples to
be used
- in the construction of this service.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="architecture"></a>3. Architecture</h2></div></div></div><p>
+ in <a href="#preliminaries" title="3. Preliminaries">Preliminaries</a>
the basics of LSRegistration for
+ services will be briefly discussed. <a href="#architecture"
title="4. Architecture">Architecture</a> will
+ go into details of the system as viewed from afar. Issues such as
+ communication and individual service behavior will be discussed.
+ <a href="#api" title="5. API">API</a> will describe the interface
service developers will
+ implement to interact with this system. <a href="#operation"
title="6. Operation">Operation</a> will
+ lay out some common use cases and examples.
+ <a href="#implementation" title="7. Implementation">Implementation</a>
will discuss some algorithms and
+ specific considerations that the both reference implementations will
need
+ to take into account. Finally <a href="#appendix"
title="8. Appendix">Appendix</a> details some
+ XML and code examples to be used in the construction of this service.
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="preliminaries"></a>3. Preliminaries</h2></div></div></div><p>
+ To motivate the discussion of a <span
class="emphasis"><em>Global</em></span> resource
+ discovery system, we must first mention the resources that are
available
+ and the steps they <span class="emphasis"><em>must</em></span> take to
make themselves known
+ to the framework at large. We will first begin in
+ <a href="#preliminaries-service" title="3.1. Service
Definition">Service Definition</a> with a discussion of what defines
+ a <span class="emphasis"><em>perfSONAR</em></span> service.
+ <a href="#preliminaries-registration"
title="3.2. Registration">Registration</a> talks about a minimum set of
+ necessary information that can be used to idenfity and describe a
service.
+ Finally, <a href="#preliminaries-prop" title="3.3. Information
Dissemination">Information Dissemination</a> explores what is desirable
+ for spreading this information to interested parties.
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="preliminaries-service"></a>3.1. Service
Definition</h3></div></div></div><p>TBD</p></div><div class="section"
lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a
id="preliminaries-registration"></a>3.2. Registration</h3></div></div></div><p>TBD</p></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3
class="title"><a id="preliminaries-prop"></a>3.3. Information
Dissemination</h3></div></div></div><p>TBD</p></div></div><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2
class="title" style="clear: both"><a
id="architecture"></a>4. Architecture</h2></div></div></div><p>
The following schematic shows the overall architecture of this system.
</p><p>
</p><div class="mediaobject"><img src="images/architecture.png"
/></div><p>
</p><p>
We will now explain some key features of this architecture:
</p><p>
- </p><div class="orderedlist"><ol type="1"><li><p><a
href="#gLS_instances">gLS Instances</a> - Global,
+ </p><div class="orderedlist"><ol type="1"><li><p><a
href="#gLS_instances" title="4.1. gLS Instances">gLS Instances</a> - Global,
<span class="emphasis"><em>well known</em></span>, LS instances
that will serve as
the <span class="emphasis"><em>top level</em></span> of the
hierarchy. Under normal
conditions <span><strong class="command">only</strong></span>
manage the registration of
<span class="emphasis"><em>hLS</em></span> instances and not other
forms of
- <span class="emphasis"><em>perfSONAR</em></span>
service.</p></li><li><p><a href="#bootstrapping">Bootstrapping</a> - Finding
gLS instances can
+ <span class="emphasis"><em>perfSONAR</em></span>
service.</p></li><li><p><a href="#bootstrapping"
title="4.2. Bootstrapping">Bootstrapping</a> - Finding gLS instances can
be challenging, and we <span><strong class="command">should
not</strong></span> rely only on
well known values. We propose a simple method for this
implementation
phase that will allow other <span
class="emphasis"><em>gLS</em></span> instances,
<span class="emphasis"><em>hLS</em></span>s, and anyone using the
API a chance to
find and communicate with root <span
class="emphasis"><em>gLS</em></span> instances.
- </p></li><li><p><a href="#synchronization">Synchronization</a> -
To ease the burden of
+ </p></li><li><p><a href="#synchronization"
title="4.3. Synchronization">Synchronization</a> - To ease the burden of
discovery, the top level <span
class="emphasis"><em>gLS</em></span> instances should
regularly synchronize their summary sets to ensure that any
discovery
query posed anywhere in the framework can be answered correctly.
- </p></li><li><p><a href="#hLS_instances">hLS Instances</a> - Local
LS instances that
+ </p></li><li><p><a href="#hLS_instances" title="4.4. hLS
Instances">hLS Instances</a> - Local LS instances that
manage the registration of individual services and communicate a
- summary of information to the upper level.</p></li><li><p><a
href="#registration">Multiple Registration</a> - Services may require
+ summary of information to the upper level.</p></li><li><p><a
href="#registration" title="4.5. Multiple Registration">Multiple
Registration</a> - Services may require
modifications to support interaction with more than one LS
instance to
foster both reliability and balancing of load.
- </p></li><li><p><a href="#interaction">Interaction</a> - To use
this new framework,
+ </p></li><li><p><a href="#interaction"
title="4.6. Interaction">Interaction</a> - To use this new framework,
clients and services require a unified access method. This access
requires two components: Discovery (e.g. <span
class="emphasis"><em>where</em></span>
information can be found) and Query (e.g. <span
class="emphasis"><em>what</em></span>
specifically can I find).</p></li></ol></div><p>
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="gLS_instances"></a>3.1. gLS Instances</h3></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="gLS_instances"></a>4.1. gLS Instances</h3></div></div></div><p>
The <span class="emphasis"><em>perfSONAR</em></span> project
partners (e.g.
- <a href="#id2531884">ESnet</a>, <a href="#id2531902">Geant2</a>,
- <a href="#id2531920">Internet2</a>, and <a
href="#id2532214">RNP</a>) are
+ [<a href="#id2542842"><span class="citation">ESnet</span></a>], [<a
href="#id2542860"><span class="citation">Geant2</span></a>],
+ [<a href="#id2542879"><span class="citation">Internet2</span></a>],
and [<a href="#id2542898"><span class="citation">RNP</span></a>]) are
expected to stand up and maintain <span
class="emphasis"><em>root</em></span>
- <a href="#gLS">gLS</a> instances. As the driving force behind
+ <a href="#gLS" title="gLS">gLS</a> instances. As the driving force
behind
<span class="emphasis"><em>perfSONAR</em></span>, this contribution
serves as the basis
for all distributed information discovery. The purpose of these LS
instances is similar to the function of the DNS root servers: well
known
@@ -97,15 +109,15 @@
point of contact with regards to locating information; therefore
each
root should know the complete contents at any given time. To
accomplish
the goals of <span class="emphasis"><em>gLS</em></span> discovery we
rely on some
- <a href="#bootstrapping">Bootstrapping</a> techniques that allow
service and
+ <a href="#bootstrapping"
title="4.2. Bootstrapping">Bootstrapping</a> techniques that allow service and
client applications alike the ability to access the
<span class="emphasis"><em>upper layer</em></span> consisting of
<span class="emphasis"><em>gLS</em></span>
deployments. To ensure that <span
class="emphasis"><em>gLS</em></span> instances are
- relevant, an additional data <a
href="#synchronization">Synchronization</a> step is
+ relevant, an additional data <a href="#synchronization"
title="4.3. Synchronization">Synchronization</a> step is
also required.
</p><p>
- The <a href="#bootstrapping">Bootstrapping</a> and
- <a href="#synchronization">Synchronization</a> ensure that a
+ The <a href="#bootstrapping"
title="4.2. Bootstrapping">Bootstrapping</a> and
+ <a href="#synchronization"
title="4.3. Synchronization">Synchronization</a> ensure that a
<span class="emphasis"><em>Discovery</em></span> query posed to any
root is able to be
completed. In addition to the process to propagate registration
information through <span
class="emphasis"><em>synchronization</em></span> the
@@ -127,7 +139,7 @@
any summarization and discovery activities (unless the
<span class="emphasis"><em>gLS</em></span> summarizes itself, and is
able to include this
information in the discovery phase).
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="bootstrapping"></a>3.2. Bootstrapping</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="bootstrapping"></a>4.2. Bootstrapping</h3></div></div></div><p>
The deployment locations of the <span
class="emphasis"><em>gLS</em></span> may be broadly
known, but the specific contact information will probably not be. It
will be necessary for the <span class="emphasis"><em>gLS</em></span>
instances,
@@ -159,7 +171,7 @@
It is expected that the first option will be implemented immediately,
with the prospects of the second option to follow. The third option
will be depend on participation from the perfSONAR partners.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="synchronization"></a>3.3. Synchronization</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="synchronization"></a>4.3. Synchronization</h3></div></div></div><p>
There are two possible approaches to information discovery using the
<span class="emphasis"><em>gLS</em></span> deployment scenario.
</p><p>
@@ -195,9 +207,9 @@
overloading <span class="emphasis"><em>gLS</em></span> instances or
if it may be able to
function as an on-demand service when new summarizations are
available.
</p><p>
- See <a href="#appendix_synch">Synchronization Example</a> for an
example of a naive
+ See <a href="#appendix_synch" title="8.5. Synchronization
Example">Synchronization Example</a> for an example of a naive
synchronization between LS instances.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="hLS_instances"></a>3.4. hLS Instances</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="hLS_instances"></a>4.4. hLS Instances</h3></div></div></div><p>
This service resembles the current LS implementation. Aside from the
changes that allow the <span class="emphasis"><em>hLS</em></span>
itself to register with
a <span class="emphasis"><em>gLS</em></span> and the addition of the
API, there is little
@@ -235,7 +247,7 @@
incorporate the <span class="emphasis"><em>Patricia
Trie</em></span> data structure to
naively find <span class="emphasis"><em>K Dominators</em></span>
from a list of
addresses. See also
- <a href="#appendix_summarization_source">Summarization Source
Code</a>.</p></li><li style="list-style-type: circle"><p><span><strong
class="command">Host/Domain Names</strong></span> - Similar to IP
+ <a href="#appendix_summarization_source"
title="8.4. Summarization Source Code">Summarization Source
Code</a>.</p></li><li style="list-style-type: circle"><p><span><strong
class="command">Host/Domain Names</strong></span> - Similar to IP
Addresses, the hostname of each service will be extracted and
broken into sub elements (e.g.
<span class="emphasis"><em>stout.pc.cis.udel.edu</em></span> is
really an
@@ -264,7 +276,7 @@
due to code reuse it is understood that any given deployment may be a
<span class="emphasis"><em>gLS</em></span> or <span
class="emphasis"><em>hLS</em></span> so the necessary
tooling to do either approach would be available.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="registration"></a>3.5. Multiple Registration</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="registration"></a>4.5. Multiple Registration</h3></div></div></div><p>
The following diagram illustrates the procedure of an
<span class="emphasis"><em>hLS</em></span> instance registering with
two distinct
<span class="emphasis"><em>gLS</em></span> instances.
@@ -291,10 +303,10 @@
</p><p>
We leave the option of multiple registration up to the individual
service designers.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="interaction"></a>3.6. Interaction</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="interaction"></a>4.6. Interaction</h3></div></div></div><p>
Currently, services and clients only have a single way to query an
- <span class="emphasis"><em>LS</em></span> instance for data: <a
href="#id2532250">XQuery</a>
- or <a href="#id2532232">XPath</a> statements. While useful to
individuals
+ <span class="emphasis"><em>LS</em></span> instance for data: [<a
href="#id2542934"><span class="citation">XQuery</span></a>]
+ or [<a href="#id2542915"><span class="citation">XPath</span></a>]
statements. While useful to individuals
with an intimate knowledge of the data storage structure and the
query
language syntax, this leaves other services and client applications
frustrated and out of luck when it comes to lookup.
@@ -325,8 +337,8 @@
range, eventType, or other specific features that pertain to the
data and service type.</p></li></ul></div><p>
</p><p>
- The API will be specified in <a href="#api">API</a>.
- </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="api"></a>4. API</h2></div></div></div><p>
+ The API will be specified in <a href="#api" title="5. API">API</a>.
+ </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="api"></a>5. API</h2></div></div></div><p>
To effectively navigate through the distributed information service, an
effective and complete API is necessary. This API should offer ways
to
perform two important tasks (together, and separately as needed):
@@ -355,15 +367,16 @@
lower level functionality that is able to expose more primitive
operations
should remain available. The following breakdown isolates the various
functions:
- </p><div class="table"><a id="table.2"></a><p
class="title"><b>Table 2. LS API</b></p><div class="table-contents"><table
summary="LS API" border="1"><colgroup><col align="left"
/></colgroup><thead><tr><th align="left">API Level</th><th
align="left">Message Type</th><th align="left">Event Type</th><th
align="left">Input</th><th align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td rowspan="4"
align="center" valign="middle"><a href="#level0_api">0</a></td><td
rowspan="8" align="left" valign="middle">LSQueryRequest</td><td
align="left">service.lookup.xquery</td><td rowspan="4" align="left"
valign="middle">XQuery</td><td rowspan="4" align="left" valign="middle">Raw
XML</td><td rowspan="4" align="left" valign="middle">Most primitive
call.</td></tr><tr><td
align="left">http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/xquery/1.0</td></tr><tr><td

align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td>
</tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td></tr><tr><td
rowspan="2" align="center" valign="middle"><a
href="#level1_api">1</a></td><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td><td
align="left">IP, Domain, eventType, Service Data</td><td align="left">hLS
URL Array</td><td align="left">Standalone Discovery</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td><td
align="left">hLS, IP, Domain, eventType, Service Data</td><td
align="left">Metadata (e.g. Service/Measurement based) Array</td><td
align="left">Standalone Query</td></tr><tr><td rowspan="2" align="center"
valign="middle"><a href="#level2_api">2</a></td><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td><td
rowspan="2" align="left" valign="middle">IP, Domain, eventType, Service
Data</td><td rowspan="2"
align="left" valign="middle">Metadata (e.g. Service/Measure!
ment bas
ed) Array</td><td rowspan="2" align="left" valign="middle">Complete
Discovery/Query</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td></tr></tbody></table></div></div><br
class="table-break" /><p>
+ </p><div class="table"><a id="table.2"></a><p
class="title"><b>Table 2. LS API</b></p><div class="table-contents"><table
summary="LS API" border="1"><colgroup><col align="left"
/></colgroup><thead><tr><th align="left">API Level</th><th
align="left">Message Type</th><th align="left">Event Type</th><th
align="left">Input</th><th align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td rowspan="4"
align="center" valign="middle"><a href="#level0_api" title="5.1. Level 0
API">0</a></td><td rowspan="10" align="left"
valign="middle">LSQueryRequest</td><td
align="left">service.lookup.xquery</td><td rowspan="4" align="left"
valign="middle">XQuery</td><td rowspan="4" align="left" valign="middle">Raw
XML</td><td rowspan="4" align="left" valign="middle">Most primitive
call.</td></tr><tr><td
align="left">http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/xquery/1.0</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/looku
p/discovery/xquery/2.0</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td></tr><tr><td
rowspan="3" align="center" valign="middle"><a href="#level1_api"
title="5.2. Level 1 API">1</a></td><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td><td
rowspan="2" align="left" valign="middle">IP, Domain, eventType, Service
Data</td><td rowspan="2" align="left" valign="middle">hLS URL Array</td><td
rowspan="2" align="left" valign="middle">Standalone
Discovery</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</td></tr><tr><td

align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td><td
align="left">hLS, IP, Domain, eventType, Service Data</td><td
align="left">Metadata (e.g. Service/Measurement based) Array</td><td
align="left">Standalone Query</td></tr><tr><td rowspan="3" align="center" v
align="middle"><a href="#level2_api" title="5.3. Level 2 AP!
I">2</a>
</td><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</td><td
rowspan="3" align="left" valign="middle">IP, Domain, eventType, Service
Data</td><td rowspan="3" align="left" valign="middle">Metadata (e.g.
Service/Measurement based) Array</td><td rowspan="3" align="left"
valign="middle">Complete Discovery/Query</td></tr><tr><td
align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/xquery/2.0</td></tr><tr><td

align="left">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</td></tr></tbody></table></div></div><br
class="table-break" /><p>
We will now explain in greater detail the expected format of the API
for
the various levels, including function names, parameter lists, as well
as expected behaviors.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level0_api"></a>4.1. Level 0 API</h3></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level0_api"></a>5.1. Level 0 API</h3></div></div></div><p>
The Level 0 API is based on the current query method used in the
<span class="emphasis"><em>LS</em></span>: <span><strong
class="command">LSQueryRequest</strong></span> messages
- sending a raw <span><strong class="command">XQuery</strong></span>
string. We would like to keep
- this base functionality for two reasons:
+ sending a raw <span><strong class="command">XQuery</strong></span>
string sent directly to the
+ LSQuery interface. We would like to keep this base functionality for
+ two reasons:
</p><p>
</p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p>
This method will serve as the base that upper levels of this
API
@@ -376,7 +389,7 @@
</p><p>
There are only minor modifications that must be made to the existing
<span><strong class="command">LSQueryRequest</strong></span>
functionality, mainly the addition of
- two new <span class="emphasis"><em>eventType</em></span>s. These
+ three new <span class="emphasis"><em>eventType</em></span>s. These
<span class="emphasis"><em>eventType</em></span>s will not only help
this level isolate
the specific dataset to query, but provided needed functionality to
the
abstractions built on top of Level 0:
@@ -391,14 +404,14 @@
backend storage holding registered information.
</p></li></ul></div><p>
</p><p>
- These <span class="emphasis"><em>eventType</em></span>s are more of
an
+ These two <span class="emphasis"><em>eventType</em></span>s are more
of an
<span class="emphasis"><em>ease of design</em></span> feature for
the implementers of the
<span class="emphasis"><em>gLS</em></span> and <span
class="emphasis"><em>hLS</em></span> due to the nature
of the backend storage mechanisms. The existing
<span class="emphasis"><em>eventType</em></span>s, as well as
message structure regarding
subject and parameters, will remain unchanged.
</p><p>
- Addtional considerations for this level of the API revolve around the
+ Additional considerations for this level of the API revolve around
the
internal representation of when data is set to expire, namely the
<span class="emphasis"><em>LS*-control</em></span> structure. It is
desirable to
have access to this when providing status reports about registered
@@ -415,8 +428,13 @@
backend storage holding registered control information.
</p></li></ul></div><p>
</p><p>
- An API breakdown follows:
- </p><div class="table"><a id="table.api.l0"></a><p
class="title"><b>Table 3. Level 0 API Calls</b></p><div
class="table-contents"><table summary="Level 0 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSDiscoveryRaw</td><td rowspan="2" align="left"
valign="middle">LS & XQuery String</td><td rowspan="2" align="left"
valign="middle">Raw XML (e.g. XML elements in an array)</td><td
align="left">Send XQuery for results in the <span
class="emphasis"><em>Summary</em></span> storage only.</td></tr><tr><td
align="left">getLSQueryRaw</td><td align="left">Send XQuery for results in
the <span class="emphasis"><em>Registered</em></span> storage
only.</td></tr><tr><td align="left">getLSSummaryControlRaw</td><td
rowspan="2" align="left" valign="middle">LS & XQuery String</td><td
rowspan=
"2" align="left" valign="middle">Raw XML (e.g. XML elements in an
array)</td><td align="left">Send XQuery for results from the <span
class="emphasis"><em>Summary</em></span> control storage
only.</td></tr><tr><td align="left">getLSRegistrationControlRaw</td><td
align="left">Send XQuery for results from the <span
class="emphasis"><em>Registered</em></span> control storage
only.</td></tr></tbody></table></div></div><br class="table-break"
/></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level1_api"></a>4.2. Level 1 API</h3></div></div></div><p>
+ While desirable, these two <span
class="emphasis"><em>eventType</em></span>s remain
+ optional and services should report their ability to use or not use
them
+ when queried.
+ </p><p>
+ An implementation of an API to access this data can be broken down as
+ follows:
+ </p><div class="table"><a id="table.api.l0"></a><p
class="title"><b>Table 3. Level 0 API Calls</b></p><div
class="table-contents"><table summary="Level 0 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSDiscoveryRaw</td><td rowspan="2" align="left"
valign="middle">LS & XQuery String</td><td rowspan="2" align="left"
valign="middle">Raw XML (e.g. XML elements in an array)</td><td
align="left">Send XQuery for results in the <span
class="emphasis"><em>Summary</em></span> storage only.</td></tr><tr><td
align="left">getLSQueryRaw</td><td align="left">Send XQuery for results in
the <span class="emphasis"><em>Registered</em></span> storage
only.</td></tr><tr><td align="left">getLSSummaryControlRaw</td><td
rowspan="2" align="left" valign="middle">LS & XQuery String</td><td
rowspan=
"2" align="left" valign="middle">Raw XML (e.g. XML elements in an
array)</td><td align="left">Send XQuery for results from the <span
class="emphasis"><em>Summary</em></span> control storage
only.</td></tr><tr><td align="left">getLSRegistrationControlRaw</td><td
align="left">Send XQuery for results from the <span
class="emphasis"><em>Registered</em></span> control storage
only.</td></tr></tbody></table></div></div><br class="table-break"
/></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level1_api"></a>5.2. Level 1 API</h3></div></div></div><p>
The Level 1 API offers a the first true way of abstracting the
queries
to the LS by identifying a series of well defined parameters as input
as well as structured output. This particular portion of the API
will
@@ -426,13 +444,44 @@
level will not require any additional modifications to be made to the
<span><strong class="command">LSQueryRequest</strong></span>, as it
will utilize Level 0 API calls.
</p><p>
- An API breakdown follows:
- </p><div class="table"><a id="table.api.l1"></a><p
class="title"><b>Table 4. Level 1 API Calls</b></p><div
class="table-contents"><table summary="Level 1 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSDiscovery</td><td align="left">(IP Address | Domain) |
eventType | Service Type</td><td align="left">hLS URL Array</td><td
align="left">Given several input parameters, return a list of <span
class="emphasis"><em>hLS</em></span>s</td></tr><tr><td
align="left">getLSQueryLocation</td><td rowspan="2" align="left"
valign="left">hLS & ((IP Address | Domain) | eventType | Service
Type)</td><td align="left">Service Metadata Array</td><td align="left">Given
several input parameters, return a list of <span
class="emphasis"><em>Service</em></span> metadata elements.</td></tr><tr><td
align
="left">getLSQueryContent</td><td align="left">Measurement Metadata
Array</td><td align="left">Given several input parameters, return a list of
<span class="emphasis"><em>Measurement</em></span> metadata
elements.</td></tr></tbody></table></div></div><br class="table-break" /><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4
class="title"><a id="level1_api_ext"></a>4.2.1. Level 1 API
Extension</h4></div></div></div><p>
+ In addition to the aforementioned <span
class="emphasis"><em>XQuery</em></span>
+ interfaces from <span><strong class="command">Level
0</strong></span>, it is desirable to create
+ a higher level Message that has direct access to the summarized
+ information, without needing to worry about the exact structure
+ (<span><strong class="command">N.B.</strong></span> this allows
implementations the ability
+ to construct higher speed caching and summarization procedures that
do
+ not need to involve <span class="emphasis"><em>XML</em></span>). We
introduce a new
+ evnet type that serves as a conduit to this particular interface:
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</strong></span>
+ An example message that takes advantage can be seen in
+ <a href="#appendix_summary_request" title="8.2. LSQuery Request
(Discovery) Example">LSQuery Request (Discovery) Example</a>. The response
to this
+ message can be seen in <a href="#appendix_summary_response"
title="8.3. LSQuery Response (Discovery) Example">LSQuery Response
(Discovery) Example</a>.
+ </p><p>
+ The following <span class="emphasis"><em>eventType</em></span>s are
used in this Level of
+ the API:
+ </p><p>
+ </p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/control/xquery/2.0</strong></span>
+ - Discussed in <a href="#level0_api" title="5.1. Level 0
API">0</a>
+ </p></li><li style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/control/xquery/2.0</strong></span>
+ - Discussed in <a href="#level0_api" title="5.1. Level 0
API">0</a>
+ </p></li><li style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</strong></span>
+ - Allows a specially crafted query (independent of
+ <span class="emphasis"><em>XQuery</em></span> language) to
query the summarized dataset
+ of a gLS (or in some cases an hLS, although this is less
common).
+ </p></li></ul></div><p>
+ </p><p>
+ An implementation of an API to access this data can be broken down as
+ follows:
+ </p><div class="table"><a id="table.api.l1"></a><p
class="title"><b>Table 4. Level 1 API Calls</b></p><div
class="table-contents"><table summary="Level 1 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSDiscovery</td><td align="left">(IP Address | Domain) |
eventType | Service Type</td><td align="left">hLS URL Array</td><td
align="left">Given several input parameters, return a list of <span
class="emphasis"><em>hLS</em></span>s</td></tr><tr><td
align="left">getLSQueryLocation</td><td rowspan="2" align="left"
valign="left">hLS & ((IP Address | Domain) | eventType | Service
Type)</td><td align="left">Service Metadata Array</td><td align="left">Given
several input parameters, return a list of <span
class="emphasis"><em>Service</em></span> metadata elements.</td></tr><tr><td
align
="left">getLSQueryContent</td><td align="left">Measurement Metadata
Array</td><td align="left">Given several input parameters, return a list of
<span class="emphasis"><em>Measurement</em></span> metadata
elements.</td></tr></tbody></table></div></div><br class="table-break" /><div
class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4
class="title"><a id="level1_api_ext"></a>5.2.1. Level 1 API
Extension</h4></div></div></div><p>
The following extension may be made to the <span><strong
class="command">Level 0</strong></span>
functions dealing with access to the
<span class="emphasis"><em>LS*-control</em></span> structures.
These formats are
presented mearly as a suggestion as they are optional to the
overall
- success of the framework.
+ success of the framework. Services should note if they do or do
not
+ implement these calls.
</p><p>
Note there is not an implicit <span
class="emphasis"><em>Discovery</em></span> step, the
specific query you are interested must be posed directly to a given
@@ -443,28 +492,44 @@
<span><strong class="command">Level 0</strong></span>.
</p><p>
An API breakdown follows:
- </p><div class="table"><a id="table.api.l1.c"></a><p
class="title"><b>Table 5. Additional Level 1 API Calls</b></p><div
class="table-contents"><table summary="Additional Level 1 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSSummaryControlDirect</td><td rowspan="2" align="left"
valign="left">LS & (Service Type | Name | AccessPoint)</td><td
rowspan="2" align="left" valign="middle">Time Array</td><td
align="left">Given an LS instance and service information, return array of
times from the <span class="emphasis"><em>Summarization</em></span> control
storage only.</td></tr><tr><td
align="left">getLSRegistrationControlDirect</td><td align="left">Given an LS
instance and service information, return array of times from the <span
class="emphasis"><em>Registered</em></span> control
storage only.</td></tr></tbody></table></div></div><br class="table-break"
/></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level2_api"></a>4.3. Level 2 API</h3></div></div></div><p>
+ </p><div class="table"><a id="table.api.l1.c"></a><p
class="title"><b>Table 5. Additional Level 1 API Calls</b></p><div
class="table-contents"><table summary="Additional Level 1 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSSummaryControlDirect</td><td rowspan="2" align="left"
valign="left">LS & (Service Type | Name | AccessPoint)</td><td
rowspan="2" align="left" valign="middle">Time Array</td><td
align="left">Given an LS instance and service information, return array of
times from the <span class="emphasis"><em>Summarization</em></span> control
storage only.</td></tr><tr><td
align="left">getLSRegistrationControlDirect</td><td align="left">Given an LS
instance and service information, return array of times from the <span
class="emphasis"><em>Registered</em></span> control
storage only.</td></tr></tbody></table></div></div><br class="table-break"
/></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="level2_api"></a>5.3. Level 2 API</h3></div></div></div><p>
The highest level of this API will perform all work with regards to
discovery and query in a single call. It is expected that services
and
client applications will make use of this API instead of manually
using
the previous 2 layers.
+ </p><p>
+ The following <span class="emphasis"><em>eventType</em></span>s are
used in this Level of
+ the API:
</p><p>
- An API breakdown follows:
- </p><div class="table"><a id="table.api.l2"></a><p
class="title"><b>Table 6. Level 2 API Calls</b></p><div
class="table-contents"><table summary="Level 2 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSLocation</td><td rowspan="2" align="left" valign="left">(IP
Address | Domain) | eventType | Service Type</td><td align="left">Service
Metadata Array</td><td align="left">Given several input parameters, return a
list of <span class="emphasis"><em>Service</em></span> metadata
elements.</td></tr><tr><td align="left">getLSContent</td><td
align="left">Measurement Metadata Array</td><td align="left">Given several
input parameters, return a list of <span
class="emphasis"><em>Measurement</em></span> metadata
elements.</td></tr></tbody></table></div></div><br class="table-break" /><div
clas
s="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4
class="title"><a id="level2_api_ext"></a>4.3.1. Level 2 API
Extension</h4></div></div></div><p>
+ </p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/control/xquery/2.0</strong></span>
+ - Discussed in <a href="#level0_api" title="5.1. Level 0
API">0</a>
+ </p></li><li style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/query/control/xquery/2.0</strong></span>
+ - Discussed in <a href="#level0_api" title="5.1. Level 0
API">0</a>
+ </p></li><li style="list-style-type: circle"><p>
+ <span><strong
class="command">http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/summary/2.0</strong></span>
+ - Discussed in <a href="#level1_api" title="5.2. Level 1
API">1</a>
+ </p></li></ul></div><p>
+ </p><p>
+ An implementation of an API to access this data can be broken down as
+ follows:
+ </p><div class="table"><a id="table.api.l2"></a><p
class="title"><b>Table 6. Level 2 API Calls</b></p><div
class="table-contents"><table summary="Level 2 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSLocation</td><td rowspan="2" align="left" valign="left">(IP
Address | Domain) | eventType | Service Type</td><td align="left">Service
Metadata Array</td><td align="left">Given several input parameters, return a
list of <span class="emphasis"><em>Service</em></span> metadata
elements.</td></tr><tr><td align="left">getLSContent</td><td
align="left">Measurement Metadata Array</td><td align="left">Given several
input parameters, return a list of <span
class="emphasis"><em>Measurement</em></span> metadata
elements.</td></tr></tbody></table></div></div><br class="table-break" /><div
clas
s="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4
class="title"><a id="level2_api_ext"></a>5.3.1. Level 2 API
Extension</h4></div></div></div><p>
The following extension may be made to the <span><strong
class="command">Level 0</strong></span>
and <span><strong class="command">Level 1</strong></span>
functions dealing with access to the
<span class="emphasis"><em>LSStore-control</em></span> structures.
These formats are
presented mearly as a suggestion as they are optional to the
overall
- success of the framework.
+ success of the framework. Services should indicate if they support
+ these calls.
</p><p>
An API breakdown follows:
- </p><div class="table"><a id="table.api.l2.c"></a><p
class="title"><b>Table 7. Additional Level 2 API Calls</b></p><div
class="table-contents"><table summary="Additional Level 2 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSSummaryControl</td><td rowspan="2" align="left"
valign="left">Service Type | Name | AccessPoint</td><td rowspan="2"
align="left" valign="middle">Time Array</td><td align="left">Given an LS
instance and service information, return array of times from the <span
class="emphasis"><em>Summarization</em></span> control storage
only.</td></tr><tr><td align="left">getLSRegistrationControl</td><td
align="left">Given an LS instance and service information, return array of
times from the <span class="emphasis"><em>Registered</em></span> control
storage only.</td></tr
></tbody></table></div></div><br class="table-break"
>/></div></div></div><div class="section" lang="en" xml:lang="en"><div
>class="titlepage"><div><div><h2 class="title" style="clear: both"><a
>id="operation"></a>5. Operation</h2></div></div></div><p>
+ </p><div class="table"><a id="table.api.l2.c"></a><p
class="title"><b>Table 7. Additional Level 2 API Calls</b></p><div
class="table-contents"><table summary="Additional Level 2 API Calls"
border="1"><colgroup><col align="left" /></colgroup><thead><tr><th
align="left">Function Name</th><th align="left">Input</th><th
align="left">Output</th><th
align="left">Purpose</th></tr></thead><tbody><tr><td
align="left">getLSSummaryControl</td><td rowspan="2" align="left"
valign="left">Service Type | Name | AccessPoint</td><td rowspan="2"
align="left" valign="middle">Time Array</td><td align="left">Given an LS
instance and service information, return array of times from the <span
class="emphasis"><em>Summarization</em></span> control storage
only.</td></tr><tr><td align="left">getLSRegistrationControl</td><td
align="left">Given an LS instance and service information, return array of
times from the <span class="emphasis"><em>Registered</em></span> control
storage only.</td></tr
></tbody></table></div></div><br class="table-break"
>/></div></div></div><div class="section" lang="en" xml:lang="en"><div
>class="titlepage"><div><div><h2 class="title" style="clear: both"><a
>id="operation"></a>6. Operation</h2></div></div></div><p>
<span><strong class="command">TBD</strong></span>
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="implementation"></a>6. Implementation</h2></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h2 class="title" style="clear: both"><a
id="implementation"></a>7. Implementation</h2></div></div></div><p>
The following sections detail notes on implementation. These will
change
as the development effort progresses, and eventually will be moved
into individual service documentation.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_general"></a>6.1. Overall
Considerations</h3></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_general"></a>7.1. Overall
Considerations</h3></div></div></div><p>
The following <span class="emphasis"><em>eventType</em></span>s
should begin to be
introduced into <span class="emphasis"><em>hLS</em></span> and <span
class="emphasis"><em>gLS</em></span>
exchanges to allow the ability to query the individual data-sets
(e.g.
@@ -496,31 +561,31 @@
following <span class="emphasis"><em>eventType</em></span>s:
</p><p>
</p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type:
circle"><p>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/key/summary/2.0</p></li><li
style="list-style-type:
circle"><p>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/key/service/2.0</p></li></ul></div><p>
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_java"></a>6.2. Java
Considerations</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_java"></a>7.2. Java
Considerations</h3></div></div></div><p>
<span><strong class="command">TBD</strong></span>
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_perl"></a>6.3. Perl
Considerations</h3></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="implementation_perl"></a>7.3. Perl
Considerations</h3></div></div></div><p>
The following represents a list of changes that must be made to the
Perl implementation along with related commentary.
</p><p>
</p><div class="itemizedlist"><ul type="opencircle"><li
style="list-style-type: circle"><p>
- <a href="#implementation_perl_mode">gLS and hLS Operation
Differences</a> - The
+ <a href="#implementation_perl_mode" title="7.3.1. gLS and hLS
Operation Differences">gLS and hLS Operation Differences</a> - The
<span class="emphasis"><em>gLS</em></span> will have special
functionality beyond
the <span class="emphasis"><em>hLS</em></span> and vice versa.
</p></li><li style="list-style-type: circle"><p>
- <a href="#implementation_perl_summarization">Summarizing
Registered Data</a> - The data
+ <a href="#implementation_perl_summarization"
title="7.3.2. Summarizing Registered Data">Summarizing Registered Data</a> -
The data
must be summarized in some way and conveyed to the
<span class="emphasis"><em>gLS</em></span> layer.
</p></li><li style="list-style-type: circle"><p>
- <a href="#implementation_perl_storage">Storage
Reorganization</a> - The summarized
+ <a href="#implementation_perl_storage" title="7.3.3. Storage
Reorganization">Storage Reorganization</a> - The summarized
data must be stored somewhere.
</p></li><li style="list-style-type: circle"><p>
- <a href="#implementation_perl_registration">Multiple and Self
Registration</a> - Changes to
+ <a href="#implementation_perl_registration"
title="7.3.4. Multiple and Self Registration">Multiple and Self
Registration</a> - Changes to
how we treat the act of registration.
</p></li><li style="list-style-type: circle"><p>
- <a href="#implementation_perl_ets">EventTypes</a> - Several new
+ <a href="#implementation_perl_ets"
title="7.3.5. EventTypes">EventTypes</a> - Several new
eventTypes are necessary.
</p></li></ul></div><p>
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_mode"></a>6.3.1. gLS and hLS Operation
Differences</h4></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_mode"></a>7.3.1. gLS and hLS Operation
Differences</h4></div></div></div><p>
The <span class="emphasis"><em>gLS</em></span> must contain the
following functionality
that is not currently found (or should be turned off in) in the LS:
</p><p>
@@ -559,9 +624,9 @@
<span class="emphasis"><em>hLS</em></span>). To enable the <span
class="emphasis"><em>gLS</em></span>
mode the switch will manually need to be edited in the
<span><strong class="command">daemon.conf</strong></span> file.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_summarization"></a>6.3.2. Summarizing Registered
Data</h4></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_summarization"></a>7.3.2. Summarizing Registered
Data</h4></div></div></div><p>
Using the example code in
- <a href="#appendix_summarization_source_perl">Summarization Source
Code (Perl)</a>, a summarization
+ <a href="#appendix_summarization_source_perl"
title="8.4.2. Summarization Source Code (Perl)">Summarization Source Code
(Perl)</a>, a summarization
of the registered data should be completed on-demand (e.g. If new
information is registered, the summary should be re-run and the
information re-registered with the <span
class="emphasis"><em>gLS</em></span> layer.
@@ -575,7 +640,7 @@
standpoint to keep all summarized info together, but having a
faster
<span class="emphasis"><em>cache</em></span> of your own summary
may prove to be
worthwhile.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_storage"></a>6.3.3. Storage
Reorganization</h4></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_storage"></a>7.3.3. Storage
Reorganization</h4></div></div></div><p>
Currently it is an option to specify the name of the collection
that
the registered data will reside in (e.g.
<span class="emphasis"><em>store.dbxml</em></span> or similar).
We will require the
@@ -592,7 +657,7 @@
is much easier to query than checking the configuration for the
exact container name, and modifying the existing
<span class="emphasis"><em>XQuery</em></span> to take this into
consideration.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_registration"></a>6.3.4. Multiple and Self
Registration</h4></div></div></div><p>
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_registration"></a>7.3.4. Multiple and Self
Registration</h4></div></div></div><p>
Currently the tooling to support registration to multiple LS
instances
is not as error resistant as it should be. The operation works,
but
does not do much in the way of checking the result codes of each
@@ -602,14 +667,14 @@
own summary information. This will mean using the accessPoint as
a <span class="emphasis"><em>default</em></span> LS instance.
This will also mean
addressing the storage issue discussed in
- <a href="#implementation_perl_storage">Storage Reorganization</a>.
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_ets"></a>6.3.5. EventTypes</h4></div></div></div><p>
- See <a href="#implementation_general">Overall Considerations</a>
for a list. The
+ <a href="#implementation_perl_storage" title="7.3.3. Storage
Reorganization">Storage Reorganization</a>.
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="implementation_perl_ets"></a>7.3.5. EventTypes</h4></div></div></div><p>
+ See <a href="#implementation_general" title="7.1. Overall
Considerations">Overall Considerations</a> for a list. The
immediate plan may avoid use of the time extension.
- </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h2 class="title"
style="clear: both"><a id="appendix"></a>7. Appendix</h2></div></div></div><p>
+ </p></div></div></div><div class="section" lang="en"
xml:lang="en"><div class="titlepage"><div><div><h2 class="title"
style="clear: both"><a id="appendix"></a>8. Appendix</h2></div></div></div><p>
The following sections describe some of the more concreate details of
this
implementation when applicable.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_summary"></a>7.1. Summary Message
Example</h3></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_summary"></a>8.1. Summary Message
Example</h3></div></div></div><p>
Each <span class="emphasis"><em>hLS</em></span> instance must
register a summary of the
data it is aware of with the <span
class="emphasis"><em>gLS</em></span> or
<span class="emphasis"><em>gLS</em></span>s it communicates with.
This summary should
@@ -737,14 +802,143 @@

<b style="color:blue">
+
+ <b style="color:blue"></summary:subject</b><b
style="color:green"></b><b style="color:blue">></b>
+
+ <b style="color:blue">
+
+ <b style="color:blue"><nmwg:metadata</b><b style="color:green">
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
id="9fe2a44e68fb22a51249f9b3e67137d0"</b><b style="color:blue">></b>
+ <b style="color:blue"><perfsonar:subject</b><b style="color:green">
xmlns:perfsonar="http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/";
id="commonParameters2"</b><b style="color:blue">></b>
+ <b style="color:blue"><psservice:service</b><b
style="color:green">
xmlns:psservice="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/1.0/";
id="serviceParameters2"</b><b style="color:blue">></b>
+ <b style="color:blue"><psservice:serviceName</b><b
style="color:green"></b><b style="color:blue">></b>My_test_MA2<b
style="color:blue"></psservice:serviceName</b><b
style="color:green"></b><b style="color:blue">></b>
+ <b style="color:blue"><psservice:accessPoint</b><b
style="color:green"></b><b
style="color:blue">></b>http://localhost:8081/axis/services/snmpMA<b
style="color:blue"></psservice:accessPoint</b><b
style="color:green"></b><b style="color:blue">></b>
+ <b style="color:blue"><psservice:serviceType</b><b
style="color:green"></b><b style="color:blue">></b>MA<b
style="color:blue"></psservice:serviceType</b><b
style="color:green"></b><b style="color:blue">></b>
+ <b style="color:blue"><psservice:serviceDescription</b><b
style="color:green"></b><b style="color:blue">></b>This is my testing
MA2<b style="color:blue"></psservice:serviceDescription</b><b
style="color:green"></b><b style="color:blue">></b>
+ <b style="color:blue"></psservice:service</b><b
style="color:green"></b><b style="color:blue">></b>
+ <b style="color:blue"></perfsonar:subject</b><b
style="color:green"></b><b style="color:blue">></b>
+ <b style="color:blue"></nmwg:metadata</b><b
style="color:green"></b><b style="color:blue">></b>
+ <b style="color:blue"></nmwg:data</b><b style="color:green"></b><b
style="color:blue">></b>
+
+<b style="color:blue"></nmwg:message</b><b style="color:green"></b><b
style="color:blue">></b>
+
+<b style="color:blue"><!--</b><b style="color:green"> End XML --</b><b
style="color:blue">></b>
+
+ </pre></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_summarization_source"></a>8.4. Summarization Source
Code</h3></div></div></div><p>
As a proof of concept to performing a rudimentary
<span class="emphasis"><em>K Dominators</em></span> identification
of the IP addresses an
<span class="emphasis"><em>hLS</em></span> will know of, consider
the following source
code written in both Java and Perl.
- </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="appendix_summarization_source_java"></a>7.2.1. Summarization Source Code
(Java)</h4></div></div></div><p>
+ </p><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="appendix_summarization_source_java"></a>8.4.1. Summarization Source Code
(Java)</h4></div></div></div><p>
<span><strong class="command">TBD</strong></span>
- </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="appendix_summarization_source_perl"></a>7.2.2. Summarization Source Code
(Perl)</h4></div></div></div><pre class="programlisting">
+ </p></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h4 class="title"><a
id="appendix_summarization_source_perl"></a>8.4.2. Summarization Source Code
(Perl)</h4></div></div></div><pre class="programlisting">

# Begin

@@ -788,14 +982,15 @@
# IP Trie Data Structure (similar to Net::Patricia)
my $tr = Net::IPTrie->new( version => 4 );

-# I need to be able to do my own manipulations
+# I need to be able to do my own manipulations (e.g. IPTrie is not really
+# that great...)
my %tree = ();

# Ensure that each child only has one parent (IPTrie data structure
# uses a strange internal representation).
my %claim = ();

-# starting list of IPs [UDel addresses from all over the domain]
+# starting list of IPs

my @map = ("128.175.13.92",
"128.175.13.74",
@@ -818,17 +1013,22 @@
# "80.15.11.2",
# "80.15.11.3");

+#my @map = ("64.57.25.15",
+# "64.57.27.4",
+# "64.57.27.138",
+# "128.4.12.12",
+# "128.4.13.1",
+# "160.135.1.1",
+# "207.75.165.151",
+# "207.72.226.18",
+# "206.72.224.1");
+
my $vote =
getCDIRSummaries(\@map);
$tr =
makePatriciaTrie(\@map,
$vote, $tr);
-manipulatePatriciaTrie($tr);
+manipulatePatriciaTrie(\@map,
$tr);
genGraph(\%tree);
-my $final = listMinDoms();
+listMinDoms();

-print "Min Dominators:\n\n";
-foreach my $f (@{$final}) {
- print $f , "\n";
-}
-
exit(1);

=head2 getCDIRSummaries($map)
@@ -842,30 +1042,17 @@
sub getCDIRSummaries {
my($map) = @_;

- # We can get ALL applicable CIDR summaries for each (in order of least to
- # greatest).
-
- my %vote = ();
+ my %tally = ();
foreach my $host (@{$map}) {
my @list = Net::CIDR::addr2cidr($host);
foreach my $range (@list) {
- $vote{$range}++ if defined $vote{$range};
- $vote{$range} = 1 if not defined $vote{$range};
- }
- }
+
+ # we want to ingore the wildcard addresses...
+ next if $range =~ m/^0\./;

- # organize the votes into popularity groups
-
- my %tally = ();
- foreach my $range (sort keys %vote) {
- if(defined $tally{$vote{$range}}) {
- push @{$tally{$vote{$range}}}, $range;
+ $tally{$range}++ if defined $tally{$range};
+ $tally{$range} = 1 if not defined $tally{$range};
}
- else {
- my @temp = ();
- push @temp, $range;
- $tally{$vote{$range}} =
\@temp;
- }
}

return \%tally;
@@ -881,7 +1068,7 @@
=cut

sub makePatriciaTrie {
- my($map, $votes, $tr) = @_;
+ my($map, $tally, $tr) = @_;

# Start to make the IPTrie data structure. First we add in all
# of the 'base' addresses
@@ -890,24 +1077,37 @@
$tr->add( address => $host, prefix => "32" );
}

- # Now we add in the summaries. We should try to find the
- # dominators in each 'vote' group first. This will ensure
- # we are closer to a minimal set
+ # Now we add in the summaries.

- foreach my $t (keys %{$votes}) {
- my @total = ();
- foreach my $addr (@{$votes->{$t}}) {
- @total = Net::CIDR::cidradd($addr, @total);
- }
- foreach my $t2 (@total) {
- my @parts = split(/\//,$t2);
- $tr->add( address => $parts[0], prefix => $parts[1] );
- }
+ foreach my $t (sort keys %{$tally}) {
+ my @parts = split(/\//,$t);
+ $tr->add( address => $parts[0], prefix => $parts[1] );
}

return $tr;
}

+=head2 extract($parent, $node, $status, $side)
+
+This aux function recursively walks the nodes of the IPTrie structure
+and creates a more usefriendly tree that we will use for manipulation
+and final display.
+
+=cut
+
+sub extract {
+ my($parent, $node, $status, $side) = @_;
+ my $me = "";
+ $me = $node->[3]."/".$node->[5] if defined $node->[3] and defined
$node->[5];
+ if($me and $side and (not $claim{$me})) {
+ push @{$tree{$parent}{"C"}}, $me;
+ $claim{$me} = 1;
+ }
+ $status = extract($parent, $node->[1], $status, "L") if $node->[1]
and (not $status->{"L"});
+ $status = extract($parent, $node->[2], $status, "R") if $node->[2]
and (not $status->{"R"});
+ return $status;
+}
+
=head2 manipulatePatriciaTrie($tr)

Given the IPTrie structure, we need to manually manipulate the nodes into
@@ -916,12 +1116,19 @@
=cut

sub manipulatePatriciaTrie {
- my($tr) = @_;
+ my($map, $tr) = @_;

my $list = ();
my $code = sub { push @$list, shift @_; };
my $count = $tr->traverse( code => $code );

+ # hacky root pointer (gives us unification if the whild card [0.*]
+ # was really needed)
+
+ my @temp = ();
+ $tree{"Root"}{"C"} =
\@temp;
+ $tree{"Root"}{"U"} = "NULL";
+
# we need to go backwards when looking at the IPTrie print out, this is
# is really to be sure children aren't all claimed by the root (the
internal
# structure is a little strange) so this ensures we hit the root last.
@@ -946,102 +1153,79 @@
extract($me, $node, \%status, "");
}

- # link all the parent information
+ # link all the parent information for each node and child
+
foreach my $item (keys %tree) {
foreach my $c (@{$tree{$item}{"C"}}) {
$tree{$c}{"U"} = $item if $c and $item;
}
}

- # No we get to do some manual mainpulation of the tree we just created,
- # there are two cases we should watch out for:
- #
- # 1) Node with only one child, child has children
- # 2) Node with only one child, child is a terminal
- #
- # Based on these two cases we will search the tree searching for
- # candidates. When we find one, be sure to move all the 'pointers'
- # around, and mark the node for deletion

- my @delete = ();
- foreach my $item (keys %tree) {
- if($#{$tree{$item}{"C"}} == 0 and
$#{$tree{$tree{$item}{"C"}->[0]}{"C"}} >= -1) {
- my @size = ($#{$tree{$item}{"C"}},
$#{$tree{$tree{$item}{"C"}->[0]}{"C"}});
-
- # we either look at the node and child, or node and parent as the
- # candidates for replacement.
- my @items = ();
- if($size[1] == -1) {
- @items = ($tree{$item}{"U"}, $item);
+ # First step: Start at the leaves and walk toward the root.
+ # - Every time we see a node with a sinle child, collapse it into the
parent
+ # (we are pruning the tree)
+
+ foreach my $host (@{$map}) {
+ my $current = $host."/32";
+ while($current) {
+ my $delete = "";
+ if($#{$tree{$tree{$current}{"U"}}{"C"}} == 0 and
+ not($current =~ m/\/32$/) and
+ $#{$tree{$current}{"C"}} == 0) {
+ $delete = $current;
+ foreach my $child (@{$tree{$current}{"C"}}) {
+ $tree{$child}{"U"} = $tree{$current}{"U"};
+ }
+ $tree{$tree{$current}{"U"}}{"C"} = $tree{$current}{"C"};
+ delete $tree{$delete}{"C"};
}
- else {
- @items = ($item, $tree{$item}{"C"}->[0]);
- }
+ $current = $tree{$current}{"U"};
+ delete $tree{$delete} if $delete;
+ }
+ }

- # We are assuming this will give us the most dominant
- # node (and that there will only be one).
- my @total = ();
- @total = Net::CIDR::cidradd($items[0], @total);
- @total = Net::CIDR::cidradd($items[1], @total);
+ # Second step: Start at the leaves and walk toward the root.
+ # - Every time we see a single child node, collapse it into the child (this
+ # is the opposite of what we just did, but this handles branching much
+ # better, this is also a form of pruning).

- # move the children
- if($size[1] == -1) {
- push @{$tree{$items[0]}{"C"}}, @{$tree{$items[1]}{"C"}};
+ foreach my $host (@{$map}) {
+ my $current = $host."/32";
+ while($current) {
+ my $delete = "";
+ if($#{$tree{$current}{"C"}} == 0) {
+ $delete = $current;
+ foreach my $child (@{$tree{$delete}{"C"}}) {
+ $tree{$child}{"U"} = $tree{$delete}{"U"};
+ push @{$tree{$tree{$delete}{"U"}}{"C"}}, $child;
+ }
+
my $counter = 0;
- foreach my $c (@{$tree{$items[0]}{"C"}}) {
- if($c eq $items[1]) {
- splice(@{$tree{$items[0]}{"C"}}, $counter, 1);
- last;
+ foreach my $child (@{$tree{$tree{$delete}{"U"}}{"C"}}) {
+ if($child eq $current) {
+ my $remove =
splice(@{$tree{$tree{$delete}{"U"}}{"C"}},$counter,1);
}
$counter++;
}
}
- else {
- $tree{$items[0]}{"C"} = $tree{$items[1]}{"C"};
- }
-
- # mark the node for deletion
- push @delete, $items[1];
-
- # Re-map the children (if any) to the new parent
- foreach my $c (@{$tree{$items[0]}{"C"}}) {
- $tree{$c}{"U"} = $items[0] if $c and $items[0];
- }
+ $current = $tree{$current}{"U"};
+ delete $tree{$delete} if $delete;
}
- }
+ }

- # Get rid of dead nodes identified above (perl doesn't like you deleting
from
- # and 'in use' data structure so deleting needs to be done out of the
- # above loop)
+ # finally link the tree(s) to the root pointer

- foreach my $d (@delete) {
- delete $tree{$d};
+ foreach my $node (keys %tree) {
+ unless($tree{$node}{"U"}) {
+ $tree{$node}{"U"} = "Root";
+ push @{$tree{"Root"}{"C"}}, $node;
+ }
}

return;
}

-=head2 extract($parent, $node, $status, $side)
-
-This aux function recursively walks the nodes of the IPTrie structure
-and creates a more usefriendly tree that we will use for manipulation
-and final display.
-
-=cut
-
-sub extract {
- my($parent, $node, $status, $side) = @_;
- my $me = "";
- $me = $node->[3]."/".$node->[5] if defined $node->[3] and defined
$node->[5];
- if($me and $side and (not $claim{$me})) {
- push @{$tree{$parent}{"C"}}, $me;
- $claim{$me} = 1;
- }
- $status = extract($parent, $node->[1], $status, "L") if $node->[1]
and (not $status->{"L"});
- $status = extract($parent, $node->[2], $status, "R") if $node->[2]
and (not $status->{"R"});
- return $status;
-}
-
=head2 genGraph

Outputs the contents of the tree structure into a "Graphviz" formated
@@ -1056,18 +1240,27 @@

foreach my $item (keys %tree) {
next unless $item;
- my @array = ();
- @array =split(/\//, $item);
+ if($item =~ m/\/\d+$/) {
+ my @array = ();
+ @array =split(/\//, $item);

- # color the terminal elements so we know they are not dominators
- if($array[1] eq "32") {
- print DOT "\t\"" , $item , "\"[ color=crimson, style=filled ];\n";
+ # color the terminal elements so we know they are not dominators
+ if($array[1] eq "32") {
+ print DOT "\t\"" , $item , "\"[ color=crimson, style=filled ];\n";
+ }
+ else {
+ print DOT "\t\"" , $item , "\";\n";
+ }
}
else {
- print DOT "\t\"" , $item , "\";\n";
+ # this is the root...
+
+ print DOT "\t\"" , $item , "\"[ color=yellow, style=filled ];\n";
}
}

+ # output the linkings
+
foreach my $item (keys %tree) {
next unless $item;
foreach my $c (@{$tree{$item}{"C"}}) {
@@ -1097,14 +1290,12 @@
# First locate the root in the tree

my @expand = ();
- foreach my $node (keys %tree) {
- unless($tree{$node}{"U"}) {
+ foreach my $node (sort keys %tree) {
+ if($node and $tree{$node}{"U"} eq "Root") {
# add the root the 'expand' list so we can
# examine it (and it's children, etc.) then
# exit
-
push @expand, $node;
- last;
}
}

@@ -1120,6 +1311,7 @@
while($expand[$counter]) {
my $minDomFlag = 0;
my $expandFlag = 0;
+
foreach my $child (sort @{$tree{$expand[$counter]}{"C"}}) {
my @array = split(/\//, $child);

@@ -1150,7 +1342,12 @@
$counter++;
}

- return
\@minDoms;
+ print "Min Dominators:\n\n";
+ foreach my $f (@minDoms) {
+ print $f , "\n";
+ }
+
+ return;
}

__END__
@@ -1205,7 +1402,7 @@
<span class="emphasis"><em>Net::IPTrie</em></span>) to solve
this problem. Similar
libraries may not be available in Java, but can easily be
re-created.</p></li><li style="list-style-type: circle"><p>The
output (shown below) is currently used to create a
- <a href="#id2532268">Graphviz</a> formated image. The script
can be
+ [<a href="#id2542952"><span
class="citation">Graphviz</span></a>] formated image. The script can be
modified to output the tree in different formats (including
directly into a summarization message).</p></li><li
style="list-style-type: circle"><p>This script does not allow one to specifiy
a set value for
<span class="emphasis"><em>K</em></span> and return only those
dominators. The
@@ -1221,39 +1418,41 @@
# Begin

digraph g {
- "128.0.0.0/9";
+ "128.4.133.163/32"[ color=crimson, style=filled ];
+ "128.175.13.74/32"[ color=crimson, style=filled ];
"128.4.131.23/32"[ color=crimson, style=filled ];
- "128.4.133.163/32"[ color=crimson, style=filled ];
+ "Root"[ color=yellow, style=filled ];
+ "128.175.13.64/27";
+ "128.4.0.0/16";
+ "128.4.40.0/27";
+ "128.0.0.0/8";
+ "128.4.40.17/32"[ color=crimson, style=filled ];
+ "128.4.40.12/32"[ color=crimson, style=filled ];
+ "128.4.133.167/32"[ color=crimson, style=filled ];
+ "128.4.128.0/21";
"128.175.13.92/32"[ color=crimson, style=filled ];
- "128.4.40.0/28";
- "128.4.128.0/17";
- "0.0.0.0/0";
- "128.4.40.17/32"[ color=crimson, style=filled ];
"128.4.133.164/30";
- "128.4.40.12/32"[ color=crimson, style=filled ];
- "128.128.0.0/9";
"128.4.133.164/32"[ color=crimson, style=filled ];
- "128.4.133.167/32"[ color=crimson, style=filled ];
- "128.4.132.0/22";
- "128.4.0.0/17";
- "128.175.13.74/32"[ color=crimson, style=filled ];
+ "128.4.133.160/29";
+ "128.4.40.8/29";
"128.4.40.10/32"[ color=crimson, style=filled ];
- "128.0.0.0/9" -> "128.4.0.0/17";
- "128.0.0.0/9" -> "128.4.128.0/17";
- "128.4.40.0/28" -> "128.4.40.10/32";
- "128.4.40.0/28" -> "128.4.40.12/32";
- "128.4.128.0/17" -> "128.4.132.0/22";
- "128.4.128.0/17" -> "128.4.131.23/32";
- "0.0.0.0/0" -> "128.0.0.0/9";
- "0.0.0.0/0" -> "128.128.0.0/9";
+ "Root" -> "128.0.0.0/8";
+ "128.175.13.64/27" -> "128.175.13.92/32";
+ "128.175.13.64/27" -> "128.175.13.74/32";
+ "128.4.0.0/16" -> "128.4.40.0/27";
+ "128.4.0.0/16" -> "128.4.128.0/21";
+ "128.4.40.0/27" -> "128.4.40.8/29";
+ "128.4.40.0/27" -> "128.4.40.17/32";
+ "128.0.0.0/8" -> "128.175.13.64/27";
+ "128.0.0.0/8" -> "128.4.0.0/16";
+ "128.4.128.0/21" -> "128.4.131.23/32";
+ "128.4.128.0/21" -> "128.4.133.160/29";
+ "128.4.133.164/30" -> "128.4.133.167/32";
"128.4.133.164/30" -> "128.4.133.164/32";
- "128.4.133.164/30" -> "128.4.133.167/32";
- "128.128.0.0/9" -> "128.175.13.74/32";
- "128.128.0.0/9" -> "128.175.13.92/32";
- "128.4.132.0/22" -> "128.4.133.163/32";
- "128.4.132.0/22" -> "128.4.133.164/30";
- "128.4.0.0/17" -> "128.4.40.0/28";
- "128.4.0.0/17" -> "128.4.40.17/32";
+ "128.4.133.160/29" -> "128.4.133.164/30";
+ "128.4.133.160/29" -> "128.4.133.163/32";
+ "128.4.40.8/29" -> "128.4.40.10/32";
+ "128.4.40.8/29" -> "128.4.40.12/32";
}

# End
@@ -1278,7 +1477,7 @@
pick out the top (3 in this case) dominating elements.
</p><p>
</p><div class="mediaobject"><img src="images/graph2.png"
/></div><p>
- </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_synch"></a>7.3. Synchronization Example</h3></div></div></div><p>
+ </p></div></div><div class="section" lang="en" xml:lang="en"><div
class="titlepage"><div><div><h3 class="title"><a
id="appendix_synch"></a>8.5. Synchronization Example</h3></div></div></div><p>
The following example illustrates synchronization using the
perfSONAR-PS framework mainly for backup up <span
class="emphasis"><em>DCN</em></span>
registered information. This small snippet of code is currently used
@@ -1568,20 +1767,20 @@
A <span class="emphasis"><em>globally</em></span> acessible
Lookup Service.
</p></dd></dl></div><div class="glossdiv"><h3
class="title">H</h3><dl><dt><a id="hLS"></a>hLS</dt><dd><p>
The <span class="emphasis"><em>home</em></span> Lookup Service.
- </p></dd></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></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="id2531864"></a><p>[<abbr
class="abbrev">dLS</abbr>] <span class="title"><i>
+ </p></dd></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></dl></div><div class="glossdiv"><dl></dl></div><div
class="glossdiv"><dl></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="id2542823"></a><p>[<abbr
class="abbrev">dLS</abbr>] <span class="title"><i>
<a
href="http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/doc/dLS/dLS_spec_1.html";

target="_top">http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/doc/dLS/dLS_spec_1.html</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2531884"></a><p>[<abbr class="abbrev">ESnet</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542842"></a><p>[<abbr class="abbrev">ESnet</abbr>] <span
class="title"><i>
<a href="http://www.es.net"; target="_top">http://www.es.net</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2531902"></a><p>[<abbr class="abbrev">Geant2</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542860"></a><p>[<abbr class="abbrev">Geant2</abbr>] <span
class="title"><i>
<a href="http://www.geant2.net";
target="_top">http://www.geant2.net</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2531920"></a><p>[<abbr class="abbrev">Internet2</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542879"></a><p>[<abbr class="abbrev">Internet2</abbr>] <span
class="title"><i>
<a href="http://www.internet2.edu";
target="_top">http://www.internet2.edu</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2532214"></a><p>[<abbr class="abbrev">RNP</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542898"></a><p>[<abbr class="abbrev">RNP</abbr>] <span
class="title"><i>
<a href="http://www.rnp.br/en"; target="_top">http://www.rnp.br/en</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2532232"></a><p>[<abbr class="abbrev">XPath</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542915"></a><p>[<abbr class="abbrev">XPath</abbr>] <span
class="title"><i>
<a href="http://www.w3.org/TR/xpath"; target="_top">XPath</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2532250"></a><p>[<abbr class="abbrev">XQuery</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542934"></a><p>[<abbr class="abbrev">XQuery</abbr>] <span
class="title"><i>
<a href="http://www.w3.org/TR/xquery/"; target="_top">XQuery</a>
- </i>. </span></p></div><div class="biblioentry"><a
id="id2532268"></a><p>[<abbr class="abbrev">Graphviz</abbr>] <span
class="title"><i>
+ </i>. </span></p></div><div class="biblioentry"><a
id="id2542952"></a><p>[<abbr class="abbrev">Graphviz</abbr>] <span
class="title"><i>
<a href="http://www.graphviz.org/"; target="_top">Graphviz</a>
</i>. </span></p></div></div></div></body></html>

nmwg: r361 - in trunk/nmwg/doc/dLS/gLS: . examples, svnlog, 06/15/2008

List archive

nmwg: r361 - in trunk/nmwg/doc/dLS/gLS: . examples