Skip to Content.
Sympa Menu

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

Subject: perfsonar development work

List archive

nmwg: r297 - trunk/nmwg/doc/dLS


Chronological Thread 
  • From:
  • To: ,
  • Subject: nmwg: r297 - trunk/nmwg/doc/dLS
  • Date: Mon, 26 Nov 2007 22:21:23 -0500

Author: zurawski
Date: 2007-11-26 22:21:22 -0500 (Mon, 26 Nov 2007)
New Revision: 297

Modified:
trunk/nmwg/doc/dLS/LSControl-JoinRequest.xml
trunk/nmwg/doc/dLS/LSControl-JoinResponse.xml
trunk/nmwg/doc/dLS/LSControl-LeaderRequest.xml
trunk/nmwg/doc/dLS/LSControl-Summary2Request.xml
trunk/nmwg/doc/dLS/LSControl-Summary2Response.xml
trunk/nmwg/doc/dLS/LSControl-SummaryRequest.xml
trunk/nmwg/doc/dLS/LSControl-SummaryResponse.xml
trunk/nmwg/doc/dLS/LSControl-TokenRequest.xml
trunk/nmwg/doc/dLS/LSControl-TokenResponse.xml
trunk/nmwg/doc/dLS/LSRing-lower.xml
trunk/nmwg/doc/dLS/LSRing-upper.xml
trunk/nmwg/doc/dLS/LSRing.xml
trunk/nmwg/doc/dLS/dLS.html
trunk/nmwg/doc/dLS/dLS.pdf
trunk/nmwg/doc/dLS/dLS.xml
Log:
Removed all references to contentSize, both in examples and in the
document (including previously commented sections in algorithms). The
new 'id' based method will now need to be explained much more.

Tried to correct language as best as I can related to global/local
upper/lower, used examples of interdomain/intradomain as suggested by
jeff.

-jason



Modified: trunk/nmwg/doc/dLS/LSControl-JoinRequest.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSControl-JoinRequest.xml 2007-11-14 09:31:41
UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSControl-JoinRequest.xml 2007-11-27 03:21:22
UTC (rev 297)
@@ -10,9 +10,6 @@
</psservice:service>
</perfsonar:subject>
<nmwg:eventType>http://perfsonar.net/services/LS/join</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">100</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

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

Modified: trunk/nmwg/doc/dLS/LSControl-JoinResponse.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSControl-JoinResponse.xml 2007-11-14 09:31:41
UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSControl-JoinResponse.xml 2007-11-27 03:21:22
UTC (rev 297)
@@ -10,9 +10,6 @@
</psservice:service>
</perfsonar:subject>

<nmwg:eventType>http://perfsonar.net/services/LS/join/success</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">50</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

<nmwg:data id="data.6" metadataIdRef="metadata.6">
@@ -25,9 +22,6 @@
<psservice:serviceDescription>...</psservice:serviceDescription>
</psservice:service>
</perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">0</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

<nmwg:metadata id="metadata.9">
@@ -39,9 +33,6 @@
<psservice:serviceDescription>...</psservice:serviceDescription>
</psservice:service>
</perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">200</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>
</nmwg:data>


Modified: trunk/nmwg/doc/dLS/LSControl-LeaderRequest.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSControl-LeaderRequest.xml 2007-11-14 09:31:41
UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSControl-LeaderRequest.xml 2007-11-27 03:21:22
UTC (rev 297)
@@ -10,9 +10,6 @@
</psservice:service>
</perfsonar:subject>
<nmwg:eventType>http://perfsonar.net/services/LS/leader</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">50</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

<nmwg:data id="data.6" metadataIdRef="metadata.6">
@@ -29,9 +26,6 @@
</psservice:service>
</perfsonar:subject>

<nmwg:eventType>http://perfsonar.net/services/LS/summary</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">100</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

<!-- then its summary -->

Modified: trunk/nmwg/doc/dLS/LSControl-Summary2Request.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSControl-Summary2Request.xml 2007-11-14 09:31:41
UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSControl-Summary2Request.xml 2007-11-27 03:21:22
UTC (rev 297)
@@ -10,9 +10,6 @@
</psservice:service>
</perfsonar:subject>

<nmwg:eventType>http://perfsonar.net/services/LS/summary/lower</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">100</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

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

Modified: trunk/nmwg/doc/dLS/LSControl-Summary2Response.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSControl-Summary2Response.xml 2007-11-14 09:31:41
UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSControl-Summary2Response.xml 2007-11-27 03:21:22
UTC (rev 297)
@@ -11,9 +11,6 @@
</psservice:service>
</perfsonar:subject>

<nmwg:eventType>http://perfsonar.net/services/LS/summary/lower/success</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">50</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

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

Modified: trunk/nmwg/doc/dLS/LSControl-SummaryRequest.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSControl-SummaryRequest.xml 2007-11-14 09:31:41
UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSControl-SummaryRequest.xml 2007-11-27 03:21:22
UTC (rev 297)
@@ -10,9 +10,6 @@
</psservice:service>
</perfsonar:subject>

<nmwg:eventType>http://perfsonar.net/services/LS/summary/upper</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">100</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

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

Modified: trunk/nmwg/doc/dLS/LSControl-SummaryResponse.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSControl-SummaryResponse.xml 2007-11-14 09:31:41
UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSControl-SummaryResponse.xml 2007-11-27 03:21:22
UTC (rev 297)
@@ -11,9 +11,6 @@
</psservice:service>
</perfsonar:subject>

<nmwg:eventType>http://perfsonar.net/services/LS/summary/upper/success</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">50</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

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

Modified: trunk/nmwg/doc/dLS/LSControl-TokenRequest.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSControl-TokenRequest.xml 2007-11-14 09:31:41
UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSControl-TokenRequest.xml 2007-11-27 03:21:22
UTC (rev 297)
@@ -10,9 +10,6 @@
</psservice:service>
</perfsonar:subject>

<nmwg:eventType>http://perfsonar.net/services/LS/token/lower</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter name="contentSize">50</nmwg:parameter>
- </nmwg:parameters>
</nmwg:metadata>

<nmwg:data id="data.6" metadataIdRef="metadata.6">
@@ -28,7 +25,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">100</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>


Modified: trunk/nmwg/doc/dLS/LSControl-TokenResponse.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSControl-TokenResponse.xml 2007-11-14 09:31:41
UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSControl-TokenResponse.xml 2007-11-27 03:21:22
UTC (rev 297)
@@ -12,7 +12,6 @@

<nmwg:eventType>http://perfsonar.net/services/LS/token/lower/success</nmwg:eventType>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">100</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>


Modified: trunk/nmwg/doc/dLS/LSRing-lower.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSRing-lower.xml 2007-11-14 09:31:41 UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSRing-lower.xml 2007-11-27 03:21:22 UTC (rev 297)
@@ -13,7 +13,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">0</nmwg:parameter>
- <nmwg:parameter name="contentSize">100</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -28,7 +27,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">50</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -43,7 +41,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">0</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -58,7 +55,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">200</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>


Modified: trunk/nmwg/doc/dLS/LSRing-upper.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSRing-upper.xml 2007-11-14 09:31:41 UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSRing-upper.xml 2007-11-27 03:21:22 UTC (rev 297)
@@ -13,7 +13,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">1000</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -28,7 +27,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">500</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>


Modified: trunk/nmwg/doc/dLS/LSRing.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSRing.xml 2007-11-14 09:31:41 UTC (rev 296)
+++ trunk/nmwg/doc/dLS/LSRing.xml 2007-11-27 03:21:22 UTC (rev 297)
@@ -13,7 +13,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">0</nmwg:parameter>
- <nmwg:parameter name="contentSize">100</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -28,7 +27,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">50</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -43,7 +41,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">0</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -58,7 +55,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">200</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -83,7 +79,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">1000</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -98,7 +93,6 @@
</perfsonar:subject>
<nmwg:parameters>
<nmwg:parameter name="active">1</nmwg:parameter>
- <nmwg:parameter name="contentSize">500</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>


Modified: trunk/nmwg/doc/dLS/dLS.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS.html 2007-11-14 09:31:41 UTC (rev 296)
+++ trunk/nmwg/doc/dLS/dLS.html 2007-11-27 03:21:22 UTC (rev 297)
@@ -1,6 +1,10 @@
<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01//EN">
-<html lang="en"><head><meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"><title>Distributed Lookup Service (dLS) in the perfSONAR
Framework</title><style type="text/css" title="Xml2Rfc (sans serif)">
+<html lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<title>Distributed Lookup Service (dLS) in the perfSONAR Framework</title>
+<style type="text/css" title="Xml2Rfc (sans serif)">
a {
text-decoration: none;
}
@@ -289,7 +293,91 @@
content: normal;
}
}
-</style><link rel="Author" href="#rfc.authors"><link rel="Copyright"
href="#rfc.copyright"><link rel="Chapter" title="1 Introduction"
href="#rfc.section.1"><link rel="Chapter" title="2 System Specific Operation"
href="#rfc.section.2"><link rel="Chapter" title="3 Bootstrapping"
href="#rfc.section.3"><link rel="Chapter" title="4 Structures and Messages"
href="#rfc.section.4"><link rel="Chapter" title="5 Result codes"
href="#rfc.section.5"><link rel="Chapter" title="6 Appendices"
href="#rfc.section.6"><link rel="Chapter" href="#rfc.section.7" title="7
References"><meta name="generator"
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291,
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica
http://www.saxonica.com/";><link rel="schema.DC"
href="http://purl.org/dc/elements/1.1/";><meta name="DC.Creator"
content="Boote, J"><meta name="DC.Creator" content="Glowiak, M"><meta
name="DC.Creator" content="Swany, M"><meta name="DC.Creator"
content="Zurawski, J"><met
a name="DC.Date.Issued" scheme="ISO8601"
content="2007-10"></head><body><table summary="header information"
class="header" border="0" cellpadding="1" cellspacing="1"><tr><td
class="front left">perfSONAR</td><td class="front right">J
Boote</td></tr><tr><td class="front left"></td><td class="front
right">Internet2</td></tr><tr><td class="front left">Intended status:
Informational</td><td class="front right">M Glowiak</td></tr><tr><td
class="front left"></td><td class="front right">PSNC</td></tr><tr><td
class="front left"></td><td class="front right">M Swany</td></tr><tr><td
class="front left"></td><td class="front right">UDel</td></tr><tr><td
class="front left"></td><td class="front right">J Zurawski</td></tr><tr><td
class="front left"></td><td class="front right">Internet2</td></tr><tr><td
class="front left"></td><td class="front right">October
2007</td></tr></table><p class="title">Distributed Lookup Service (dLS) in
the perfSONAR Framework</p><h1><a id="rfc.status" href="#r
fc.status">Status of this Memo</a></h1><p>This memo provides!
informa
tion for the perfSONAR community. It does not specify any standards or
technical recommendations. Distribution is unlimited.</p><h1><a
id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright
Notice</a></h1><p>Copyright � The perfSONAR Consortium (2007). All Rights
Reserved.</p><hr class="noprint"><h1 id="rfc.section.1" class="np"><a
href="#rfc.section.1">1.</a>&nbsp;<a id="intro"
href="#intro">Introduction</a></h1><p id="rfc.section.1.p.1">This document
describes the Distributed Lookup Service (dLS) in the perfSONAR (pS) system.
This functionality extends the basic Lookup Service (LS) functionality that
has been present in the system for some time. The basic LS supports the
storing and querying of perfSONAR Service information as well as metadata
about data stored or gathered by a particular pS service instance.</p><p
id="rfc.section.1.p.2">From the clients' perspective, Lookup Service
operation involves registration, deregistration, querying and obtaining query
result
s. Clients want to discover the services that are running in the network.
The LS enables this by gathering information from the services and then using
it to fulfill client queries. The following figure presents basic LS
interactions.</p><div id="ls-op"></div><div id="rfc.figure.1"></div><p>LS
Operation</p><pre>
+</style>
+<link rel="Author" href="#rfc.authors">
+<link rel="Copyright" href="#rfc.copyright">
+<link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
+<link rel="Chapter" title="2 System Specific Operation"
href="#rfc.section.2">
+<link rel="Chapter" title="3 Bootstrapping" href="#rfc.section.3">
+<link rel="Chapter" title="4 Structures and Messages" href="#rfc.section.4">
+<link rel="Chapter" title="5 Result codes" href="#rfc.section.5">
+<link rel="Chapter" title="6 Appendices" href="#rfc.section.6">
+<link rel="Chapter" href="#rfc.section.7" title="7 References">
+<meta name="generator"
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291,
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica
http://www.saxonica.com/";>
+<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/";>
+<meta name="DC.Creator" content="Boote, J">
+<meta name="DC.Creator" content="Glowiak, M">
+<meta name="DC.Creator" content="Swany, M">
+<meta name="DC.Creator" content="Zurawski, J">
+<meta name="DC.Date.Issued" scheme="ISO8601" content="2007-10">
+</head>
+<body>
+<table summary="header information" class="header" border="0"
cellpadding="1" cellspacing="1">
+<tr>
+<td class="front left">perfSONAR</td>
+<td class="front right">J Boote</td>
+</tr>
+<tr>
+<td class="front left">
+</td>
+<td class="front right">Internet2</td>
+</tr>
+<tr>
+<td class="front left">Intended status: Informational</td>
+<td class="front right">M Glowiak</td>
+</tr>
+<tr>
+<td class="front left">
+</td>
+<td class="front right">PSNC</td>
+</tr>
+<tr>
+<td class="front left">
+</td>
+<td class="front right">M Swany</td>
+</tr>
+<tr>
+<td class="front left">
+</td>
+<td class="front right">UDel</td>
+</tr>
+<tr>
+<td class="front left">
+</td>
+<td class="front right">J Zurawski</td>
+</tr>
+<tr>
+<td class="front left">
+</td>
+<td class="front right">Internet2</td>
+</tr>
+<tr>
+<td class="front left">
+</td>
+<td class="front right">October 2007</td>
+</tr>
+</table>
+<p class="title">Distributed Lookup Service (dLS) in the perfSONAR
Framework</p>
+<h1>
+<a id="rfc.status" href="#rfc.status">Status of this Memo</a>
+</h1>
+<p>This memo provides information for the perfSONAR community. It does not
specify any standards or technical recommendations. Distribution is
unlimited.</p>
+<h1>
+<a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a>
+</h1>
+<p>Copyright � The perfSONAR Consortium (2007). All Rights Reserved.</p>
+<hr class="noprint">
+<h1 id="rfc.section.1" class="np">
+<a href="#rfc.section.1">1.</a>&nbsp;<a id="intro"
href="#intro">Introduction</a>
+</h1>
+<p id="rfc.section.1.p.1">This document describes the Distributed Lookup
Service (dLS) in the perfSONAR (pS) system. This functionality extends the
basic Lookup Service (LS) functionality that has been present in the system
for some time. The basic LS supports the storing and querying of perfSONAR
Service information as well as metadata about data stored or gathered by a
particular pS service instance.</p>
+<p id="rfc.section.1.p.2">From the clients' perspective, Lookup Service
operation involves registration, deregistration, querying and obtaining query
results. Clients want to discover the services that are running in the
network. The LS enables this by gathering information from the services and
then using it to fulfill client queries. The following figure presents basic
LS interactions.</p>
+<div id="ls-op">
+</div>
+<div id="rfc.figure.1">
+</div>
+<p>LS Operation</p>
+<pre>
_____ __________
| | Register/De-register | |
| LS | &lt;------------------------&gt; | Service |
@@ -299,7 +387,57 @@
----------------&gt; | Client/Service |
Query for Services |_________________|

- </pre><p>Services interacting with an LS</p><p
class="figure">Figure 1</p><p id="rfc.section.1.p.4">This document describes
the support necessary to extend the basic Lookup Service to a distributed
mode of operation. Distributing LS functionality is necessary to scale the
system up in terms of the amount of information that can be stored and
searched. There are a few key facets of this mode of
operation:</p><ul><li>Summarization - to reduce the amount of information
sent over the network or to anonymize sensitive data, some form of data
reduction must take place.</li><li>Scope - to enable a hierarchy of systems,
some form of scoping must exist that defines local and remote communication
groups.</li><li>Search - information location is key and the way in which
distributed location and search is handled is the crux of this
service.</li></ul><p id="rfc.section.1.p.6">Additionally we present solutions
to issues necessary to allow effective operation of this service in
cluding bootstrapping (i.e. how service finds other parts of the system) and
domain-specific concerns.</p><hr class="noprint"><h1 id="rfc.section.2"
class="np"><a href="#rfc.section.2">2.</a>&nbsp;<a id="system"
href="#system">System Specific Operation</a></h1><h2 id="rfc.section.2.1"><a
href="#rfc.section.2.1">2.1</a>&nbsp;<a id="overview"
href="#overview">Overview</a></h2><p id="rfc.section.2.1.p.1">The first step
of information flow is when a pS service registers with an LS. The service
may know the name of an LS via static configuration (the most common case for
legacy deployments), or other forms of bootstrapping such as multicast may
occur. A service registers a "service metadata" record about itself and full
metadata (i.e. containing all information such as subject, eventType(s), and
any parameters, see <a href="#service-metadata" title="Service metadata
example">Section&nbsp;4.1</a>) about stored data it has knowledge of. Such a
record is called Lookup Information (s
ee <a href="#lookup-info" title="Lookup Information">Section!
&nbsp;4.
2</a>).</p><p id="rfc.section.2.1.p.2">The idea is to move the metadata from
a service-local XML data store to a specialized LS with additional searching
capabilities. While a service instance may support limited searching, this is
not necessary as they should be focused on storing or gathering data and
leave the lookup functionality to the LS. Possible exceptions when a client
may need to contact a service directly are when metadata rapidly changes,
like the most recent data's timestamp and full details of data stored in
long-term archival MAs.</p><p id="rfc.section.2.1.p.3">The architecture of
the dLS protocol assumes the existence of logical rings of LS instances. The
architecture should allow for multiple levels. The current proposal involves
two levels of rings: lower scope and upper scope. Lower scope hides
inter-domain relationships between LS instances while upper scope hides
intra-domain relationships. </p><h2 id="rfc.section.2.2"><a
href="#rfc.section.2.2">2.2</a>&n
bsp;<a id="summary" href="#summary">Summarization</a></h2><p
id="rfc.section.2.2.p.1">The LS that a service contacts to register becomes
the "Home LS" (HLS, see <a href="#glossary"
title="Glossary">Section&nbsp;6.1</a>) of that particular service. It is the
responsibility of the HLS to make summary data about the all of the pS
services it knows of available to the larger enterprise and to draw relevant
queries to itself.</p><p id="rfc.section.2.2.p.2">Summarization is important
to the overall success of this service as summaries prevents other LS
instances from being overloaded by information. They must be general enough
to allow for easy creation and exchange but also must retain enough
information to provide a rich query interface able to locate the distributed
information. That means service metadata information must be reduced
(summarized) as it propagates through the LS cloud. We start by making an
observation that summarization is best based on scope (see also <a href=
"#scope" title="Scope Forming">Section&nbsp;2.3</a> for form!
ing scop
e). Simply put, this means that we should attempt to summarize "more" the
"farther" away from the source that we get. This creates a smaller data set
that travels the farthest away while keeping the larger and more informative
data sets closer to the source. We present the strategies as such:
</p><ul><li>Summarization for the "lower scope" (formerly known as "local
scope")</li><li>Summarization for the "upper scope" (formerly known as
"global scope")</li></ul><p> We limit much of the discussion in this document
to two scopes, although an arbitrary number of scopes is possible without
extension to the model. As the number of scopes increases additional
"aggregation" will be necessary to combine information thus reducing the size
of the data sets further. </p><h3 id="rfc.section.2.2.1"><a
href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a id="lower_scope_summarization"
href="#lower_scope_summarization">Lower Scope Summarization</a></h3><p
id="rfc.section.2.2.1.p.1">This first level of
summarization, between HLS instances internal to a domain, consists of
simply eliding detailed information from the metadata descriptions provided
by registered services. For now we define this to be simply removing
additional "parameter" elements from the metadata. Special consideration must
be given to the "supportedEventType" parameter by simply converting this to
actual eventType elements. This will ensure interoperability with legacy
services.</p><p id="rfc.section.2.2.1.p.2">Future iterations may choose to
drop additional pieces of information deemed unnecessary or private such as
parts of topological descriptions. This sort of modification is encouraged as
long as the data remains "symmetrical" and conforms to the schematic
definitions for a given metadata description. It should be noted that such
modifications will affect the searching procedure and could isolate the
source services.</p><p id="rfc.section.2.2.1.p.3">The mechanics for
performing this level of summari
zation can use any number of technologies. Either Extensible!
Stylesh
eet Language Transformation (XSLT) documents or the XQuery language (see <a
href="#glossary" title="Glossary">Section&nbsp;6.1</a>) may be used to
prepare the initial data for exchange in this first level. Since the exchange
of this local information will occur frequently, a simple operation that is
scheduled or on demand should be employed by the individual implementations
to ensure the regular LS functions are not impeded.</p><p
id="rfc.section.2.2.1.p.4">In order to make information available to the LS
cloud, the HLS will advertise this summary information to other LS instances
to propagate the appropriate information. Information exchange will be
handled using a "taking turns" protocol such as token ring. The holder of the
token will then perform the information exchange to other known instances
(see <a href="#glossary" title="Glossary">Section&nbsp;6.1</a>).</p><div
id="hls-cloud"></div><div id="rfc.figure.2"></div><p>Token passing between
HLS cloud</p><pre>
+ </pre>
+<p>Services interacting with an LS</p>
+<p class="figure">Figure 1</p>
+<p id="rfc.section.1.p.4">This document describes the support necessary to
extend the basic Lookup Service to a distributed mode of operation.
Distributing LS functionality is necessary to scale the system up in terms of
the amount of information that can be stored and searched. There are a few
key facets of this mode of operation:</p>
+<p id="rfc.section.1.p.5">
+</p>
+<ul>
+<li>Summarization - to reduce the amount of information sent over the
network or to anonymize sensitive data, some form of data reduction must take
place.</li>
+<li>Scope - to enable a hierarchy of systems, some form of scoping must
exist that defines local and remote communication groups.</li>
+<li>Search - information location is key and the way in which distributed
location and search is handled is the crux of this service.</li>
+</ul>
+<p id="rfc.section.1.p.6">Additionally we present solutions to issues
necessary to allow effective operation of this service including
bootstrapping (i.e. how service finds other parts of the system) and
domain-specific concerns.</p>
+<hr class="noprint">
+<h1 id="rfc.section.2" class="np">
+<a href="#rfc.section.2">2.</a>&nbsp;<a id="system" href="#system">System
Specific Operation</a>
+</h1>
+<h2 id="rfc.section.2.1">
+<a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="overview"
href="#overview">Overview</a>
+</h2>
+<p id="rfc.section.2.1.p.1">The first step of information flow is when a pS
service registers with an LS. The service may know the name of an LS via
static configuration (the most common case for legacy deployments), or other
forms of bootstrapping such as multicast may occur. A service registers a
"service metadata" record about itself and full metadata (i.e. containing all
information such as subject, eventType(s), and any parameters, see <a
href="#service-metadata" title="Service metadata
example">Section&nbsp;4.1</a>) about stored data it has knowledge of. Such a
record is called Lookup Information (see <a href="#lookup-info" title="Lookup
Information">Section&nbsp;4.2</a>).</p>
+<p id="rfc.section.2.1.p.2">The idea is to move the metadata from a
service-local XML data store to a specialized LS with additional searching
capabilities. While a service instance may support limited searching, this is
not necessary as they should be focused on storing or gathering data and
leave the lookup functionality to the LS. Possible exceptions when a client
may need to contact a service directly are when metadata rapidly changes,
like the most recent data's timestamp and full details of data stored in
long-term archival MAs.</p>
+<p id="rfc.section.2.1.p.3">The architecture of the dLS protocol assumes the
existence of logical rings of LS instances. The architecture should allow for
multiple levels of these rings representing multiple splits in a hierarchy,
although the basic example that will be an ongoing theme in this document
will revolve around only 2 levels. The authors realize it is impossible to
predict how the hierarchy of this service may split over time, therefore we
avoid using language that directly categorizes a ring into a specific role.
In general the two rings that define scope are 'lower' and 'upper'.</p>
+<p id="rfc.section.2.1.p.4">To better define this classification consider an
example at a high level: inter-domain communication. It is natural to assume
that single domain will deploy an LS instance to manage deployed services.
The true goal of perfSONAR is to ease the detection of end to end performance
issues particularly across domain boundaries, therefore communication between
domain LS instances is paramount. We assume for this example that the 'top'
most level is that of the domain; further fragmentation by other factors such
as the 'top-level domain' or geographical considerations are probable, just
not of interest in this work. A single domain may have multiple LS
deployments; a representative 'leader' from this set will represent the
'upper' (intra-domain) scope and communicate with similar LS instances of
other domains in this case. The actual registered services of the LS
represent the 'lower' (local, or in many cases inter-domain) scope.</p>
+<p id="rfc.section.2.1.p.5">The scoping designations are important to the
next stage: data reduction. We observe that the abundance of information
available via the original metadata description is rather obtuse when it
comes to answering a simple (and common) query such as 'give me bandwidth
data for host x'. Although information such as capacity or interface name is
valuable internal to a domain, it does not serve much purpose to NOC staff
simply asking to see utilization of a link. We propose a 'summarization'
strategy based on 'distance' from the source that will distill the complete
metadata into smaller and smaller sets as the information is passed through
the scope hierarchy.</p>
+<p id="rfc.section.2.1.p.6">Finally, using the scoping and summarizing steps
we come to final, and arguably most important phase: search. Search must rely
on two phases to work efficiently in the dLS framework, namely discovery and
query. The first step is locating 'where' information can be found. This
involves asking semi direct questions regarding the well defined network
topology in order to locate the 'vicinity' of data. The query phase will then
ask more esoteric questions once it locates the proper LS instances to ask.
The discovery phase is made possible through the process of summarization,
while the query phase remains similar to the current LS functionality.</p>
+<h2 id="rfc.section.2.2">
+<a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="summary"
href="#summary">Summarization</a>
+</h2>
+<p id="rfc.section.2.2.p.1">The LS that a service contacts to register
becomes the "Home LS" (HLS, see <a href="#glossary"
title="Glossary">Section&nbsp;6.1</a>) of that particular service. It is the
responsibility of the HLS to make summary data about the all of the pS
services it knows of available to the larger enterprise and to draw relevant
queries to itself.</p>
+<p id="rfc.section.2.2.p.2">Summarization is important to the overall
success of this service as summaries prevents other LS instances from being
overloaded by information. They must be general enough to allow for easy
creation and exchange but also must retain enough information to provide a
rich query interface able to locate the distributed information. That means
service metadata information must be reduced (summarized) as it propagates
through the LS cloud.</p>
+<p id="rfc.section.2.2.p.3">We start by making an observation that
summarization is best based on scope (see also <a href="#scope" title="Scope
Forming">Section&nbsp;2.3</a> for forming scope). Simply put, this means that
we should attempt to summarize "more" the "farther" away from the source that
we get. This creates a smaller data set that travels the farthest away while
keeping the larger and more informative data sets closer to the source. We
present the strategies as such:</p>
+<p id="rfc.section.2.2.p.4">
+</p>
+<ul>
+<li>Summarization for the "lower scope" - we must examine services that we
are directly responsible for and distill this information into a compact and
manageable form.</li>
+<li>Summarization for the "upper scope" of an LS - Aggregation of summaries
from peers plus additional summary steps will yield a concise (yet still
compact) data set. Potentially we will need to consider summaries from lower
scopes and aggregate these into the information set.</li>
+</ul>
+<p id="rfc.section.2.2.p.5">We will limit our discussions to the previously
discussed inter-domain example, thus involving only two scope rings. Building
upon the basic ideas presented here, extension to multiple scopes will be be
presented in future work.</p>
+<h3 id="rfc.section.2.2.1">
+<a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a
id="lower_scope_summarization" href="#lower_scope_summarization">Lower Scope
Summarization</a>
+</h3>
+<p id="rfc.section.2.2.1.p.1">The lower scope summarization, described here
as information exchange between HLS instances internal to a domain, consists
of simply extracting detailed information from the metadata descriptions
provided by registered services. For now we define this to be simply removing
additional "parameter" elements from the metadata. Special consideration must
be given to the "supportedEventType" parameter by simply converting this to
actual eventType elements. This will ensure interoperability with legacy
services.</p>
+<p id="rfc.section.2.2.1.p.2">Future iterations may choose to drop
additional pieces of information deemed unnecessary or private such as parts
of topological descriptions. This sort of modification is encouraged as long
as the data remains "symmetrical" and conforms to the schematic definitions
for a given metadata description. It should be noted that such modifications
will affect the searching procedure and could isolate the source services.</p>
+<p id="rfc.section.2.2.1.p.3">The mechanics for performing this level of
summarization can use any number of technologies. Either Extensible
Stylesheet Language Transformation (XSLT) documents or the XQuery language
(see <a href="#glossary" title="Glossary">Section&nbsp;6.1</a>) may be used
to prepare the initial data for exchange in this first level. Since the
exchange of this local information will occur frequently, a simple operation
that is scheduled or on demand should be employed by the individual
implementations to ensure the regular LS functions are not impeded.</p>
+<p id="rfc.section.2.2.1.p.4">In order to make information available to the
LS cloud, the HLS will advertise this summary information to other LS
instances to propagate the appropriate information. Information exchange will
be handled using a "taking turns" protocol such as token ring. The holder of
the token will then perform the information exchange to other known instances
(see <a href="#glossary" title="Glossary">Section&nbsp;6.1</a>).</p>
+<div id="hls-cloud">
+</div>
+<div id="rfc.figure.2">
+</div>
+<p>Token passing between HLS cloud</p>
+<pre>
_____ _____
| | | |
| LS1 | &lt;----------------- | LS2 |
@@ -310,7 +448,15 @@
| | | |
|-------&gt; | LS3 | ---------|
|_____|
- </pre><p>HLS instances communicating via a token message</p><p
class="figure">Figure 2</p><div id="hls-cloud1"></div><div
id="rfc.figure.3"></div><p>Broadcast summary</p><pre>
+ </pre>
+<p>HLS instances communicating via a token message</p>
+<p class="figure">Figure 2</p>
+<div id="hls-cloud1">
+</div>
+<div id="rfc.figure.3">
+</div>
+<p>Broadcast summary</p>
+<pre>
_____ _____
| | | |
| LS1 | &lt; &gt; | LS2 |
@@ -323,7 +469,62 @@
|____/T\ Token
\_/

- </pre><p>The holder of the token (LS3) will inform everyone of
its summary information.</p><p class="figure">Figure 3</p><p
id="rfc.section.2.2.1.p.7">Once exchanged, the details regarding storage in
the XML database backend (see <a href="#glossary"
title="Glossary">Section&nbsp;6.1</a>) are also left to individual
implementations. It is understood that this information, in the possession of
non HLS instances, is provided as a convenience and should be treated in the
same way that directly registered information is (i.e. purged on expiration).
When responding to queries for this information, the LS must indicate whether
or not it is authoritative.</p><h3 id="rfc.section.2.2.2"><a
href="#rfc.section.2.2.2">2.2.2</a>&nbsp;<a id="upper_scope_summarization"
href="#upper_scope_summarization">Upper Scope Summarization</a></h3><p
id="rfc.section.2.2.2.p.1">A designated member of each lower scope will be
required to interact with the upper scope. The mechanics of how we
learn who is the designated leader are discussed in <a href="#tokens"
title="Token Passing">Section&nbsp;2.3.2</a>. The leader of each lower scope
(and the designated backup) will be responsible for examining each member's
summary information and building a summarization/aggregation that describes
the contents of a given scope. This summary will serve as input to the
higher-level scope.</p><p id="rfc.section.2.2.2.p.2">The most natural
summarization is based on the topology of the network (like in network
routing). Thus, topology-based summarization will reduce available service
instances in the same way that IP addresses are summarized into network
numbers. They will indicate the eventTypes that a service has and ones that
can it can generate. Summarization will be performed using specialized
summary algorithm. Topology information such as IP addresses will be
summarized using algorithms based on Radix Tree (see <a href="#IP-summary"
title="IP addresses summarization algor
ithm">Section&nbsp;2.2.2.1</a>).</p><p id="rfc.section.2.2.2!
.p.3">Ot
her information can be summarized in a less programmatic fashion through the
use of either Extensible Stylesheet Language Transformation (XSLT) documents
or the XQuery language as discussed in the previous section. These mechanisms
will take into account the XML elements that represent the network topology
currently used in metadata subjects as well as additional items such as
eventTypes.</p><p id="rfc.section.2.2.2.p.4">The output of this process
becomes a "service summary" that represents a breadth of the original input.
See <a href="#LSControl-Summary-lower" title="LS Summary Message
(Lower)">Section&nbsp;4.6</a> or <a href="#LSControl-Summary-upper" title="LS
Summary Message (Upper)">Section&nbsp;4.7</a> for a mock-up of the summary
output. Additional transformations, while aggressive, will strive to preserve
as much information as possible to remain useful during the search
procedures.</p><h4 id="rfc.section.2.2.2.1"><a
href="#rfc.section.2.2.2.1">2.2.2.1</a>&nbsp;<a id=
"IP-summary" href="#IP-summary">IP addresses summarization
algorithm</a></h4><p id="rfc.section.2.2.2.1.p.1">To properly summarize a
list of strings such as IP addresses we must rely on the help of special
algorithms and data structures. The <a
href="http://en.wikipedia.org/wiki/Radix_tree";>Radix Tree</a> algorithm is
useful in creating "associative arrays" where the keys are expressed as
strings. Radix Tree implementations have been used in practice to index
things such as text documents as well as more menial tasks such as
dictionaries. We are most interested in indexing IP addresses with their
natural hierarchy, where it is necessary to describe a large ranges of values
and have few exceptions.</p><p id="rfc.section.2.2.2.1.p.2">A detailed
explanation of the nuances of the Radix Tree is well beyond the scope of this
document, but a brief overview is presented for completeness. The structure
itself is best described as a binary tree where nodes contain whole values
and the
edges are the primary source of navigation. The edges of th!
e tree c
an be based on a single character or perhaps on even longer strings (one of
the features that leads to efficiency for small data sets). The algorithm
should support the following basic operations: </p><ul><li>Lookup: Indicate
that something is or is not contained in the tree.</li><li>Insert: Like in
most inserts we attempt to place something into the structure. We first start
by doing a Lookup to see if it exists already; the point where we stop is
where we will insert the object. We are careful to utilize the longest
matching prefix of any other nearby edge to our advantage. This last part is
normally referred to as "splitting" and ensures that each node has no more
than two children.</li><li>Delete: Delete an object from the tree. This
operation will be complicated by "collapsing" parents that have a single
child and merging the edges.</li></ul><p id="rfc.section.2.2.2.1.p.3">Once
constructed, it is possible to consult the structure in creating IP network
summaries.</p><h2
id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="scope"
href="#scope">Scope Forming</a></h2><p id="rfc.section.2.3.p.1">The next
question is how to form the lower and upper scopes. The simplest answer is
that the lower scope be formed based on the domain name of the participating
systems. That would allow e.g. internet2.edu, geant2.net, and pionier.gov.pl
to potentially operate more than one LS instance inside their own domains
(for performance and scalability.) As LS instances come online they will
invoke bootstrapping procedures to find and join a lower scoped group
first.</p><p id="rfc.section.2.3.p.2">The scopes should be named based on
URIs. This will allow a domain-level scope to take the form <a
href="http://internet2.edu";>http://internet2.edu</a>, with subdomain scopes
named <a href="http://internet2.edu/foo";>http://internet2.edu/foo</a>, etc.
The top-level scope can be called <a
href="http://perfsonar.net";>http://perfsonar.net</a> with potential f
or geographic divisions later if necessary for performance (!
such as
<a href="http://eu.perfsonar.net";>http://eu.perfsonar.net</a>).</p><p
id="rfc.section.2.3.p.3">The major algorithms used to form and maintain the
ring structure of the dLS, no matter which scope we are talking about, are as
follows: </p><ul><li>Join Procedure</li><li>Token
Passing</li><li>Summarization Notification</li></ul><p> Each of these
procedures is important to keeping members of the distributed "service"
functioning correctly. The algorithms will be presented in the frame of the
lower scope, but will be used in the same manner for the upper scope as
well.</p><h3 id="rfc.section.2.3.1"><a
href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="join" href="#join">Join
Procedure</a></h3><p id="rfc.section.2.3.1.p.1">When an LS instance comes
online it will have some bootstrapping knowledge of potential peers (both
inter and intra domain). This information is contained in LSRing file (see <a
href="#LSRing" title="LS Ring File Structure">Section&nbsp;4.3</a>). The
inter-domain kno
wledge is used first to establish a connection to an already in progress
ring, or perhaps to start a ring that may not exist yet.</p><p
id="rfc.section.2.3.1.p.2">A candidate LS will continuously search its LSRing
information and send an LSControl mesage to its known LS instances with a
"join" eventType (see <a href="#LSControl-Join" title="LS Joining Message for
Joining a Ring">Section&nbsp;4.4</a>) until a successful response is seen.
The LS candidate will then search through the successful LSControlResponse to
this message and update its LSRing with the returned information. This can
mean updating the "contentSize" and "active" parameters as well as adding new
LS instances. These parameters are indicative of the size of each LS (i.e.
how many services are registering with it) and "live-ness" (i.e. were we
successful in contacting it recently). The contacted LS will also update the
local copy of LSRing to add the new member to its "available" list.</p><p
id="rfc.section.2.
3.1.p.3">After updating, the newly joined LS will broadcast !
another
LSControl message with a "summary" eventType (see <a
href="#LSControl-Summary-lower" title="LS Summary Message
(Lower)">Section&nbsp;4.6</a>, or if we are dealing with the upper level see
<a href="#LSControl-Summary-upper" title="LS Summary Message
(Upper)">Section&nbsp;4.7</a>) to all of the "active" LS instances from its
LSRing. Again the responses will be parsed to get any useful updated
information. At the end of this process the joining LS will possess an LSRing
file reflecting the state of the dLS cloud. Each of the recipient LS
instances which hasn't heard anything from this joining LS previously will do
the same, including adding this new member to their own lists (as they didn't
know of it's existence yet).</p><p id="rfc.section.2.3.1.p.4">After this
initial warm-up the LS will observe the rules of token etiquette and remain
silent until it is contacted with a token, or it has not seen one in a very
long time (see <a href="#tokens" title="Token Passing">Section&nbsp;
2.3.2</a>).</p><h4 id="rfc.section.2.3.1.1"><a
href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="join_algorithm"
href="#join_algorithm">Join Algorithm</a></h4><p
id="rfc.section.2.3.1.1.p.1"> </p><div id="join-example2"></div><div
id="rfc.figure.4"></div><p>Illustration of LS Join Algorithm</p><pre>
+ </pre>
+<p>The holder of the token (LS3) will inform everyone of its summary
information.</p>
+<p class="figure">Figure 3</p>
+<p id="rfc.section.2.2.1.p.7">Once exchanged, the details regarding storage
in the XML database backend (see <a href="#glossary"
title="Glossary">Section&nbsp;6.1</a>) are also left to individual
implementations. It is understood that this information, in the possession of
non HLS instances, is provided as a convenience and should be treated in the
same way that directly registered information is (i.e. purged on expiration).
When responding to queries for this information, the LS must indicate whether
or not it is authoritative.</p>
+<h3 id="rfc.section.2.2.2">
+<a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;<a
id="upper_scope_summarization" href="#upper_scope_summarization">Upper Scope
Summarization</a>
+</h3>
+<p id="rfc.section.2.2.2.p.1">A designated member of the aforementioned HLS
organization will be required to interact with other similar LSs (possibly
representing other domains) in order to form an upper scope. The mechanics of
how we learn who is the designated leader are discussed in <a href="#tokens"
title="Token Passing">Section&nbsp;2.3.2</a>. The leader from each of the
first layers of this hierarchy (and the designated backup) will be
responsible for examining each member's summary information and building a
summarization/aggregation that describes the contents of the various LS
instances. This summary will serve as input to the upper scope.</p>
+<p id="rfc.section.2.2.2.p.2">The most natural summarization is based on the
topology of the network (like in network routing). Thus, topology-based
summarization will reduce available service instances in the same way that IP
addresses are summarized into network numbers. They will indicate the
eventTypes that a service has and ones that can it can generate.
Summarization will be performed using specialized summary algorithm. Topology
information such as IP addresses will be summarized using algorithms based on
Radix Tree (see <a href="#IP-summary" title="IP addresses summarization
algorithm">Section&nbsp;2.2.2.1</a>).</p>
+<p id="rfc.section.2.2.2.p.3">Other information can be summarized in a less
programmatic fashion through the use of either Extensible Stylesheet Language
Transformation (XSLT) documents or the XQuery language as discussed in the
previous section. These mechanisms will take into account the XML elements
that represent the network topology currently used in metadata subjects as
well as additional items such as eventTypes.</p>
+<p id="rfc.section.2.2.2.p.4">The output of this process becomes a "service
summary" that represents a breadth of the original input. See <a
href="#LSControl-Summary-lower" title="LS Summary Message
(Lower)">Section&nbsp;4.6</a> or <a href="#LSControl-Summary-upper" title="LS
Summary Message (Upper)">Section&nbsp;4.7</a> for a mock-up of the summary
output. Additional transformations, while aggressive, will strive to preserve
as much information as possible to remain useful during the search
procedures.</p>
+<h4 id="rfc.section.2.2.2.1">
+<a href="#rfc.section.2.2.2.1">2.2.2.1</a>&nbsp;<a id="IP-summary"
href="#IP-summary">IP addresses summarization algorithm</a>
+</h4>
+<p id="rfc.section.2.2.2.1.p.1">To properly summarize a list of strings such
as IP addresses we must rely on the help of special algorithms and data
structures. The <a href="http://en.wikipedia.org/wiki/Radix_tree";>Radix
Tree</a> algorithm is useful in creating "associative arrays" where the keys
are expressed as strings. Radix Tree implementations have been used in
practice to index things such as text documents as well as more menial tasks
such as dictionaries. We are most interested in indexing IP addresses with
their natural hierarchy, where it is necessary to describe a large ranges of
values and have few exceptions.</p>
+<p id="rfc.section.2.2.2.1.p.2">A detailed explanation of the nuances of the
Radix Tree is well beyond the scope of this document, but a brief overview is
presented for completeness. The structure itself is best described as a
binary tree where nodes contain whole values and the edges are the primary
source of navigation. The edges of the tree can be based on a single
character or perhaps on even longer strings (one of the features that leads
to efficiency for small data sets). The algorithm should support the
following basic operations:</p>
+<p id="rfc.section.2.2.2.1.p.3">
+</p>
+<ul>
+<li>Lookup: Indicate that something is or is not contained in the tree.</li>
+<li>Insert: Like in most inserts we attempt to place something into the
structure. We first start by doing a Lookup to see if it exists already; the
point where we stop is where we will insert the object. We are careful to
utilize the longest matching prefix of any other nearby edge to our
advantage. This last part is normally referred to as "splitting" and ensures
that each node has no more than two children.</li>
+<li>Delete: Delete an object from the tree. This operation will be
complicated by "collapsing" parents that have a single child and merging the
edges.</li>
+</ul>
+<p id="rfc.section.2.2.2.1.p.4">Once constructed, it is possible to consult
the structure in creating IP network summaries.</p>
+<h2 id="rfc.section.2.3">
+<a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="scope" href="#scope">Scope
Forming</a>
+</h2>
+<p id="rfc.section.2.3.p.1">The next question is how to form the hierarchy
of LS instances and subsequently organize the 'scopes'. The simplest answer
is that the highest scope be formed based on the domain name of the
participating systems as mentioned in the previous examples. That would allow
e.g. internet2.edu, geant2.net, and pionier.gov.pl to potentially operate
more than one LS instance inside their own domains (for performance and
scalability.) As LS instances come online they will invoke bootstrapping
procedures to find and join a lower scoped group first.</p>
+<p id="rfc.section.2.3.p.2">The scopes should be named based on URIs. This
will allow a domain-level scope to take the form <a
href="http://internet2.edu";>http://internet2.edu</a>, with subdomain scopes
named <a href="http://internet2.edu/foo";>http://internet2.edu/foo</a>, etc.
The top-level scope can be called <a
href="http://perfsonar.net";>http://perfsonar.net</a> with potential for
geographic divisions later if necessary for performance (such as <a
href="http://eu.perfsonar.net";>http://eu.perfsonar.net</a>).</p>
+<p id="rfc.section.2.3.p.3">The major algorithms used to form and maintain
the ring structure of the dLS, no matter which scope we are talking about,
are as follows:</p>
+<p id="rfc.section.2.3.p.4">
+</p>
+<ul>
+<li>Join Procedure</li>
+<li>Token Passing</li>
+<li>Summarization Notification</li>
+</ul>
+<p id="rfc.section.2.3.p.5">Each of these procedures is important to keeping
members of the distributed "service" functioning correctly. The algorithms
will be presented in the frame of HLS instances communicating in a lower
scope, but will be used in the same manner for inter-domain communication as
an upper scope as well.</p>
+<h3 id="rfc.section.2.3.1">
+<a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="join" href="#join">Join
Procedure</a>
+</h3>
+<p id="rfc.section.2.3.1.p.1">When an LS instance comes online it will have
some bootstrapping knowledge of potential peers (both inter and intra
domain). This information is contained in LSRing file (see <a href="#LSRing"
title="LS Ring File Structure">Section&nbsp;4.3</a>). The inter-domain
knowledge is used first to establish a connection to an already in progress
ring, or perhaps to start a ring that may not exist yet.</p>
+<p id="rfc.section.2.3.1.p.2">A candidate LS will continuously search its
LSRing information and send an LSControl message to its known LS instances
with a "join" eventType (see <a href="#LSControl-Join" title="LS Joining
Message for Joining a Ring">Section&nbsp;4.4</a>) until a successful response
is seen. The LS candidate will then search through the successful
LSControlResponse to this message and update its LSRing with the returned
information. This can mean updating the "active" parameter as well as adding
new LS instances. This parameter is indicative of the "live-ness" (i.e. were
we successful in contacting it recently). The contacted LS will also update
the local copy of LSRing to add the new member to its "available" list.</p>
+<p id="rfc.section.2.3.1.p.3">After updating, the newly joined LS will
broadcast another LSControl message with a "summary" eventType (see <a
href="#LSControl-Summary-lower" title="LS Summary Message
(Lower)">Section&nbsp;4.6</a>, or if we are dealing with the upper level see
<a href="#LSControl-Summary-upper" title="LS Summary Message
(Upper)">Section&nbsp;4.7</a>) to all of the "active" LS instances from its
LSRing. Again the responses will be parsed to get any useful updated
information. At the end of this process the joining LS will possess an LSRing
file reflecting the state of the dLS cloud. Each of the recipient LS
instances which hasn't heard anything from this joining LS previously will do
the same, including adding this new member to their own lists (as they didn't
know of it's existence yet).</p>
+<p id="rfc.section.2.3.1.p.4">After this initial warm-up the LS will observe
the rules of token etiquette and remain silent until it is contacted with a
token, or it has not seen one in a very long time (see <a href="#tokens"
title="Token Passing">Section&nbsp;2.3.2</a>).</p>
+<h4 id="rfc.section.2.3.1.1">
+<a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="join_algorithm"
href="#join_algorithm">Join Algorithm</a>
+</h4>
+<p id="rfc.section.2.3.1.1.p.1">
+</p>
+<div id="join-example2">
+</div>
+<div id="rfc.figure.4">
+</div>
+<p>Illustration of LS Join Algorithm</p>
+<pre>
(5,6)
______________________________________________________
| |
@@ -341,7 +542,41 @@
(5,6)


- </pre><p>LS2, LS3 and LS4 are in the ring. LS1 wants to join
the dLS cloud.</p><p class="figure">Figure 4</p><p
id="rfc.section.2.3.1.1.p.2">The algorithm for joining the ring works as
follows:</p><p id="rfc.section.2.3.1.1.p.3"> </p><dl class="empty"><dd>1. LS1
- Candidate sends LSControlRequest message with the
http://perfsonar.net/services/LS/join eventType to selected LS2 which is
already a member of the ring. LS2 was found in LSRing initial file during
bootstrapping process.</dd><dd>2. LS2 receives join message from L1 and
decides whether to accept it or not. Application of security policy may occur
here.</dd><dd>3. LS2 sends the LSControlResponse answer indicating success
joining (result code: http://perfsonar.net/result/success/LS/join) or failure
(error code).</dd><dd>4. After receiving the response from LS2, LS1 parses
the results of LSControlResponse to discover all members of its
scope.</dd><dd>5. LS1 broadcast its summary info (lower or upper) with L
SControl message with http://perfsonar.net/services/LS/summary eventType to
all of the LS instances it learns of. This is of course "out of turn" as LS1
doesn't have the token yet but this reasoning is twofold: <dl
class="empty"><dd>This expedites all ring members knowing the new LS, the
ring will grow instantly by inserting the new member into the correct
position.</dd><dd>This allows the information it provides to the leaders to
become available for the next upper ring summary as soon as possible. Worst
case scenarios would place this knowledge cycles away from being
recognized.</dd></dl> </dd><dd>6. All members of the ring process the
summaries, save the necessary information, and recognize the new peer.
Responses are sent to LS1.</dd></dl><h3 id="rfc.section.2.3.2"><a
href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="tokens" href="#tokens">Token
Passing</a></h3><p id="rfc.section.2.3.2.p.1">The "token" is an
LSControlMessage (see <a href="#LSControl-Token" title="LS Token
Message">Section&nbsp;4.5</a>) meant to be passed around an !
LSRing t
o the various members in some order. There are various criteria that can be
used in deciding how to order the ring so that everyone can predict where the
token is, when they might expect to get it, and whom they should get it from/
pass it to next. It is important that we choose a sound method that is simple
to calculate, and should use as much "knowledge" of the ring as possible
without burdening the LS instances too much with complex calculations.</p><p
id="rfc.section.2.3.2.p.2">The essential idea in the token passing mechanism
for leader election is that some identifier is chosen for each node and that
the node with the highest (or lowest) identifier win the election and becomes
the leader. The basic mechanism of leader election is that participants form
a logical ring and initiate an election. An election can be initiated when a
new machine joins, at system start time, or when a host feels that the leader
may have failed based on failure to receive a periodic token. When
an election is initiated, the initiating host sends an election message to
its counter-clockwise neighbor and changes its state to
&#8220;ELECTING&#8221;. It places its identifier inside the message. The
ulimate goal is for the host with the highest identifier to be chosen. When a
host receives an election message, it compares its identifier with that in
the message. It forwards the higher of the identifiers. When a node receives
a message with its own identifier, it knows that it has been selected and the
election terminates.</p><p id="rfc.section.2.3.2.p.3">The next question is
how to choose the identifier for a given node. There still needs to be some
discussion here. The first proposal was to use the IP address of the node as
the lower-order 32-bits of a 64-bit number and to allow the higher-order bits
to be set as a "priority" field. This would effectively allow a system
administrator to make sure that her most powerful or well-connected nodes
became the leader when th
ey were available. In the absence of a priority, the nodes e!
ssential
ly are randomly ordered.</p><p id="rfc.section.2.3.2.p.4">Another possibility
is to use common method used in P2P systems such as Gnutella when forming
"ultrapeers" is to consider the size of the data that a node is serving. The
principle, as described <a
href="http://rakjar.de/gnufu/index.php/GnuFU_en#Network_model:_Change_who_calls_whom:_Ultrapeers_and_Leafs";>here</a>,
alludes to the fact that nodes with less content to look after (i.e. less
services, or services with a smaller amount of data) can spend more time and
effort helping the enterprise as a whole by taking on additional roles (such
as serving as leaders). As such we will record the number of metadata
elements that register with each LS and share this with our friends in the
form of the "contentSize" parameter.</p><p id="rfc.section.2.3.2.p.5">Token
passing is directly related to the concept of leader election (see <a
href="#Leader_Election" title="Leader election">Section&nbsp;2.3.4</a>), so
more explanation of t
his approach will follow. For now we are justified in saying that the
"contentSize" forms another good criterion for "ordering" the members of the
ring. With all members of the ring aware of everyone's data size, we can
easily know who we should pass the token to, and receive it from at any point
in time. We assume passing order between the LSs from smallest to greatest
"contentSize" (with wrap around at the ends). Of course, this metric leaves
out the relative power of the machines in question, so futher modifications
are possible.</p><p id="rfc.section.2.3.2.p.6">The key is that as long as the
identifier is chosen consistently within a given scope, the choice of
identifier doesn't affect the operation of the protocol.</p><p
id="rfc.section.2.3.2.p.7">The token can be viewed as "permission to talk"
and permits the holding LS to send its summary information to all other
available LS instances (see <a href="#LSControl-Summary-lower" title="LS
Summary Message (Lower)">Section&
nbsp;4.6</a> and <a href="#LSControl-Summary-upper" title="L!
S Summar
y Message (Upper)">Section&nbsp;4.7</a>). The responses will be parsed to get
any useful updated information about current dLS cloud state.</p><h4
id="rfc.section.2.3.2.1"><a href="#rfc.section.2.3.2.1">2.3.2.1</a>&nbsp;<a
id="token_passing_algorithm" href="#token_passing_algorithm">Token Passing
Algorithm</a></h4><div id="join-example"></div><div
id="rfc.figure.5"></div><p>Illustration of Token Passing Algorithm</p><pre>
+ </pre>
+<p>LS2, LS3 and LS4 are in the ring. LS1 wants to join the dLS cloud.</p>
+<p class="figure">Figure 4</p>
+<p id="rfc.section.2.3.1.1.p.2">The algorithm for joining the ring works as
follows:</p>
+<p id="rfc.section.2.3.1.1.p.3">
+</p>
+<dl class="empty">
+<dd>1. LS1 - Candidate sends LSControlRequest message with the
http://perfsonar.net/services/LS/join eventType to selected LS2 which is
already a member of the ring. LS2 was found in LSRing initial file during
bootstrapping process.</dd>
+<dd>2. LS2 receives join message from L1 and decides whether to accept it or
not. Application of security policy may occur here.</dd>
+<dd>3. LS2 sends the LSControlResponse answer indicating success joining
(result code: http://perfsonar.net/result/success/LS/join) or failure (error
code).</dd>
+<dd>4. After receiving the response from LS2, LS1 parses the results of
LSControlResponse to discover all members of its scope.</dd>
+<dd>5. LS1 broadcast its summary info (lower or upper) with LSControl
message with http://perfsonar.net/services/LS/summary eventType to all of the
LS instances it learns of. This is of course "out of turn" as LS1 doesn't
have the token yet but this reasoning is twofold: <dl class="empty">
+<dd>This expedites all ring members knowing the new LS, the ring will grow
instantly by inserting the new member into the correct position.</dd>
+<dd>This allows the information it provides to the leaders to become
available for the next upper ring summary as soon as possible. Worst case
scenarios would place this knowledge cycles away from being recognized.</dd>
+</dl>
+</dd>
+<dd>6. All members of the ring process the summaries, save the necessary
information, and recognize the new peer. Responses are sent to LS1.</dd>
+</dl>
+<h3 id="rfc.section.2.3.2">
+<a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="tokens"
href="#tokens">Token Passing</a>
+</h3>
+<p id="rfc.section.2.3.2.p.1">The "token" is an LSControlMessage (see <a
href="#LSControl-Token" title="LS Token Message">Section&nbsp;4.5</a>) meant
to be passed around an LSRing to the various members in some order. There are
various criteria that can be used in deciding how to order the ring so that
everyone can predict where the token is, when they might expect to get it,
and whom they should get it from/ pass it to next. It is important that we
choose a sound method that is simple to calculate, and should use as much
"knowledge" of the ring as possible without burdening the LS instances too
much with complex calculations.</p>
+<p id="rfc.section.2.3.2.p.2">The essential idea in the token passing
mechanism for leader election is that some identifier is chosen for each node
and that the node with the highest (or lowest) identifier win the election
and becomes the leader. The basic mechanism of leader election is that
participants form a logical ring and initiate an election. An election can be
initiated when a new machine joins, at system start time, or when a host
feels that the leader may have failed based on failure to receive a periodic
token. When an election is initiated, the initiating host sends an election
message to its counter-clockwise neighbor and changes its state to
&#8220;ELECTING&#8221;. It places its identifier inside the message. The
ultimate goal is for the host with the highest identifier to be chosen. When
a host receives an election message, it compares its identifier with that in
the message. It forwards the higher of the identifiers. When a node receives
a message with its o
wn identifier, it knows that it has been selected and the election
terminates.</p>
+<p id="rfc.section.2.3.2.p.3">The next question is how to choose the
identifier for a given node. There still needs to be some discussion here.
The first proposal was to use the IP address of the node as the lower-order
32-bits of a 64-bit number and to allow the higher-order bits to be set as a
"priority" field. This would effectively allow a system administrator to make
sure that her most powerful or well-connected nodes became the leader when
they were available. In the absence of a priority, the nodes essentially are
randomly ordered.</p>
+<p id="rfc.section.2.3.2.p.4">The key is that as long as the identifier is
chosen consistently within a given scope, the choice of identifier doesn't
affect the operation of the protocol.</p>
+<p id="rfc.section.2.3.2.p.5">The token can be viewed as "permission to
talk" and permits the holding LS to send its summary information to all other
available LS instances (see <a href="#LSControl-Summary-lower" title="LS
Summary Message (Lower)">Section&nbsp;4.6</a> and <a
href="#LSControl-Summary-upper" title="LS Summary Message
(Upper)">Section&nbsp;4.7</a>). The responses will be parsed to get any
useful updated information about current dLS cloud state.</p>
+<h4 id="rfc.section.2.3.2.1">
+<a href="#rfc.section.2.3.2.1">2.3.2.1</a>&nbsp;<a
id="token_passing_algorithm" href="#token_passing_algorithm">Token Passing
Algorithm</a>
+</h4>
+<div id="join-example">
+</div>
+<div id="rfc.figure.5">
+</div>
+<p>Illustration of Token Passing Algorithm</p>
+<pre>

_____________(3)____________
| |
@@ -359,7 +594,100 @@



- </pre><p>LS1, LS2 and LS3 are in the ring. LS1 receives a
token.</p><p class="figure">Figure 5</p><p id="rfc.section.2.3.2.1.p.2">The
algorithm for token passing works as follows:</p><p
id="rfc.section.2.3.2.1.p.3"> </p><dl class="empty"><dd>1. LS1 receives the
token i.e. LSControlRequest message with the
http://perfsonar.net/services/LS/token/ eventType from its predecessor
L3.</dd><dd>2. LS1 updates its local peer list based on token
content.</dd><dd>2.x (More description needed)</dd><dd>2.1 If token contains
entry that is not present in the local LSRing, copy this entry to local
LSRing</dd><dd>2.2 If token doesn't contains entry that is present in the
local LSRing... (to be discussed: there are two cases: new LS just joined to
LS that has got the token right now OR local LSRing contains obsolete LS
entry -- I guess we'll base on active parameter, but it's not elaborated how
it works</dd><dd>3. LS1 sends LSControlRequest message with the
http://perfsonar.net/s
ervices/LS/summary/ eventType to all peers in the lease (excluding
itself).</dd><dd>3. LS2 receiving this message checks its collection and
updates it if necessary with service info including "contentSize".</dd><dd>4.
LS1 waits for some amount of time.</dd><dd>5. LS1 sends token to next LS
(LS2) from the LSRing lower scope (if it fails, try next one).</dd></dl><h4
id="rfc.section.2.3.2.2"><a href="#rfc.section.2.3.2.2">2.3.2.2</a>&nbsp;<a
id="rotation-time-computing" href="#rotation-time-computing">Token rotation
time computing</a></h4><p id="rfc.section.2.3.2.2.p.1">The token rotation
time is the time of passing and serving token by all nodes in the LS ring.
This time should be computed by the leader basing on some knowledge about the
time of serving token by all particular nodes. The time may be based on times
saving in token message by all nodes. Initially, this can be very simple as
in "2 minutes X the number of nodes in the ring." (To be discussed)</p><p
id="rfc.section
.2.3.2.2.p.2">The key is that after the timeout has exceeded!
, it can
be inferred that the leader has failed and another election should be
initiated.</p><h3 id="rfc.section.2.3.3"><a
href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="summary-blast"
href="#summary-blast">Summarization Notification</a></h3><p
id="rfc.section.2.3.3.p.1">As discussed in the prior two sections there are
two acceptable instances to send your summary to the LSRing: </p><ol><li>When
first joining</li><li>When holding the token</li></ol><p
id="rfc.section.2.3.3.p.2">In the first case we are explicitly entering
ourselves into the ring when we get our first message from a peer. This
ensures we show up in the token rotation instantly. The second case is the
routine exchange started when a token arrives from a peer.</p><p
id="rfc.section.2.3.3.p.3"> <a href="#LSControl-Summary-lower" title="LS
Summary Message (Lower)">Section&nbsp;4.6</a> and <a
href="#LSControl-Summary-upper" title="LS Summary Message
(Upper)">Section&nbsp;4.7</a> contain examples of the message format for
this exchange. It is left up to the implementation when the summarization
occurs (i.e. at message send time, or also as a periodic event).</p><h3
id="rfc.section.2.3.4"><a href="#rfc.section.2.3.4">2.3.4</a>&nbsp;<a
id="Leader_Election" href="#Leader_Election">Leader election</a></h3><p
id="rfc.section.2.3.4.p.1">The most important role of the lower scope nodes
is electing a leader to serve in the upper levels. This logical ring should
consist of one representative LS from each of the lower scopes. </p><p
id="rfc.section.2.3.4.p.2">The Leader and Vice-Leader LS instances should
exchange messages (see <a href="#LSControl-Leader" title="LS Leader
Message">Section&nbsp;4.8</a>) periodically to ensure that in the event of a
failure the lower level will still have a link to the upper level. A
Vice-Leader will be monitoring the time between successive communications
from the Leader to be sure it has not failed. In the event that it has, the
"Join" procedure will start to the upper
level to keep the hierarchy complete.</p><h2 id="rfc.sectio!
n.2.4"><
a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="search"
href="#search">Search</a></h2><p id="rfc.section.2.4.p.1">The search
operation is obviously critical to the Lookup Service's function. It is
envisioned that searching could take one of two major forms, iterative and
recursive, analogous to those used in DNS. This design will focus exclusively
on iterative initially as the only method in the first versions of the dLS.
The key act when searching is to find what eventTypes exist for a particular
topology element or set of topology elements.</p><p
id="rfc.section.2.4.p.2">As outlined above, the full data that services
register to an LS is not expected to leave the scope of that LS. The
information is summarized before wider distribution. Therefore, a client
needs to find an LS in the scope of the HLS to make queries about the
complete metadata. Specifically, a client wishing to locate information might
specify a topology element in a query to locate the LS instance (or instanc
es) that contain the relevant details. This separation of full data and
summary data means the overall act of searching is broken down into two
distinct phases - Discovery and Metadata Query.</p><h3
id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;<a
id="discovery" href="#discovery">Discovery Phase</a></h3><p
id="rfc.section.2.4.1.p.1">The discovery phase is used to locate the set of
Authoritative LS (or LSes) for a given Subject/eventType tuple. This requires
a query to be constructed over the Discovery information set (which is not
described yet, but which must consist of the 3-tuple of Subject Summary,
eventType and Authoritative LS.) Either a specific API call and a
pre-prepared query, or some automatic mechanism, must map the desired query
into a query of the Discovery infoset (see <a href="#LSControl-Discovery"
title="LS Discovery Message">Section&nbsp;4.9</a>).</p><h4
id="rfc.section.2.4.1.1"><a href="#rfc.section.2.4.1.1">2.4.1.1</a>&nbsp;<a
id="dis
covery-alg" href="#discovery-alg">Discovery Algorithm</a></h!
4><p id=
"rfc.section.2.4.1.1.p.1">The discovery algorithm is as follows.</p><ol><li>A
client locates an LS of some sort (this may be known beforehand via a
configuration value, or from bootstrapping).</li><li>The client should start
by making a discovery query (possibly using an API call) to locate an LS that
contains the data it is interested in. The results of this query will be: <ol
style="list-style-type: lower-alpha"><li>Failure: Returned if there is no LS
at a higher scope than the current one, and nothing was found in the summary
infoset that matches the query.</li><li>Referral: This is returned when there
is no match other than a "global wildcard" <ol style="list-style-type:
lower-alpha"><li>If this LS is not participating in the highest (upper)
scope, then it returns the leader of its current scope (or a direct referral
to an instance of the next-higher scope.) This is effectively a wildcard
match saying "I don't know the answer, but I know who might." This is how the
Metada
ta registered to an LS in another scope (domain) is found.</li></ol>
</li><li>Success: We define success to mean at least one matching LS has been
returned. The LS must return the following: <ol style="list-style-type:
lower-alpha"><li>If this LS is an HLS for the discovery query, it returns
itself.</li><li>This LS also returns any other HLS instances it has found
that match. An LS instance will have summary information from other domains
when it is participating in a higher-level scope (such as
upper).</li><li>Note: this is where recursive searches would be added into
the discovery phase. The trail up the scope hierarchy would be followed by
the LS itself instead of returning the leader LS. Ideally, this list would be
iterated on by the LS so that only leaf LS instances are returned</li></ol>
</li></ol> </li><li>The client will need to iterate through the list of
returned LS instances. If the LS returns itself, this LS can be used in the
following Metadata query phase. If t
he returned LS is different, a discovery query should be mad!
e to it.
</li></ol><h3 id="rfc.section.2.4.2"><a
href="#rfc.section.2.4.2">2.4.2</a>&nbsp;<a id="metadata-query"
href="#metadata-query">Metadata Query Phase</a></h3><p
id="rfc.section.2.4.2.p.1">The Metadata Query Phase with an individual LS is
the same as the query mechanism that is in place with the current LS
implementations.</p><p id="rfc.section.2.4.2.p.2">Once we have found the HLS
(or Home LSes) that contain data in the range of our discovery query, we can
pose Metadata Queries to each of them. The results will be failure or
success.</p><hr class="noprint"><h1 id="rfc.section.3" class="np"><a
href="#rfc.section.3">3.</a>&nbsp;<a id="bootstrapping"
href="#bootstrapping">Bootstrapping</a></h1><p id="rfc.section.3.p.1">A
distributed information system such as the LS needs to address bootstrapping.
In this system, an LS instance needs to find other members of its scope (for
each scope in which it participates.) To accomplish this we will use a
similar solution to what DNS uses (roo
t.hints).</p><p id="rfc.section.3.p.2">We will maintain a service that
maintains a list of currently known LS instances. These known instances
should preferably be at the upper scope. All clients can cache this list. The
service will be accessed via a well-known hostname, and could be requested
via UDP messages. (We can also use TCP here for some sorts of anycast.)</p><p
id="rfc.section.3.p.3">Initially this will be deployed on one server. We can
extend this to handle redundancy and load balancing in the future by using
multiple DNS records and implementing ANYCAST with routing tricks for this
well known hostname. (Additionally, we can distribute an initial file with a
list of well known LS instances that are supported by the primary perfSONAR
participants.)</p><p id="rfc.section.3.p.4">The above discovery algorithm is
used to find an LS within a given scope. Therefore, the only piece of
information an LS should need to be pre-configured with is the scope it
belongs to. And
as stated above, that can be assumed to be "global:organizat!
ion-dns-
name". Note: Need to define the specific syntax above.</p><hr
class="noprint"><h1 id="rfc.section.4" class="np"><a
href="#rfc.section.4">4.</a>&nbsp;<a id="structures-and-messages"
href="#structures-and-messages">Structures and Messages</a></h1><h2
id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a
id="service-metadata" href="#service-metadata">Service metadata
example</a></h2><p id="rfc.section.4.1.p.1">Example of metadata describing
information collected and stored in Measurement Archive service</p><p
id="rfc.section.4.1.p.2"> <pre>
+ </pre>
+<p>LS1, LS2 and LS3 are in the ring. LS1 receives a token.</p>
+<p class="figure">Figure 5</p>
+<p id="rfc.section.2.3.2.1.p.2">The algorithm for token passing works as
follows:</p>
+<p id="rfc.section.2.3.2.1.p.3">
+</p>
+<dl class="empty">
+<dd>1. LS1 receives the token i.e. LSControlRequest message with the
http://perfsonar.net/services/LS/token/ eventType from its predecessor
L3.</dd>
+<dd>2. LS1 updates its 'lower' peer list based on token content.</dd>
+<dd>2.x (More description needed)</dd>
+<dd>2.1 If token contains entry that is not present in the 'lower' LSRing,
copy this entry to 'lower' LSRing</dd>
+<dd>2.2 If token doesnt contains entry that is present in the 'lower'
LSRing... (to be discussed: there are two cases: new LS just joined to LS
that has got the token right now OR local LSRing contains obsolete LS entry
-- I guess we'll base on active parameter, but it's not elaborated how it
works</dd>
+<dd>3. LS1 sends LSControlRequest message with the
http://perfsonar.net/services/LS/summary/ eventType to all peers in the lease
(excluding itself).</dd>
+<dd>3. LS2 receiving this message checks its collection and updates it if
necessary with service info.</dd>
+<dd>4. LS1 waits for some amount of time.</dd>
+<dd>5. LS1 sends token to next LS (LS2) from the LSRing lower scope (if it
fails, try next one).</dd>
+</dl>
+<h4 id="rfc.section.2.3.2.2">
+<a href="#rfc.section.2.3.2.2">2.3.2.2</a>&nbsp;<a
id="rotation-time-computing" href="#rotation-time-computing">Token rotation
time computing</a>
+</h4>
+<p id="rfc.section.2.3.2.2.p.1">The token rotation time is the time of
passing and serving token by all nodes in the LS ring. This time should be
computed by the leader basing on some knowledge about the time of serving
token by all particular nodes. The time may be based on times saving in token
message by all nodes. Initially, this can be very simple as in "2 minutes X
the number of nodes in the ring." (To be discussed)</p>
+<p id="rfc.section.2.3.2.2.p.2">The key is that after the timeout has
exceeded, it can be inferred that the leader has failed and another election
should be initiated.</p>
+<h3 id="rfc.section.2.3.3">
+<a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="summary-blast"
href="#summary-blast">Summarization Notification</a>
+</h3>
+<p id="rfc.section.2.3.3.p.1">As discussed in the prior two sections there
are two acceptable instances to send your summary to the LSRing:</p>
+<p id="rfc.section.2.3.3.p.2">
+</p>
+<ol>
+<li>When first joining</li>
+<li>When holding the token</li>
+</ol>
+<p id="rfc.section.2.3.3.p.3">In the first case we are explicitly entering
ourselves into the ring when we get our first message from a peer. This
ensures we show up in the token rotation instantly. The second case is the
routine exchange started when a token arrives from a peer.</p>
+<p id="rfc.section.2.3.3.p.4">
+<a href="#LSControl-Summary-lower" title="LS Summary Message
(Lower)">Section&nbsp;4.6</a> and <a href="#LSControl-Summary-upper"
title="LS Summary Message (Upper)">Section&nbsp;4.7</a> contain examples of
the message format for this exchange. It is left up to the implementation
when the summarization occurs (i.e. at message send time, or also as a
periodic event).</p>
+<h3 id="rfc.section.2.3.4">
+<a href="#rfc.section.2.3.4">2.3.4</a>&nbsp;<a id="Leader_Election"
href="#Leader_Election">Leader election</a>
+</h3>
+<p id="rfc.section.2.3.4.p.1">The most important role of any group of HLS
instances is electing a leader to serve as a representative in upper level
communication. This logical ring should consist of one representative LS from
each of similar lower scope configuration.</p>
+<p id="rfc.section.2.3.4.p.2">The Leader and Vice-Leader LS instances should
exchange messages (see <a href="#LSControl-Leader" title="LS Leader
Message">Section&nbsp;4.8</a>) periodically to ensure that in the event of a
failure the lower level will still have a link to the upper level. A
Vice-Leader will be monitoring the time between successive communications
from the Leader to be sure it has not failed. In the event that it has, the
"Join" procedure will start to the upper level to keep the hierarchy
complete.</p>
+<h2 id="rfc.section.2.4">
+<a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="search"
href="#search">Search</a>
+</h2>
+<p id="rfc.section.2.4.p.1">The search operation is obviously critical to
the Lookup Service's function. It is envisioned that searching could take one
of two major forms, iterative and recursive, analogous to those used in DNS.
This design will focus exclusively on iterative initially as the only method
in the first versions of the dLS. The key act when searching is to find what
eventTypes exist for a particular topology element or set of topology
elements.</p>
+<p id="rfc.section.2.4.p.2">As outlined above, the full data that services
register to an LS is not expected to leave the scope of that LS. The
information is summarized before wider distribution. Therefore, a client
needs to find an LS in the scope of the HLS to make queries about the
complete metadata. Specifically, a client wishing to locate information might
specify a topology element in a query to locate the LS instance (or
instances) that contain the relevant details. This separation of full data
and summary data means the overall act of searching is broken down into two
distinct phases - Discovery and Metadata Query.</p>
+<h3 id="rfc.section.2.4.1">
+<a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;<a id="discovery"
href="#discovery">Discovery Phase</a>
+</h3>
+<p id="rfc.section.2.4.1.p.1">The discovery phase is used to locate the set
of Authoritative LS (or LSes) for a given Subject/eventType tuple. This
requires a query to be constructed over the Discovery information set (which
is not described yet, but which must consist of the 3-tuple of Subject
Summary, eventType and Authoritative LS.) Either a specific API call and a
pre-prepared query, or some automatic mechanism, must map the desired query
into a query of the Discovery info-set (see <a href="#LSControl-Discovery"
title="LS Discovery Message">Section&nbsp;4.9</a>).</p>
+<h4 id="rfc.section.2.4.1.1">
+<a href="#rfc.section.2.4.1.1">2.4.1.1</a>&nbsp;<a id="discovery-alg"
href="#discovery-alg">Discovery Algorithm</a>
+</h4>
+<p id="rfc.section.2.4.1.1.p.1">The discovery algorithm is as follows.</p>
+<ol>
+<li>A client locates an LS of some sort (this may be known beforehand via a
configuration value, or from bootstrapping).</li>
+<li>The client should start by making a discovery query (possibly using an
API call) to locate an LS that contains the data it is interested in. The
results of this query will be: <ol style="list-style-type: lower-alpha">
+<li>Failure: Returned if there is no LS at a higher scope than the current
one, and nothing was found in the summary info-set that matches the
query.</li>
+<li>Referral: This is returned when there is no match other than a "global
wildcard" <ol style="list-style-type: lower-alpha">
+<li>If this LS is not participating in the highest (upper) scope, then it
returns the leader of its current scope (or a direct referral to an instance
of the next-higher scope.) This is effectively a wildcard match saying "I
don't know the answer, but I know who might." This is how the Metadata
registered to an LS in another scope (domain) is found.</li>
+</ol>
+</li>
+<li>Success: We define success to mean at least one matching LS has been
returned. The LS must return the following: <ol style="list-style-type:
lower-alpha">
+<li>If this LS is an HLS for the discovery query, it returns itself.</li>
+<li>This LS also returns any other HLS instances it has found that match. An
LS instance will have summary information from other domains when it is
participating in a higher-level scope (such as upper).</li>
+<li>Note: this is where recursive searches would be added into the discovery
phase. The trail up the scope hierarchy would be followed by the LS itself
instead of returning the leader LS. Ideally, this list would be iterated on
by the LS so that only leaf LS instances are returned</li>
+</ol>
+</li>
+</ol>
+</li>
+<li>The client will need to iterate through the list of returned LS
instances. If the LS returns itself, this LS can be used in the following
Metadata query phase. If the returned LS is different, a discovery query
should be made to it.</li>
+</ol>
+<h3 id="rfc.section.2.4.2">
+<a href="#rfc.section.2.4.2">2.4.2</a>&nbsp;<a id="metadata-query"
href="#metadata-query">Metadata Query Phase</a>
+</h3>
+<p id="rfc.section.2.4.2.p.1">The Metadata Query Phase with an individual LS
is the same as the query mechanism that is in place with the current LS
implementations.</p>
+<p id="rfc.section.2.4.2.p.2">Once we have found the HLS (or Home LSes) that
contain data in the range of our discovery query, we can pose Metadata
Queries to each of them. The results will be failure or success.</p>
+<hr class="noprint">
+<h1 id="rfc.section.3" class="np">
+<a href="#rfc.section.3">3.</a>&nbsp;<a id="bootstrapping"
href="#bootstrapping">Bootstrapping</a>
+</h1>
+<p id="rfc.section.3.p.1">A distributed information system such as the LS
needs to address bootstrapping. In this system, an LS instance needs to find
other members of its scope (for each scope in which it participates.) To
accomplish this we will use a similar solution to what DNS uses
(root.hints).</p>
+<p id="rfc.section.3.p.2">We will maintain a service that maintains a list
of currently known LS instances. These known instances should preferably be
at the upper scope. All clients can cache this list. The service will be
accessed via a well-known hostname, and could be requested via UDP messages.
(We can also use TCP here for some sorts of anycast.)</p>
+<p id="rfc.section.3.p.3">Initially this will be deployed on one server. We
can extend this to handle redundancy and load balancing in the future by
using multiple DNS records and implementing ANYCAST with routing tricks for
this well known hostname. (Additionally, we can distribute an initial file
with a list of well known LS instances that are supported by the primary
perfSONAR participants.)</p>
+<p id="rfc.section.3.p.4">The above discovery algorithm is used to find an
LS within a given scope. Therefore, the only piece of information an LS
should need to be pre-configured with is the scope it belongs to. And as
stated above, that can be assumed to be "global:organization-dns-name". Note:
Need to define the specific syntax above.</p>
+<hr class="noprint">
+<h1 id="rfc.section.4" class="np">
+<a href="#rfc.section.4">4.</a>&nbsp;<a id="structures-and-messages"
href="#structures-and-messages">Structures and Messages</a>
+</h1>
+<h2 id="rfc.section.4.1">
+<a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="service-metadata"
href="#service-metadata">Service metadata example</a>
+</h2>
+<p id="rfc.section.4.1.p.1">Example of metadata describing information
collected and stored in Measurement Archive service</p>
+<p id="rfc.section.4.1.p.2">
+<pre>

&lt;nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
id="m_ale-netutil-1"&gt;
&lt;netutil:subject
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/";
id="s_ale-netutil-1"&gt;
@@ -380,7 +708,14 @@
&lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

- </pre> </p><h2 id="rfc.section.4.2"><a
href="#rfc.section.4.2">4.2</a>&nbsp;<a id="lookup-info"
href="#lookup-info">Lookup Information</a></h2><p
id="rfc.section.4.2.p.1">Example Lookup Information of Measurement Archive.
The metadata block contains basic service information and data elements
containing the metadata from the MA.</p><p id="rfc.section.4.2.p.2"> <pre>
+ </pre>
+</p>
+<h2 id="rfc.section.4.2">
+<a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="lookup-info"
href="#lookup-info">Lookup Information</a>
+</h2>
+<p id="rfc.section.4.2.p.1">Example Lookup Information of Measurement
Archive. The metadata block contains basic service information and data
elements containing the metadata from the MA.</p>
+<p id="rfc.section.4.2.p.2">
+<pre>

&lt;nmwg:metadata
id="http://newcastle.pc.cis.udel.edu:6767/perfSONAR_PS/services/snmpMA"&gt;
&lt;perfsonar:subject id="subject.15977808"&gt;
@@ -416,7 +751,17 @@
&lt;/nmwg:data&gt;


- </pre> </p><h2 id="rfc.section.4.3"><a
href="#rfc.section.4.3">4.3</a>&nbsp;<a id="LSRing" href="#LSRing">LS Ring
File Structure</a></h2><p id="rfc.section.4.3.p.1">The LSRing file represents
the "state" of the LS cloud at either level of hierarchy (we avoid using the
terms "global" and "local" here since the hierarchy may be much larger). This
file must start with some static values, and will be added to/deleted from as
time goes on. As such implementations must ensure that this file is under
database control of some sort.</p><h3 id="rfc.section.4.3.1"><a
href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="LSRingLower"
href="#LSRingLower">LS Ring lower level</a></h3><p
id="rfc.section.4.3.1.p.1"> <pre>
+ </pre>
+</p>
+<h2 id="rfc.section.4.3">
+<a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="LSRing" href="#LSRing">LS
Ring File Structure</a>
+</h2>
+<p id="rfc.section.4.3.p.1">The LSRing file represents the "state" of the LS
cloud at either level of hierarchy (we avoid using the terms "global" and
"local" here since the hierarchy may be much larger). This file must start
with some static values, and will be added to/deleted from as time goes on.
As such implementations must ensure that this file is under database control
of some sort.</p>
+<h3 id="rfc.section.4.3.1">
+<a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="LSRingLower"
href="#LSRingLower">LS Ring lower level</a>
+</h3>
+<p id="rfc.section.4.3.1.p.1">
+<pre>

&lt;nmwg:store type="LSRing-lower"&gt;

@@ -433,7 +778,6 @@
&lt;/perfsonar:subject&gt;
&lt;nmwg:parameters&gt;
&lt;nmwg:parameter name="active"&gt;0&lt;/nmwg:parameter&gt;
- &lt;nmwg:parameter name="contentSize"&gt;100&lt;/nmwg:parameter&gt;
&lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

@@ -448,7 +792,6 @@
&lt;/perfsonar:subject&gt;
&lt;nmwg:parameters&gt;
&lt;nmwg:parameter name="active"&gt;1&lt;/nmwg:parameter&gt;
- &lt;nmwg:parameter name="contentSize"&gt;50&lt;/nmwg:parameter&gt;
&lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

@@ -463,7 +806,6 @@
&lt;/perfsonar:subject&gt;
&lt;nmwg:parameters&gt;
&lt;nmwg:parameter name="active"&gt;1&lt;/nmwg:parameter&gt;
- &lt;nmwg:parameter name="contentSize"&gt;0&lt;/nmwg:parameter&gt;
&lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

@@ -478,13 +820,18 @@
&lt;/perfsonar:subject&gt;
&lt;nmwg:parameters&gt;
&lt;nmwg:parameter name="active"&gt;1&lt;/nmwg:parameter&gt;
- &lt;nmwg:parameter name="contentSize"&gt;200&lt;/nmwg:parameter&gt;
&lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;/nmwg:store&gt;

- </pre> </p><h3 id="rfc.section.4.3.2"><a
href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="LSRingUpper"
href="#LSRingUpper">LS Ring upper level</a></h3><p
id="rfc.section.4.3.2.p.1"> <pre>
+ </pre>
+</p>
+<h3 id="rfc.section.4.3.2">
+<a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="LSRingUpper"
href="#LSRingUpper">LS Ring upper level</a>
+</h3>
+<p id="rfc.section.4.3.2.p.1">
+<pre>

&lt;nmwg:store type="LSRing-upper"&gt;

@@ -501,7 +848,6 @@
&lt;/perfsonar:subject&gt;
&lt;nmwg:parameters&gt;
&lt;nmwg:parameter name="active"&gt;1&lt;/nmwg:parameter&gt;
- &lt;nmwg:parameter name="contentSize"&gt;1000&lt;/nmwg:parameter&gt;
&lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

@@ -516,13 +862,23 @@
&lt;/perfsonar:subject&gt;
&lt;nmwg:parameters&gt;
&lt;nmwg:parameter name="active"&gt;1&lt;/nmwg:parameter&gt;
- &lt;nmwg:parameter name="contentSize"&gt;500&lt;/nmwg:parameter&gt;
&lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;/nmwg:store&gt;

- </pre> </p><h2 id="rfc.section.4.4"><a
href="#rfc.section.4.4">4.4</a>&nbsp;<a id="LSControl-Join"
href="#LSControl-Join">LS Joining Message for Joining a Ring</a></h2><p
id="rfc.section.4.4.p.1">This message exchange represents when a "new" LS
instance comes online. The LS will send these messages to its "list" of known
LS instances until it gets a hit. The message consists of metadata/data
pair(s) that contain service information and a parameter indicating "size" of
the data set the LS manages. This will be used for leader voting purposes
later.</p><p id="rfc.section.4.4.p.2">The response message should indicate
success or failure via the eventType, and will contain metadata/data pair(s).
The metadata should indicate who the service is, and its "size" for voting
purposes. The data section is an enumeration of all of the current members of
the ring and their votes. This information gives the new member a snapshot of
the ring.</p><h3 id="rfc.section.4.4.1"><a href="#rf
c.section.4.4.1">4.4.1</a>&nbsp;<a id="LSControl-JoinRequest"
href="#LSControl-JoinRequest">Request</a></h3><p id="rfc.section.4.4.1.p.1">
<pre>
+ </pre>
+</p>
+<h2 id="rfc.section.4.4">
+<a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="LSControl-Join"
href="#LSControl-Join">LS Joining Message for Joining a Ring</a>
+</h2>
+<p id="rfc.section.4.4.p.1">This message exchange represents when a "new" LS
instance comes online. The LS will send these messages to its "list" of known
LS instances until it gets a hit. The message consists of metadata/data
pair(s) that contain service information and a parameter indicating "size" of
the data set the LS manages. This will be used for leader voting purposes
later.</p>
+<p id="rfc.section.4.4.p.2">The response message should indicate success or
failure via the eventType, and will contain metadata/data pair(s). The
metadata should indicate who the service is, and its "size" for voting
purposes. The data section is an enumeration of all of the current members of
the ring and their votes. This information gives the new member a snapshot of
the ring.</p>
+<h3 id="rfc.section.4.4.1">
+<a href="#rfc.section.4.4.1">4.4.1</a>&nbsp;<a id="LSControl-JoinRequest"
href="#LSControl-JoinRequest">Request</a>
+</h3>
+<p id="rfc.section.4.4.1.p.1">
+<pre>

&lt;nmwg:message type="LSControlRequest"&gt;

@@ -536,16 +892,19 @@
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/join&lt;/nmwg:eventType&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;100&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;nmwg:data id="data.2" metadataIdRef="metadata.2" /&gt;

&lt;/nmwg:message&gt;

- </pre> </p><h3 id="rfc.section.4.4.2"><a
href="#rfc.section.4.4.2">4.4.2</a>&nbsp;<a id="LSControl-JoinResponse"
href="#LSControl-JoinResponse">Response</a></h3><p
id="rfc.section.4.4.2.p.1"> <pre>
+ </pre>
+</p>
+<h3 id="rfc.section.4.4.2">
+<a href="#rfc.section.4.4.2">4.4.2</a>&nbsp;<a id="LSControl-JoinResponse"
href="#LSControl-JoinResponse">Response</a>
+</h3>
+<p id="rfc.section.4.4.2.p.1">
+<pre>

&lt;nmwg:message type="LSControlResponse"&gt;

@@ -559,9 +918,6 @@
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/join/success&lt;/nmwg:eventType&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;50&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;nmwg:data id="data.6" metadataIdRef="metadata.6"&gt;
@@ -574,9 +930,6 @@

&lt;psservice:serviceDescription&gt;...&lt;/psservice:serviceDescription&gt;
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;0&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;nmwg:metadata id="metadata.9"&gt;
@@ -588,15 +941,23 @@

&lt;psservice:serviceDescription&gt;...&lt;/psservice:serviceDescription&gt;
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;200&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;
&lt;/nmwg:data&gt;

&lt;/nmwg:message&gt;

- </pre> </p><h2 id="rfc.section.4.5"><a
href="#rfc.section.4.5">4.5</a>&nbsp;<a id="LSControl-Token"
href="#LSControl-Token">LS Token Message</a></h2><p
id="rfc.section.4.5.p.1">This message exchange represents the token that is
passed between LS instances in a cloud. The message contains metadata/data
pair(s) wherein the Metadata is the sending LS's info, and the data contains
the contents of the LSRing file (lower or upper depending on the token we are
exchanging).</p><p id="rfc.section.4.5.p.2">The response to this message
should indicate success or failure. Failure and timeouts should trigger a
resend.</p><h3 id="rfc.section.4.5.1"><a
href="#rfc.section.4.5.1">4.5.1</a>&nbsp;<a id="LSControl-TokenRequest"
href="#LSControl-TokenRequest">Request</a></h3><p id="rfc.section.4.5.1.p.1">
<pre>
+ </pre>
+</p>
+<h2 id="rfc.section.4.5">
+<a href="#rfc.section.4.5">4.5</a>&nbsp;<a id="LSControl-Token"
href="#LSControl-Token">LS Token Message</a>
+</h2>
+<p id="rfc.section.4.5.p.1">This message exchange represents the token that
is passed between LS instances in a cloud. The message contains metadata/data
pair(s) wherein the Metadata is the sending LS's info, and the data contains
the contents of the LSRing file (lower or upper depending on the token we are
exchanging).</p>
+<p id="rfc.section.4.5.p.2">The response to this message should indicate
success or failure. Failure and timeouts should trigger a resend.</p>
+<h3 id="rfc.section.4.5.1">
+<a href="#rfc.section.4.5.1">4.5.1</a>&nbsp;<a id="LSControl-TokenRequest"
href="#LSControl-TokenRequest">Request</a>
+</h3>
+<p id="rfc.section.4.5.1.p.1">
+<pre>

&lt;nmwg:message type="LSControlRequest"&gt;

@@ -610,9 +971,6 @@
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/token/lower&lt;/nmwg:eventType&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;50&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;nmwg:data id="data.6" metadataIdRef="metadata.6"&gt;
@@ -628,7 +986,6 @@
&lt;/perfsonar:subject&gt;
&lt;nmwg:parameters&gt;
&lt;nmwg:parameter name="active"&gt;1&lt;/nmwg:parameter&gt;
- &lt;nmwg:parameter name="contentSize"&gt;100&lt;/nmwg:parameter&gt;
&lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

@@ -644,7 +1001,13 @@

&lt;/nmwg:message&gt;

- </pre> </p><h3 id="rfc.section.4.5.2"><a
href="#rfc.section.4.5.2">4.5.2</a>&nbsp;<a id="LSControl-TokenResponse"
href="#LSControl-TokenResponse">Response</a></h3><p
id="rfc.section.4.5.2.p.1"> <pre>
+ </pre>
+</p>
+<h3 id="rfc.section.4.5.2">
+<a href="#rfc.section.4.5.2">4.5.2</a>&nbsp;<a id="LSControl-TokenResponse"
href="#LSControl-TokenResponse">Response</a>
+</h3>
+<p id="rfc.section.4.5.2.p.1">
+<pre>

&lt;nmwg:message type="LSControlResponse"&gt;

@@ -660,7 +1023,6 @@

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/token/lower/success&lt;/nmwg:eventType&gt;
&lt;nmwg:parameters&gt;
&lt;nmwg:parameter name="active"&gt;1&lt;/nmwg:parameter&gt;
- &lt;nmwg:parameter name="contentSize"&gt;100&lt;/nmwg:parameter&gt;
&lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

@@ -670,7 +1032,24 @@

&lt;/nmwg:message&gt;

- </pre> </p><h2 id="rfc.section.4.6"><a
href="#rfc.section.4.6">4.6</a>&nbsp;<a id="LSControl-Summary-lower"
href="#LSControl-Summary-lower">LS Summary Message (Lower)</a></h2><p
id="rfc.section.4.6.p.1">This message exchange represents when an LS instance
is holding the token and sharing summary information (lower scope). The
message consists of metadata/data pair(s) that contain service information
and a parameter indicating "size" of the data set the LS manages as well as
the minimal (without parameters) summary.</p><p id="rfc.section.4.6.p.2">The
response message should indicate success or failure via the eventType, and
will contain metadata/data pair(s). The metadata should indicate who the
service is, and its "size" for leader voting purposes. The data section is
message that can be used for logging.</p><p id="rfc.section.4.6.p.3">When
receiving the message, check your local list and update it as needed for:
</p><dl class="empty"><dd>Do you know of this service? I
f so make sure the vote and other info is ok.</dd><dd>Update the summary
info in your collection</dd><dd>If you don"t know of them, add
them!</dd></dl><h3 id="rfc.section.4.6.1"><a
href="#rfc.section.4.6.1">4.6.1</a>&nbsp;<a id="LSControl-Summary2Request"
href="#LSControl-Summary2Request">Request</a></h3><p
id="rfc.section.4.6.1.p.1"> <pre>
+ </pre>
+</p>
+<h2 id="rfc.section.4.6">
+<a href="#rfc.section.4.6">4.6</a>&nbsp;<a id="LSControl-Summary-lower"
href="#LSControl-Summary-lower">LS Summary Message (Lower)</a>
+</h2>
+<p id="rfc.section.4.6.p.1">This message exchange represents when an LS
instance is holding the token and sharing summary information (lower scope).
The message consists of metadata/data pair(s) that contain service
information and a parameter indicating "size" of the data set the LS manages
as well as the minimal (without parameters) summary.</p>
+<p id="rfc.section.4.6.p.2">The response message should indicate success or
failure via the eventType, and will contain metadata/data pair(s). The
metadata should indicate who the service is, and its "size" for leader voting
purposes. The data section is message that can be used for logging.</p>
+<p id="rfc.section.4.6.p.3">When receiving the message, check your 'lower'
list and update it as needed for: </p>
+<dl class="empty">
+<dd>Do you know of this service? If so make sure the vote and other info is
ok.</dd>
+<dd>Update the summary info in your collection</dd>
+<dd>If you don"t know of them, add them!</dd>
+</dl>
+<h3 id="rfc.section.4.6.1">
+<a href="#rfc.section.4.6.1">4.6.1</a>&nbsp;<a
id="LSControl-Summary2Request" href="#LSControl-Summary2Request">Request</a>
+</h3>
+<p id="rfc.section.4.6.1.p.1">
+<pre>

&lt;nmwg:message type="LSControlRequest"&gt;

@@ -684,9 +1063,6 @@
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/summary/lower&lt;/nmwg:eventType&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;100&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;nmwg:data id="data.2" metadataIdRef="metadata.2"&gt;
@@ -704,7 +1080,13 @@
&lt;/nmwg:message&gt;


- </pre> </p><h3 id="rfc.section.4.6.2"><a
href="#rfc.section.4.6.2">4.6.2</a>&nbsp;<a id="LSControl-Summary2Response"
href="#LSControl-Summary2Response">Response</a></h3><p
id="rfc.section.4.6.2.p.1"> <pre>
+ </pre>
+</p>
+<h3 id="rfc.section.4.6.2">
+<a href="#rfc.section.4.6.2">4.6.2</a>&nbsp;<a
id="LSControl-Summary2Response"
href="#LSControl-Summary2Response">Response</a>
+</h3>
+<p id="rfc.section.4.6.2.p.1">
+<pre>

&lt;nmwg:message type="LSControlResponse"&gt;

@@ -719,9 +1101,6 @@
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/summary/lower/success&lt;/nmwg:eventType&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;50&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;nmwg:data id="data.6" metadataIdRef="metadata.6"&gt;
@@ -730,7 +1109,24 @@

&lt;/nmwg:message&gt;

- </pre> </p><h2 id="rfc.section.4.7"><a
href="#rfc.section.4.7">4.7</a>&nbsp;<a id="LSControl-Summary-upper"
href="#LSControl-Summary-upper">LS Summary Message (Upper)</a></h2><p
id="rfc.section.4.7.p.1">This message exchange represents when an LS instance
is holding the token and sharing summary information. The message consists of
metadata/data pair(s) that contain service information and a parameter
indicating "size" of the data set the LS manages. The "data" portion is the
summary info (FORMAT TBD!!!)</p><p id="rfc.section.4.7.p.2">The response
message should indicate success or failure via the eventType, and will
contain metadata/data pair(s). The metadata should indicate who the service
is, and its "size" for leader voting purposes. The data section is message
that can be used for logging.</p><p id="rfc.section.4.7.p.3">When receiving
the message, check your local list and update it as needed for: </p><dl
class="empty"><dd>Do you know of this service? If so make s
ure the vote and other info is ok.</dd><dd>Update the summary info in your
collection</dd><dd>If you don't know of them, add them!</dd></dl><h3
id="rfc.section.4.7.1"><a href="#rfc.section.4.7.1">4.7.1</a>&nbsp;<a
id="LSControl-SummaryRequest"
href="#LSControl-SummaryRequest">Request</a></h3><p
id="rfc.section.4.7.1.p.1"> <pre>
+ </pre>
+</p>
+<h2 id="rfc.section.4.7">
+<a href="#rfc.section.4.7">4.7</a>&nbsp;<a id="LSControl-Summary-upper"
href="#LSControl-Summary-upper">LS Summary Message (Upper)</a>
+</h2>
+<p id="rfc.section.4.7.p.1">This message exchange represents when an LS
instance is holding the token and sharing summary information. The message
consists of metadata/data pair(s) that contain service information and a
parameter indicating "size" of the data set the LS manages. The "data"
portion is the summary info (FORMAT TBD!!!)</p>
+<p id="rfc.section.4.7.p.2">The response message should indicate success or
failure via the eventType, and will contain metadata/data pair(s). The
metadata should indicate who the service is, and its "size" for leader voting
purposes. The data section is message that can be used for logging.</p>
+<p id="rfc.section.4.7.p.3">When receiving the message, check your 'lower'
list and update it as needed for: </p>
+<dl class="empty">
+<dd>Do you know of this service? If so make sure the vote and other info is
ok.</dd>
+<dd>Update the summary info in your collection</dd>
+<dd>If you don't know of them, add them!</dd>
+</dl>
+<h3 id="rfc.section.4.7.1">
+<a href="#rfc.section.4.7.1">4.7.1</a>&nbsp;<a id="LSControl-SummaryRequest"
href="#LSControl-SummaryRequest">Request</a>
+</h3>
+<p id="rfc.section.4.7.1.p.1">
+<pre>

&lt;nmwg:message type="LSControlRequest"&gt;

@@ -744,9 +1140,6 @@
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/summary/upper&lt;/nmwg:eventType&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;100&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;nmwg:data id="data.2" metadataIdRef="metadata.2"&gt;
@@ -779,7 +1172,13 @@

&lt;/nmwg:message&gt;

- </pre> </p><h3 id="rfc.section.4.7.2"><a
href="#rfc.section.4.7.2">4.7.2</a>&nbsp;<a id="LSControl-SummaryResponse"
href="#LSControl-SummaryResponse">Response</a></h3><p
id="rfc.section.4.7.2.p.1"> <pre>
+ </pre>
+</p>
+<h3 id="rfc.section.4.7.2">
+<a href="#rfc.section.4.7.2">4.7.2</a>&nbsp;<a
id="LSControl-SummaryResponse" href="#LSControl-SummaryResponse">Response</a>
+</h3>
+<p id="rfc.section.4.7.2.p.1">
+<pre>

&lt;nmwg:message type="LSControlResponse"&gt;

@@ -794,9 +1193,6 @@
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/summary/upper/success&lt;/nmwg:eventType&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;50&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;nmwg:data id="data.6" metadataIdRef="metadata.6"&gt;
@@ -805,7 +1201,18 @@

&lt;/nmwg:message&gt;

- </pre> </p><h2 id="rfc.section.4.8"><a
href="#rfc.section.4.8">4.8</a>&nbsp;<a id="LSControl-Leader"
href="#LSControl-Leader">LS Leader Message</a></h2><p
id="rfc.section.4.8.p.1">This message exchange will be conducted between the
Leader and Vice-Leader on some (frequent) interval. It may even become a part
of the Leader's token exchange with the Upper Level.</p><p
id="rfc.section.4.8.p.2">The leader identifies itself, and sends down the
summaries from the upper level for the Vice-Leader to store. If the leader
should die, the vice leader will have a summary of the upper level and be
able to continue answering lower level queries and obtaining information from
the higher levels.</p><h3 id="rfc.section.4.8.1"><a
href="#rfc.section.4.8.1">4.8.1</a>&nbsp;<a id="LSControl-LeaderRequest"
href="#LSControl-LeaderRequest">Request</a></h3><p
id="rfc.section.4.8.1.p.1"> <pre>
+ </pre>
+</p>
+<h2 id="rfc.section.4.8">
+<a href="#rfc.section.4.8">4.8</a>&nbsp;<a id="LSControl-Leader"
href="#LSControl-Leader">LS Leader Message</a>
+</h2>
+<p id="rfc.section.4.8.p.1">This message exchange will be conducted between
the Leader and Vice-Leader on some (frequent) interval. It may even become a
part of the Leader's token exchange with the Upper Level.</p>
+<p id="rfc.section.4.8.p.2">The leader identifies itself, and sends down the
summaries from the upper level for the Vice-Leader to store. If the leader
should die, the vice leader will have a summary of the upper level and be
able to continue answering lower level queries and obtaining information from
the higher levels.</p>
+<h3 id="rfc.section.4.8.1">
+<a href="#rfc.section.4.8.1">4.8.1</a>&nbsp;<a id="LSControl-LeaderRequest"
href="#LSControl-LeaderRequest">Request</a>
+</h3>
+<p id="rfc.section.4.8.1.p.1">
+<pre>

&lt;nmwg:message type="LSControlRequest"&gt;

@@ -819,9 +1226,6 @@
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/leader&lt;/nmwg:eventType&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;50&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;nmwg:data id="data.6" metadataIdRef="metadata.6"&gt;
@@ -838,9 +1242,6 @@
&lt;/psservice:service&gt;
&lt;/perfsonar:subject&gt;

&lt;nmwg:eventType&gt;http://perfsonar.net/services/LS/summary&lt;/nmwg:eventType&gt;
- &lt;nmwg:parameters&gt;
- &lt;nmwg:parameter name="contentSize"&gt;100&lt;/nmwg:parameter&gt;
- &lt;/nmwg:parameters&gt;
&lt;/nmwg:metadata&gt;

&lt;!-- then its summary --&gt;
@@ -879,7 +1280,13 @@

&lt;/nmwg:message&gt;

- </pre> </p><h3 id="rfc.section.4.8.2"><a
href="#rfc.section.4.8.2">4.8.2</a>&nbsp;<a id="LSControl-LeaderResponse"
href="#LSControl-LeaderResponse">Response</a></h3><p
id="rfc.section.4.8.2.p.1"> <pre>
+ </pre>
+</p>
+<h3 id="rfc.section.4.8.2">
+<a href="#rfc.section.4.8.2">4.8.2</a>&nbsp;<a id="LSControl-LeaderResponse"
href="#LSControl-LeaderResponse">Response</a>
+</h3>
+<p id="rfc.section.4.8.2.p.1">
+<pre>

&lt;nmwg:message type="LSControlRequest"&gt;

@@ -887,7 +1294,17 @@

&lt;/nmwg:message&gt;

- </pre> </p><h2 id="rfc.section.4.9"><a
href="#rfc.section.4.9">4.9</a>&nbsp;<a id="LSControl-Discovery"
href="#LSControl-Discovery">LS Discovery Message</a></h2><p
id="rfc.section.4.9.p.1">Structure of the LSDiscovery Message used to locate
info-sets. (FORMAT TBD!!!)</p><h3 id="rfc.section.4.9.1"><a
href="#rfc.section.4.9.1">4.9.1</a>&nbsp;<a id="LSDiscoveryRequest"
href="#LSDiscoveryRequest">Request</a></h3><p id="rfc.section.4.9.1.p.1">
<pre>
+ </pre>
+</p>
+<h2 id="rfc.section.4.9">
+<a href="#rfc.section.4.9">4.9</a>&nbsp;<a id="LSControl-Discovery"
href="#LSControl-Discovery">LS Discovery Message</a>
+</h2>
+<p id="rfc.section.4.9.p.1">Structure of the LSDiscovery Message used to
locate info-sets. (FORMAT TBD!!!)</p>
+<h3 id="rfc.section.4.9.1">
+<a href="#rfc.section.4.9.1">4.9.1</a>&nbsp;<a id="LSDiscoveryRequest"
href="#LSDiscoveryRequest">Request</a>
+</h3>
+<p id="rfc.section.4.9.1.p.1">
+<pre>

&lt;nmwg:message type="LSDiscoveryRequest"&gt;

@@ -901,7 +1318,13 @@

&lt;/nmwg:message&gt;

- </pre> </p><h3 id="rfc.section.4.9.2"><a
href="#rfc.section.4.9.2">4.9.2</a>&nbsp;<a id="LSDiscoveryResponse"
href="#LSDiscoveryResponse">Response</a></h3><p id="rfc.section.4.9.2.p.1">
<pre>
+ </pre>
+</p>
+<h3 id="rfc.section.4.9.2">
+<a href="#rfc.section.4.9.2">4.9.2</a>&nbsp;<a id="LSDiscoveryResponse"
href="#LSDiscoveryResponse">Response</a>
+</h3>
+<p id="rfc.section.4.9.2.p.1">
+<pre>

&lt;nmwg:message type="LSDiscoveryResponse"&gt;

@@ -935,16 +1358,106 @@

&lt;/nmwg:message&gt;

- </pre> </p><hr class="noprint"><h1 id="rfc.section.5" class="np"><a
href="#rfc.section.5">5.</a>&nbsp;<a id="codes" href="#codes">Result
codes</a></h1><ul><li>error.ls.foo -</li><li>success.ls.foo
-</li><li>TBD</li></ul><hr class="noprint"><h1 id="rfc.section.6"
class="np"><a href="#rfc.section.6">6.</a>&nbsp;<a id="apdx"
href="#apdx">Appendices</a></h1><h2 id="rfc.section.6.1"><a
href="#rfc.section.6.1">6.1</a>&nbsp;<a id="glossary"
href="#glossary">Glossary</a></h2><ul><li>AuthoritativeLS - LS that is an
authority for the perfSONAR services in question. AuthoritativeLS is a result
of discovery phase and can be used in the metadata query
phase.</li><li>Berkeley DB XML - Oracle Berkeley DB XML is an open source,
embeddable XML database with XQuery-based access to documents stored in
containers and indexed based on their content.</li><li>Bootstraping - It
refers to the process of automatically finding at service startup other LS
instances of the scope utilizing a previo
usly configured registry.</li><li>eXist XML DB - eXist is an Open Source
native XML database featuring efficient, index-based XQuery processing,
automatic indexing, extensions for full-text search, XUpdate support, XQuery
update extensions and tight integration with existing XML development
tools.</li><li>Home LS (HLS) - The Home LS of a Service is the LS where the
Service registers its Lookup Information</li><li>Lookup Service (LS) - The
Lookup Service is a key element of the perfSONAR framework because it allows
every independent service to be a visible part of the system. New services
may identify themselves to the community and provide their detailed
capabilities description. Other services are able to communicate to the LS in
order to get this data called Lookup Information. Basic Lookup Service
supports registration, query, keepalives and de-registration actions
(additionally updates?).</li><li>Lookup Information - information registered
by a Service in the Lookup Serv
ice</li><li>Lower Scope - The scoping paradigm meant to indi!
cate int
er-domain relationships.</li><li>LSRing - Represents the state of the LS
cloud listing available LS instances</li><li>Multidomain / Distributed Lookup
Information (mLS) - Lookup Service which supports summarization and
communication with other Lookup Services (which might be in the same
domain...)</li><li>P2P - network infrastucture that does not have fixed
clients and servers, but a number of peer nodes that function as both clients
and servers to the other nodes on the network. This model is contrasted with
the client-server model.</li><li>Service - A Service is an application that
communicates with other perfSONAR Services via standardized protocol set
(SOAP+XML+NMWGv2)</li><li>Summary Information - aggregated information from
Lookup Information that is sent by one LS to another</li><li>Token Ring - A
ring network in which the network topology features nodes connected to
exactly two other nodes, forming a circular pathway for signals: a ring. Data
travels from node to node
, with each node handling every packet. We use a logical ring in which a
"token" message is used to synchronize the communication among the
nodes.</li><li>Upper (Global) Scope - The scoping paradigm meant to indicate
intra-domain relationships.</li><li>XSLT - Extensible Stylesheet Language
Transformations is an XML-based language used for the transformation of XML
documents into other XML or "human-readable" documents. The original document
is not changed; rather, a new document is created based on the content of an
existing one.</li><li>XQuery - A query language (with some programming
language features) that is designed to query collections of XML data. It is
semantically similar to SQL.</li></ul><h1 class="np" id="rfc.references"><a
href="#rfc.section.7">7.</a> References</h1><table summary="References"
border="0" cellpadding="2"><tr><td class="topnowrap"><b
id="tridentcom">[1]</b></td><td class="top">Zurawski, J., Swany, M., and D.
Gunter, &#8220;A Scalable Framework for
Representation and Exchange of Network Measurements&#8221;, !
In Proce
edings of 2nd International IEEE/Create-Net
+ </pre>
+</p>
+<hr class="noprint">
+<h1 id="rfc.section.5" class="np">
+<a href="#rfc.section.5">5.</a>&nbsp;<a id="codes" href="#codes">Result
codes</a>
+</h1>
+<ul>
+<li>error.ls.foo -</li>
+<li>success.ls.foo -</li>
+<li>TBD</li>
+</ul>
+<hr class="noprint">
+<h1 id="rfc.section.6" class="np">
+<a href="#rfc.section.6">6.</a>&nbsp;<a id="apdx" href="#apdx">Appendices</a>
+</h1>
+<h2 id="rfc.section.6.1">
+<a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="glossary"
href="#glossary">Glossary</a>
+</h2>
+<ul>
+<li>AuthoritativeLS - LS that is an authority for the perfSONAR services in
question. AuthoritativeLS is a result of discovery phase and can be used in
the metadata query phase.</li>
+<li>Berkeley DB XML - Oracle Berkeley DB XML is an open source, embeddable
XML database with XQuery-based access to documents stored in containers and
indexed based on their content.</li>
+<li>Bootstraping - It refers to the process of automatically finding at
service startup other LS instances of the scope utilizing a previously
configured registry.</li>
+<li>eXist XML DB - eXist is an Open Source native XML database featuring
efficient, index-based XQuery processing, automatic indexing, extensions for
full-text search, XUpdate support, XQuery update extensions and tight
integration with existing XML development tools.</li>
+<li>Home LS (HLS) - The Home LS of a Service is the LS where the Service
registers its Lookup Information</li>
+<li>Lookup Service (LS) - The Lookup Service is a key element of the
perfSONAR framework because it allows every independent service to be a
visible part of the system. New services may identify themselves to the
community and provide their detailed capabilities description. Other services
are able to communicate to the LS in order to get this data called Lookup
Information. Basic Lookup Service supports registration, query, keepalives
and de-registration actions (additionally updates?).</li>
+<li>Lookup Information - information registered by a Service in the Lookup
Service</li>
+<li>Lower Scope - The scoping paradigm meant to indicate inter-domain
relationships.</li>
+<li>LSRing - Represents the state of the LS cloud listing available LS
instances</li>
+<li>Multidomain / Distributed Lookup Information (mLS) - Lookup Service
which supports summarization and communication with other Lookup Services
(which might be in the same domain...)</li>
+<li>P2P - network infrastucture that does not have fixed clients and
servers, but a number of peer nodes that function as both clients and servers
to the other nodes on the network. This model is contrasted with the
client-server model.</li>
+<li>Service - A Service is an application that communicates with other
perfSONAR Services via standardized protocol set (SOAP+XML+NMWGv2)</li>
+<li>Summary Information - aggregated information from Lookup Information
that is sent by one LS to another</li>
+<li>Token Ring - A ring network in which the network topology features nodes
connected to exactly two other nodes, forming a circular pathway for signals:
a ring. Data travels from node to node, with each node handling every packet.
We use a logical ring in which a "token" message is used to synchronize the
communication among the nodes.</li>
+<li>Upper (Global) Scope - The scoping paradigm meant to indicate
intra-domain relationships.</li>
+<li>XSLT - Extensible Stylesheet Language Transformations is an XML-based
language used for the transformation of XML documents into other XML or
"human-readable" documents. The original document is not changed; rather, a
new document is created based on the content of an existing one.</li>
+<li>XQuery - A query language (with some programming language features) that
is designed to query collections of XML data. It is semantically similar to
SQL.</li>
+</ul>
+<h1 class="np" id="rfc.references">
+<a href="#rfc.section.7">7.</a> References</h1>
+<table summary="References" border="0" cellpadding="2">
+<tr>
+<td class="topnowrap">
+<b id="tridentcom">[1]</b>
+</td>
+<td class="top">Zurawski, J., Swany, M., and D. Gunter, &#8220;A Scalable
Framework for Representation and Exchange of Network Measurements&#8221;, In
Proceedings of 2nd International IEEE/Create-Net
Conference on Testbeds and Research Infrastructures
for the Development of Networks and Communities
- (Tridentcom 2006).</td></tr></table><hr
class="noprint"><h1 id="rfc.authors" class="np">Authors'
Addresses</h1><address class="vcard"><span class="vcardline"><span
class="fn">Jeff Boote</span><span class="n hidden"><span
class="family-name">Boote</span><span
class="given-name">Jeff</span></span></span><span class="org
vcardline">Internet2
+ (Tridentcom 2006).</td>
+</tr>
+</table>
+<hr class="noprint">
+<h1 id="rfc.authors" class="np">Authors' Addresses</h1>
+<address class="vcard">
+<span class="vcardline">
+<span class="fn">Jeff Boote</span>
+<span class="n hidden">
+<span class="family-name">Boote</span>
+<span class="given-name">Jeff</span>
+</span>
+</span>
+<span class="org vcardline">Internet2
1000 Oakbrook Drive Suite 300
- Ann Arbor MI 48104
</span></address><address class="vcard"><span class="vcardline"><span
class="fn">Maciej Glowiak</span><span class="n hidden"><span
class="family-name">Glowiak</span><span
class="given-name">Maciej</span></span></span><span class="org
vcardline">Poznan Supercomputing and Networking Center
+ Ann Arbor MI 48104 </span>
+</address>
+<address class="vcard">
+<span class="vcardline">
+<span class="fn">Maciej Glowiak</span>
+<span class="n hidden">
+<span class="family-name">Glowiak</span>
+<span class="given-name">Maciej</span>
+</span>
+</span>
+<span class="org vcardline">Poznan Supercomputing and Networking Center
ul. Noskowskiego 10
61-704 Poznan
- Poland</span></address><address
class="vcard"><span class="vcardline"><span class="fn">D. Martin
Swany</span><span class="n hidden"><span
class="family-name">Swany</span><span class="given-name">D.
Martin</span></span></span><span class="org vcardline">University of Delaware
+ Poland</span>
+</address>
+<address class="vcard">
+<span class="vcardline">
+<span class="fn">D. Martin Swany</span>
+<span class="n hidden">
+<span class="family-name">Swany</span>
+<span class="given-name">D. Martin</span>
+</span>
+</span>
+<span class="org vcardline">University of Delaware
Department of Computer and
Information Sciences
- Newark, DE
19716</span></address><address class="vcard"><span class="vcardline"><span
class="fn">Jason Zurawski</span><span class="n hidden"><span
class="family-name">Zurawski</span><span
class="given-name">Jason</span></span></span><span class="org
vcardline">Internet2
+ Newark, DE 19716</span>
+</address>
+<address class="vcard">
+<span class="vcardline">
+<span class="fn">Jason Zurawski</span>
+<span class="n hidden">
+<span class="family-name">Zurawski</span>
+<span class="given-name">Jason</span>
+</span>
+</span>
+<span class="org vcardline">Internet2
1000 Oakbrook Drive Suite 300
- Ann Arbor MI 48104
</span></address></body></html>
\ No newline at end of file
+ Ann Arbor MI 48104 </span>
+</address>
+</body>
+</html

Modified: trunk/nmwg/doc/dLS/dLS.pdf
===================================================================
(Binary files differ)

Modified: trunk/nmwg/doc/dLS/dLS.xml
===================================================================
--- trunk/nmwg/doc/dLS/dLS.xml 2007-11-14 09:31:41 UTC (rev 296)
+++ trunk/nmwg/doc/dLS/dLS.xml 2007-11-27 03:21:22 UTC (rev 297)
@@ -76,7 +76,8 @@
There are a few key facets of this mode of operation:
</t>

- <t><list style="symbols">
+ <t>
+ <list style="symbols">
<t>Summarization - to reduce the amount of information sent over the

network or to anonymize sensitive data, some form of data
reduction
@@ -89,7 +90,8 @@
distributed location and search is handled is the crux of this
service.
</t>
- </list></t>
+ </list>
+ </t>

<t>
Additionally we present solutions to issues necessary to allow
effective
@@ -97,6 +99,8 @@
other parts of the system) and domain-specific concerns.
</t>
</section>
+
+
<section anchor="system" title="System Specific Operation">
<!-- Overivew Section -->
<section anchor="overview" title="Overview">
@@ -121,20 +125,63 @@
rapidly changes, like the most recent data's timestamp and
full details of data stored in long-term archival MAs.
</t>
+
<t>The architecture of the dLS protocol assumes the existence of logical
- rings of LS instances. The architecture should allow for
multiple levels.
- The current proposal involves two levels of rings:
- lower scope and upper scope. Lower scope hides inter-domain
relationships
- between LS instances while upper scope hides intra-domain
relationships.
- <!--XXX global/local -->
- <!--The initial deployment utilizes two levels of rings:
- local scope and global scope. Local scope hides
inter-domain relationships
- between LS instances while global scope hides intra-domain
relationships.
- this might be turned around to say that local concerns local and
- global concerns global-->
- </t>
-
- </section>
+ rings of LS instances. The architecture should allow for
multiple
+ levels of these rings representing multiple splits in a
hierarchy,
+ although the basic example that will be an ongoing theme
in this document
+ will revolve around only 2 levels. The authors realize it
is impossible
+ to predict how the hierarchy of this service may split
over time,
+ therefore we avoid using language that directly
categorizes a ring into
+ a specific role. In general the two rings that define
scope are
+ 'lower' and 'upper'.
+ </t>
+
+ <t>
+ To better define this classification consider an example
at a high
+ level: inter-domain communication. It is natural to
assume that single
+ domain will deploy an LS instance to manage deployed
services. The true
+ goal of perfSONAR is to ease the detection of end to end
performance
+ issues particularly across domain boundaries, therefore
communication
+ between domain LS instances is paramount. We assume for
this example
+ that the 'top' most level is that of the domain; further
fragmentation
+ by other factors such as the 'top-level domain' or
geographical
+ considerations are probable, just not of interest in this
work. A
+ single domain may have multiple LS deployments; a
representative
+ 'leader' from this set will represent the 'upper'
(intra-domain) scope
+ and communicate with similar LS instances of other domains
in this case.
+ The actual registered services of the LS represent the
'lower' (local,
+ or in many cases inter-domain) scope.
+ </t>
+
+ <t>
+ The scoping designations are important to the next stage: data
reduction.
+ We observe that the abundance of information available via the
original
+ metadata description is rather obtuse when it comes to answering
a
+ simple (and common) query such as 'give me bandwidth data for
host x'.
+ Although information such as capacity or interface name is
valuable internal
+ to a domain, it does not serve much purpose to NOC staff simply
asking to
+ see utilization of a link. We propose a 'summarization'
strategy based
+ on 'distance' from the source that will distill the complete
metadata into
+ smaller and smaller sets as the information is passed through
the scope
+ hierarchy.
+ </t>
+
+ <t>
+ Finally, using the scoping and summarizing steps we come to
final, and
+ arguably most important phase: search. Search must rely on two
phases
+ to work efficiently in the dLS framework, namely discovery and
query.
+ The first step is locating 'where' information can be found.
This
+ involves asking semi direct questions regarding the well defined
network
+ topology in order to locate the 'vicinity' of data. The query
phase will
+ then ask more esoteric questions once it locates the proper LS
instances
+ to ask. The discovery phase is made possible through the
process of
+ summarization, while the query phase remains similar to the
current LS
+ functionality.
+ </t>
+
+
+ </section>

<!-- Summarization Section -->
<section anchor="summary" title="Summarization">
@@ -152,39 +199,51 @@
for easy creation and exchange but also must retain enough
information to provide a rich query interface able to locate the
distributed information. That means service metadata information
- must be reduced (summarized) as it propagates through the LS
cloud. We start by making an
+ must be reduced (summarized) as it propagates through the LS
cloud.
+ </t>
+
+ <t>
+ We start by making an
observation that summarization is best based on scope (see also
<xref target="scope" /> for forming scope). Simply put, this
means that we should attempt to summarize "more" the "farther"
away from the
source that we get. This creates a smaller data set that travels
the farthest away while keeping the larger and more informative
data
sets closer to the source. We present the strategies as such:
-
+ </t>
+ <t>
<list style="symbols">
- <!-- XXX local/global -->
- <t>Summarization for the "lower scope" (formerly known as
- "local scope")</t>
- <t>Summarization for the "upper scope" (formerly known as
- "global scope")</t>
- </list>
-
- We limit much of the discussion in this document to two scopes,
although
- an arbitrary number of scopes is possible without extension to the
- model. As the number of scopes
- increases additional "aggregation" will be necessary to combine
- information thus reducing the size of the data sets further.
- <!-- XXX might mention sub-domain scopes here -->
+ <t>Summarization for the "lower scope" - we must examine
+ services that we are directly responsible for and distill
this
+ information into a compact and manageable form.
+ </t>
+ <t>Summarization for the "upper scope" of an LS - Aggregation
of
+ summaries from peers plus additional summary steps will
yield a
+ concise (yet still compact) data set. Potentially we
+ will need to consider summaries from lower scopes and
aggregate
+ these into the information set.
+ </t>
+ </list>
</t>
+
+ <t>
+ We will limit our discussions to the previously discussed
inter-domain
+ example, thus involving only two scope rings. Building upon the
+ basic ideas presented here, extension to multiple scopes will be
+ be presented in future work.
+
+ </t>
+
<section anchor="lower_scope_summarization" title="Lower Scope
Summarization">
<t>
- This first level of summarization, between HLS instances
internal
- to a domain, consists of simply eliding detailed information
- from the metadata descriptions provided by registered services.

- For now we define this to be simply removing additional
"parameter"
- elements from the metadata. Special consideration must be
given to
- the "supportedEventType" parameter by simply converting this to
- actual eventType elements. This will ensure interoperability
with
- legacy services.
+ The lower scope summarization, described here as information
+ exchange between HLS instances internal to a domain, consists
of
+ simply extracting detailed information from the metadata
descriptions
+ provided by registered services. For now we define this to be
+ simply removing additional "parameter" elements from the
metadata.
+ Special consideration must be given to the "supportedEventType"
+ parameter by simply converting this to actual eventType
elements.
+ This will ensure interoperability with legacy services.
</t>
<t>
Future iterations may choose to drop additional pieces of
@@ -249,6 +308,7 @@
<postamble>The holder of the token (LS3) will inform everyone of its
summary information.</postamble>
</figure>
+
<t>Once exchanged, the details regarding storage in the XML database
backend (see <xref target="glossary" />) are also left to
individual implementations. It is understood that this
@@ -259,16 +319,18 @@
indicate whether or not it is authoritative.
</t>
</section>
+
<section anchor="upper_scope_summarization" title="Upper Scope
Summarization">
<t>
- A designated member of each lower scope will be required to
interact
- with the upper scope. The mechanics of how we learn who is the
- designated leader are discussed in <xref target="tokens" />.
The
- leader of each lower scope (and the designated backup) will be
responsible
- for examining each member's summary information and building a
- summarization/aggregation that describes the contents of a
- given scope. This summary will serve as input to the
higher-level
- scope.
+ A designated member of the aforementioned HLS organization will
be
+ required to interact with other similar LSs (possibly
representing
+ other domains) in order to form an upper scope. The mechanics
of
+ how we learn who is the designated leader are discussed in
+ <xref target="tokens" />. The leader from each of the first
layers
+ of this hierarchy (and the designated backup) will be
responsible for
+ examining each member's summary information and building a
+ summarization/aggregation that describes the contents of the
various
+ LS instances. This summary will serve as input to the upper
scope.
</t>
<t>
The most natural summarization is based on the topology of the
@@ -299,6 +361,7 @@
strive to preserve as much information as possible to remain
useful during the search procedures.
</t>
+
<section anchor="IP-summary" title="IP addresses summarization
algorithm">
<t>
To properly summarize a list of strings such as IP addresses we
@@ -322,7 +385,8 @@
strings (one of the features that leads to efficiency for
small
data sets). The algorithm should support the following basic
operations:
-
+ </t>
+ <t>
<list style="symbols">
<t>Lookup: Indicate that something is or is not contained in
the tree.</t>
@@ -339,6 +403,7 @@
child and merging the edges.</t>
</list>
</t>
+
<t>
Once constructed, it is possible to consult the structure in
creating IP network summaries.
@@ -346,17 +411,20 @@
</section>
</section>
</section>
+
+
<!-- Scope Section -->
<section anchor="scope" title="Scope Forming">
- <t>The next question is how to form the lower and upper scopes. The
- simplest answer is that the lower scope be formed based on the
domain
- name of the participating systems. That would allow e.g.
- internet2.edu, geant2.net, and pionier.gov.pl to potentially
operate more
- than one LS instance inside their own domains (for performance and
- scalability.) As LS instances come online they will invoke
- bootstrapping procedures to find and join a lower scoped group
- first.
- </t>
+ <t>The next question is how to form the hierarchy of LS instances and
+ subsequently organize the 'scopes'. The simplest answer is that the
+ highest scope be formed based on the domain name of the participating
+ systems as mentioned in the previous examples. That would allow e.g.
+ internet2.edu, geant2.net, and pionier.gov.pl to potentially operate
more
+ than one LS instance inside their own domains (for performance and
+ scalability.) As LS instances come online they will invoke
+ bootstrapping procedures to find and join a lower scoped group
+ first.
+ </t>
<t>The scopes should be named based on URIs. This will allow a
domain-level scope to take the form
<eref target="http://internet2.edu";>http://internet2.edu</eref>,
@@ -371,16 +439,22 @@
<t>
The major algorithms used to form and maintain the ring structure
of
the dLS, no matter which scope we are talking about, are as
follows:
+ </t>
+ <t>
<list style="symbols">
<t>Join Procedure</t>
<t>Token Passing</t>
<t>Summarization Notification</t>
</list>
+ </t>
+ <t>
Each of these procedures is important to keeping members of the
distributed "service" functioning correctly. The algorithms will
be
- presented in the frame of the lower scope, but will be used in the
- same manner for the upper scope as well.
+ presented in the frame of HLS instances communicating in a lower
scope,
+ but will be used in the same manner for inter-domain communication
as
+ an upper scope as well.
</t>
+
<section anchor="join" title="Join Procedure">
<t>
When an LS instance comes online it will have some bootstrapping
@@ -392,17 +466,15 @@
</t>
<t>
A candidate LS will continuously search its LSRing information
and
- send an LSControl mesage to its known LS instances with a "join"
eventType
+ send an LSControl message to its known LS instances with a
"join" eventType
(see <xref target="LSControl-Join" />) until a successful
response
is seen. The LS candidate will then search through
the successful LSControlResponse to this message and update its
LSRing with
- the returned information. This can mean updating the
"contentSize"
- and "active" parameters as well as adding new LS instances.
These
- parameters are indicative of the size of each LS (i.e. how many
- services are registering with it) and "live-ness" (i.e. were we
- successful in contacting it recently). The contacted LS will
also
- update the local copy of LSRing to add the new member to its
- "available" list.
+ the returned information. This can mean updating the "active"
parameter
+ as well as adding new LS instances. This parameter is
indicative of
+ the "live-ness" (i.e. were we successful in contacting it
recently).
+ The contacted LS will also update the local copy of LSRing to
add the
+ new member to its "available" list.
</t>
<t>
After updating, the newly joined LS will broadcast another
LSControl message with
@@ -422,6 +494,7 @@
etiquette and remain silent until it is contacted with a token,
or
it has not seen one in a very long time (see <xref
target="tokens" />).
</t>
+
<section anchor="join_algorithm" title="Join Algorithm">
<t>
<figure anchor="join-example2">
@@ -449,8 +522,11 @@
the dLS cloud.</postamble>
</figure>
</t>
- <t>The algorithm for joining the ring works as follows:
+
+ <t>
+ The algorithm for joining the ring works as follows:
</t>
+
<t>
<list type="symbols">
<t>1. LS1 - Candidate sends LSControlRequest message with
@@ -481,6 +557,7 @@
this knowledge cycles away from being recognized.</t>
</list>
</t>
+
<t>6. All members of the ring process the summaries, save
the necessary information, and recognize the new peer.

Responses are sent to LS1.</t>
@@ -500,8 +577,11 @@
-->
</list>
</t>
+
</section>
+
</section>
+
<section anchor="tokens" title="Token Passing">
<t>
The "token" is an LSControlMessage (see <xref
target="LSControl-Token" />)
@@ -526,7 +606,7 @@
receive a periodic token. When an election is initiated, the
initiating host sends an election message to its
counter-clockwise neighbor and changes its state to “ELECTING”.
- It places its identifier inside the message. The ulimate goal is
+ It places its identifier inside the message. The ultimate goal is
for the host with the highest identifier to be chosen. When a
host receives an election message, it compares its identifier
with that in the message. It forwards the higher of the
@@ -545,38 +625,14 @@
they were available. In the absence of a priority, the nodes
essentially
are randomly ordered.
</t>
- <t>
- Another possibility is to use common method used in P2P systems
such as Gnutella when forming
- "ultrapeers" is to consider the size of the data that a node is
- serving. The principle, as described
- <eref
target="http://rakjar.de/gnufu/index.php/GnuFU_en#Network_model:_Change_who_calls_whom:_Ultrapeers_and_Leafs";>here</eref>,

- alludes to the fact that nodes with less content to look after
(i.e. less
- services, or services with a smaller amount of data) can spend
more
- time and effort helping the enterprise as a whole by taking on
- additional roles (such as serving as leaders). As such we will
- record the number of metadata elements that register with each LS
- and share this with our friends in the form of the "contentSize"
- parameter.
- </t>
- <t>
- Token passing is directly related to the concept of leader
- election (see <xref target="Leader_Election" />), so more
- explanation of this approach will follow. For now we are
justified
- in saying that the "contentSize" forms another good criterion
for
- "ordering" the members of the ring. With all members of the ring
- aware of everyone's data size, we can easily know who we should
- pass the token to, and receive it from at any point in time.
- We assume passing order between the LSs from smallest to
greatest
- "contentSize" (with wrap around at the ends). Of course, this
- metric leaves out the relative power of the machines in question, so
- futher modifications are possible.
- </t>
+

<t>
The key is that as long as the identifier is chosen consistently
within a
given scope, the choice of identifier doesn't affect the operation of
the
protocol.
</t>
+
<t>
The token can be viewed as "permission to talk" and permits the
holding LS to send its summary information to all other
available LS
@@ -606,12 +662,14 @@
standard value) thus calculating the expected time is not an
issue.
</t>
-->
+
<section anchor="token_passing_algorithm" title="Token Passing
Algorithm">
<!--
<section anchor="tokenpass_algorithm" title="Toking Passing
Algorithm">

<t>
-->
+
<figure anchor="join-example">
<preamble>Illustration of Token Passing Algorithm</preamble>
<artwork>
@@ -635,26 +693,30 @@
</artwork>
<postamble>LS1, LS2 and LS3 are in the ring. LS1 receives a
token.</postamble>
</figure>
+
<t>The algorithm for token passing works as follows:</t>
+
<t>
+
<list type="numbers">
<t>1. LS1 receives the token i.e. LSControlRequest message
with the http://perfsonar.net/services/LS/token/
eventType from its predecessor L3.</t>
- <t>2. LS1 updates its local peer list based on token content.</t>
+ <t>2. LS1 updates its 'lower' peer list based on token content.</t>
<t>2.x (More description needed)</t>
- <t>2.1 If token contains entry that is not present in the local
LSRing, copy this entry to local LSRing</t>
- <t>2.2 If token doesn't contains entry that is present in the local
LSRing... (to be discussed: there are two cases: new LS just joined to LS
that has got the token right now OR local LSRing contains obsolete LS entry
-- I guess we'll base on active parameter, but it's not elaborated how it
works</t>
+ <t>2.1 If token contains entry that is not present in the 'lower'
LSRing, copy this entry to 'lower' LSRing</t>
+ <t>2.2 If token doesnt contains entry that is present in the 'lower'
LSRing... (to be discussed: there are two cases: new LS just joined to LS
that has got the token right now OR local LSRing contains obsolete LS entry
-- I guess we'll base on active parameter, but it's not elaborated how it
works</t>
<t>3. LS1 sends LSControlRequest message with the
http://perfsonar.net/services/LS/summary/ eventType
to all peers in the lease (excluding itself).</t>
<t>3. LS2 receiving this message checks its collection and updates it
- if necessary with service info including "contentSize".</t>
+ if necessary with service info.</t>
<t>4. LS1 waits for some amount of time.</t>
<t>5. LS1 sends token to next LS (LS2) from the LSRing lower scope
(if it fails, try next one).</t>
</list>
</t>
+
</section>

<section anchor="rotation-time-computing" title="Token rotation time
computing">
@@ -672,21 +734,27 @@
</section>

</section>
+
<section anchor="summary-blast" title="Summarization Notification">
<t>
As discussed in the prior two sections there are two acceptable
instances to send your summary to the LSRing:
+ </t>
+
+ <t>
<list style="numbers">
<t>When first joining</t>
<t>When holding the token</t>
</list>
</t>
+
<t>
In the first case we are explicitly entering ourselves into the
ring when we get our first message from a peer. This ensures we
show up in the token rotation instantly. The second case is
the routine exchange started when a token arrives from a peer.
</t>
+
<t>
<xref target="LSControl-Summary-lower" /> and
<xref target="LSControl-Summary-upper" /> contain examples of
the
@@ -694,57 +762,20 @@
implementation when the summarization occurs (i.e. at message
send time, or also as a periodic event).
</t>
-<!--
-<t><vspace blankLines="2" />START_NOTE (Maciej 10/3/07):<vspace
blankLines="1" />
- making summarization at the message send time may increase token holding
time and
- cause time-out in next peer in the list (and re-sending token by it).
-<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" /></t>

-<t><vspace blankLines="2" />START_NOTE (Jason 10/4/07):<vspace
blankLines="1" />
-This is why I have left it as an implementation detail. In general you get
the
-token for a long time, I doubt it will take a full 5 minutes to complete this
-task.
-<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" /></t>
--->
</section>
+
+
<section anchor="Leader_Election" title="Leader election">
<t>
- The most important role of the lower scope nodes is electing a
leader
- to serve in the upper levels. This logical ring should consist
of
- one representative LS from each of the lower scopes.
- <!--
- we still have to discuss this. my laptop with 2 elements might not
- be less busy than an 8 core superbox with 10K elements. MS
- This
- representative will be selected based on the "contentSize"
- parameter, which as we have discussed previously is a count of
the
- number of metadata elements the LS is responsible for. We choose
- this parameter primarily because it imposes a very simple
ordering
- on the nodes, and allows us to choose the "least busy" node for
- performing more important work.
- -->
+ The most important role of any group of HLS instances is electing
a
+ leader to serve as a representative in upper level communication.

+ This logical ring should consist of one representative LS from
each
+ of similar lower scope configuration.
</t>
- <!-- more junk about contentSize. we need one place where the choice
- of identifier is placed and the rest of the text should not care.
+
+
<t>
- The theory behind this choice of leader is that unladen LS
instances
- will not be as loaded processing requests and responses from
clients
- and other services, thus the choice to name them as leaders is
- natural. An added feature of this criteria is that it becomes
very
- simple to designate a leader LS for a domain; simply deploy an LS
- instance that does not accept registrations. This service will
only
- serve in the role of liaison to the upper level.
- </t>
- <t>
- All LS instances will have a complete view at any given time (and
- updated over time) of the values of the "contentSize" parameter for
- all peer LS instances in an LSRing. This ensures that the "Leader"
- and "Vice-Leader" are always known. Explicit election is therefore
- not required, and succession can pass between the two executives
- quickly.
- </t>
- -->
- <t>
The Leader and Vice-Leader LS instances should exchange messages
(see <xref target="LSControl-Leader" />)
periodically to ensure that in the event of a failure the lower
@@ -753,66 +784,15 @@
from the Leader to be sure it has not failed. In the event that
it has, the "Join" procedure will start to the upper level to keep
the hierarchy complete.
- </t>
- <!--
- <t>
- <vspace blankLines="2" />START_NOTE (Maciej 10/3/07):<vspace
blankLines="1" />
- Question: I am not convinced "contentSize" should be the only criterion.
- When new LS joins the ring it may have empty database, but in some time
- it'll get a lot of metadata. The mechanism of leader election bases on
that, so
- its quite important. If such LS will "update" its "contentSize" value not
all
- other LS-es may know about it immediately (token passing cycle) and they
may
- not have the same knowledge about the leader. I"d prefer more
deterministic
- way of leader election.
-<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" />
</t>
- <t>
- <vspace blankLines="2" />START_NOTE (Jason 10/4/07):<vspace
blankLines="1" />
-I have added some more reasoning behind this, as well as a pointer to some
-literature from the Gnutella folks as to why this is a good method. I am
not in
-favor of something complex when calculating a leader; we must choose
something
-that everyone can figure out [instantly] so that the ring continues to
function
-even during times when bad things are happening. Everyone will be able to
see (at
-any given time) how much information someone has, and the notion that an
unburdened
-system should be given more work (as opposed to a system that may be very
busy with
-local queries yet chosen anyway based on separate criteria) is very
appealing.
-<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" />
- </t>
-
- I don't think that we can debate this in comments. I agree with
- Maciej. There's no way this should be the only option. Again,
- we describe the generic protocol based on an ID, and discuss, in
- one place in the doc, how to choose that ID.
--->
+

</section>

- <!-- if I'm not mistaken, this is covered elsewhere.
- <section anchor="scopes" title="Scopes">
- <t>Scopes are named based on URIs. The top-level domain provides a
- natural basis for the formation of these URIs. These URIs may be
- constructed to allow internal differentiation. In the future, we
may
- need a mechanism to provide another level of hierarchy above the
- domain level and below the root, but that is left for future work.
- Note: I would like to see this be something like:
- <eref
target="http://lsls.perfsonar.net/master/internet2.edu/";>http://lsls.perfsonar.net/master/internet2.edu/</eref>.

- Actual syntax doesn't matter that much but I would like the
- following components:
-
- <list style="numbers">
- <t>Well-known hostname to get the current root.hints from
- (lsls)</t>
- <t>A place holder for where we can break the scope between
- organization and upper levels (master)</t>
- <t>A zero-conf default name for the organization
- (internet2.edu)</t>
- <t>A way to sub-divide the organization (everything after
- trailing / )</t>
- </list>
- </t>
- </section>
- -->
+
</section>
+
+
<!-- Search Section -->
<section anchor="search" title="Search">
<t>The search operation is obviously critical to the Lookup Service's
@@ -823,6 +803,7 @@
searching is to find what eventTypes exist for a particular
topology element or set of topology elements.
</t>
+
<t>As outlined above, the full data that services register to an LS is
not expected to leave the scope of that LS. The information is
summarized before wider distribution. Therefore, a client needs to
@@ -833,6 +814,7 @@
data and summary data means the overall act of searching is broken
down into two distinct phases - Discovery and Metadata Query.

</t>
+
<section anchor="discovery" title="Discovery Phase">
<t>The discovery phase is used to locate the set of Authoritative LS
(or LSes) for a given Subject/eventType tuple. This
requires a
@@ -840,9 +822,10 @@
is not described yet, but which must consist of the 3-tuple
of
Subject Summary, eventType and Authoritative LS.) Either a
specific
API call and a pre-prepared query, or some automatic
mechanism, must
- map the desired query into a query of the Discovery infoset
(see
+ map the desired query into a query of the Discovery info-set
(see
<xref target="LSControl-Discovery" />).
</t>
+
<section anchor="discovery-alg" title="Discovery Algorithm">
<t>The discovery algorithm is as follows.</t>
<list style="numbers">
@@ -856,7 +839,7 @@
<list style="numbers">
<t>Failure: Returned if there is no LS at a higher scope
than the current one, and nothing was found in
the summary
- infoset that matches the query.</t>
+ info-set that matches the query.</t>
<t>Referral: This is returned when there is no match other
than a "global wildcard"

@@ -872,6 +855,7 @@
</t>
</list>
</t>
+
<t>Success: We define success to mean at least one matching
LS has been returned. The LS must return the
following:

@@ -893,13 +877,17 @@
</t>
</list>
</t>
+
<t>The client will need to iterate through the list of returned
LS instances. If the LS returns itself, this LS can be
used in
the following Metadata query phase. If the returned LS
is
different, a discovery query should be made to it.</t>
</list>
+
</section>
+
</section>
+
<section anchor="metadata-query" title="Metadata Query Phase">
<t>The Metadata Query Phase with an individual LS is the same as
the query mechanism that is in place with the current LS
@@ -909,10 +897,15 @@
in the range of our discovery query, we can pose Metadata
Queries
to each of them. The results will be failure or success.
</t>
+
</section>
+
</section>
+
</section>
+
<!-- Bootstrapping Section -->
+
<section anchor="bootstrapping" title="Bootstrapping">
<t>A distributed information system such as the LS needs to address
bootstrapping. In this system, an LS instance needs to find other
@@ -974,15 +967,7 @@
goes on. As such implementations must ensure that this file
is under
database control of some sort.
</t>
- <!-- here it is again
- <t>
- Each metadata description contains the usual service level info,
as
- well as a "voting" parameter (labeled as "contentSize") used to
- decide who the leader is, and a flag indicating if the current
- service thinks the remote service is active. Both of these should
- be updated frequently as reality changes.
- </t>
- -->
+
<section anchor="LSRingLower" title="LS Ring lower level">
<t>
<artwork>
@@ -1084,7 +1069,7 @@
purposes. The data section is message that can be used for
logging.
</t>
<t>
- When receiving the message, check your local list and update it as
+ When receiving the message, check your 'lower' list and update it
as
needed for:
<list type="symbols">
<t>Do you know of this service? If so make sure the vote and other
@@ -1127,7 +1112,7 @@
purposes. The data section is message that can be used for
logging.
</t>
<t>
- When receiving the message, check your local list and update it as
+ When receiving the message, check your 'lower' list and update it
as
needed for:
<list type="symbols">
<t>Do you know of this service? If so make sure the vote and other



  • nmwg: r297 - trunk/nmwg/doc/dLS, svnlog, 11/26/2007

Archive powered by MHonArc 2.6.16.

Top of Page