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

Subject: perfsonar development work

List archive

nmwg: r280 - trunk/nmwg/doc/dLS

From:
To: ,
Subject: nmwg: r280 - trunk/nmwg/doc/dLS
Date: Tue, 2 Oct 2007 10:35:03 -0400

Author: mac
Date: 2007-10-02 10:35:02 -0400 (Tue, 02 Oct 2007)
New Revision: 280

Modified:
trunk/nmwg/doc/dLS/LSToken-Join.xml
trunk/nmwg/doc/dLS/LSToken-Leader.xml
trunk/nmwg/doc/dLS/LSToken-Summary.xml
trunk/nmwg/doc/dLS/LSToken-Token.xml
trunk/nmwg/doc/dLS/dLS.html
trunk/nmwg/doc/dLS/dLS.pdf
trunk/nmwg/doc/dLS/dLS.xml
Log:
A few changes (not all, but I don't know when will have some time for next
changes, probably I'll do something tomorrow or day after)

I replaced LSToken by LSControl, it seems to be more proper (LSToken-* names
should be updated as well).
Sections describing algorithms were added. I'd expect to have detailed
algorithms of IP addresses summary, TTRT computing and so on
I added Join algorithm description. Other sub-algorithms should be described
in the same manner.

Modified: trunk/nmwg/doc/dLS/LSToken-Join.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSToken-Join.xml 2007-10-01 23:54:49 UTC (rev 279)
+++ trunk/nmwg/doc/dLS/LSToken-Join.xml 2007-10-02 14:35:02 UTC (rev 280)
@@ -16,7 +16,7 @@
This information gives the new member a snapshot of the ring.
-->

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

<nmwg:metadata id="metadata.2">
<perfsonar:subject id="subject.2">

Modified: trunk/nmwg/doc/dLS/LSToken-Leader.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSToken-Leader.xml 2007-10-01 23:54:49 UTC (rev
279)
+++ trunk/nmwg/doc/dLS/LSToken-Leader.xml 2007-10-02 14:35:02 UTC (rev
280)
@@ -11,7 +11,7 @@
higher levels.
-->

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

<nmwg:metadata id="metadata.6">
<perfsonar:subject id="subject.6">

Modified: trunk/nmwg/doc/dLS/LSToken-Summary.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSToken-Summary.xml 2007-10-01 23:54:49 UTC (rev
279)
+++ trunk/nmwg/doc/dLS/LSToken-Summary.xml 2007-10-02 14:35:02 UTC (rev
280)
@@ -26,7 +26,7 @@

-->

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

<nmwg:metadata id="metadata.2">
<perfsonar:subject id="subject.2">

Modified: trunk/nmwg/doc/dLS/LSToken-Token.xml
===================================================================
--- trunk/nmwg/doc/dLS/LSToken-Token.xml 2007-10-01 23:54:49 UTC (rev
279)
+++ trunk/nmwg/doc/dLS/LSToken-Token.xml 2007-10-02 14:35:02 UTC (rev
280)
@@ -11,7 +11,7 @@

-->

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

<nmwg:metadata id="metadata.6">
<perfsonar:subject id="subject.6">

Modified: trunk/nmwg/doc/dLS/dLS.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS.html 2007-10-01 23:54:49 UTC (rev 279)
+++ trunk/nmwg/doc/dLS/dLS.html 2007-10-02 14:35:02 UTC (rev 280)
@@ -266,7 +266,7 @@
content: "RFC ";
}
@top-right {
- content: "September 2007";
+ content: "October 2007";
}
@top-center {
content: "Distributed Lookup Service (dLS) in the perfSONAR
Framework";
@@ -309,7 +309,7 @@
<meta name="DC.Creator" content="Boote, J">
<meta name="DC.Creator" content="Zurawski, J">
<meta name="DC.Creator" content="Glowiak, M">
-<meta name="DC.Date.Issued" scheme="ISO8601" content="2007-09">
+<meta name="DC.Date.Issued" scheme="ISO8601" content="2007-10">
</head>
<body>
<table summary="header information" class="header" border="0"
cellpadding="1" cellspacing="1">
@@ -349,7 +349,7 @@
<tr>
<td class="front left">
</td>
-<td class="front right">September 2007</td>
+<td class="front right">October 2007</td>
</tr>
</table>
Distributed Lookup Service (dLS) in the perfSONAR
Framework
@@ -372,23 +372,23 @@
</div>
LS Operation
<pre>
- _____ _____
-| | Register Metadata | |
-| LS | <------------------------> | MA |
-|_____| <--------- |_____|
- | _____
- | | |
- ----------------> | TS |
- Query for Services |_____|
+ _____ __________
+| | Register/De-register | Service |
+| LS | <------------------------> | Service |
+|_____| <--------- |__________|
+ | _________________
+ | | |
+ ----------------> | Client/Service |
+ Query for Services |_________________|

</pre>
Services interacting with an LS
Figure 1
This document describes the support necessary to
extend this service to a distributed mode of operation. There are a few key
facets of this mode of operation:
<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 forms logical communication and data exchange channels.</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>
+<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 forms logical communication and data exchange channels.</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>
Additionally we present solutions to issues
related to the operation of this seemless service including bootstrapping and
domain specific concerns.
<hr class="noprint">
@@ -398,13 +398,13 @@
<h2 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1</a> <a id="summary"
href="#summary">Summarization</a>
</h2>
-The first step of information flow is when a
service registers with an LS. The service may know the name of an LS via
static configuration, or other forms of bootstrapping may occur. A service
registers a 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 4.1</a>) about stored (or gathered) data. Such a record
is called Lookup Information (see <a href="#lookup-info" title="Lookup
Information">Section 4.2</a>). The idea is to move the metadata from a
local XML data store to a specialized LS with additional searching
capabilities. While a service instance may support limited searching, this is
not required as they should be focused on storing or gathering data and leave
the lookup functionality to the LS. Possible exceptions are rapidly changing
Metadata like the most recent timestamp and
full details of data stored in long-term archival MAs.
+The first step of information flow is when a
service registers with an LS. The service may know the name of an LS via
static configuration, or other forms of bootstrapping may occur. A service
registers 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 4.1</a>) about stored (or gathered) data. Such a record
is called Lookup Information (see <a href="#lookup-info" title="Lookup
Information">Section 4.2</a>). The idea is to move the metadata from a
local XML data store to a specialized LS with additional searching
capabilities. While a service instance may support limited searching, this is
not required as they should be focused on storing or gathering data and leave
the lookup functionality to the LS. Possible exceptions are rapidly changing
Metadata like the most recent timestamp and fu
ll details of data stored in long-term archival MAs.

 
 
- START_NOTE (Jason 9/18/07): 
- Question 1) 
- END_NOTE: 
+ START_NOTE (Jason 9/18/07): 
+ Question 1) In the first level of summarization (i.e. 'local' ring)
what is being exchanged between HLS instances? Are they exchanging full
information, or summaries? Where is this info stored (i.e. seperate
collection)? If we are exchanging summaries it is natural to use a different
collection, if we are exchanging full info it doesn't seem to be necessary.
 
+ END_NOTE: 
 
 

@@ -415,48 +415,68 @@
</div>
HLS Cloud
<pre>
+
+A) Token passing
_____ _____
| | | |
-| LS | <----------------- | LS |
+| LS1 | <----------------- | LS2 |
|_____| Communicate via |_____|
| token exchange ^
- | | Broadcast Summary info to
- | _____ | all peers when holding
- | | | | the token
- |-------> | LS | ---------|
+ | |
+ | _____ |
+ | | | |
+ |-------> | LS3 | ---------|
|_____|

+B) Broadcast summary
+ _____ _____
+| | | |
+| LS1 | < > | LS2 |
+|_____| \ / |_____|
+ \ /
+ \ / Broadcast Summary info to
+ \ _____ / all peers when holding the token
+ | |
+ | LS3 |
+ |____/T\ Token
+ \_/
+
</pre>
-HLS instances communicating via token. The holder of the token will
inform everyone of summary information.
+HLS instances communicating via token (A). The holder of the token (LS3)
will inform everyone of summary information (B).
Figure 2
The most natural summarization is based on the
topology of the network (like in network routing). Thus, a given HLS will
perform topology-based summarization and will include this information as
well as eventType information to other LSs in its "lower scope" (formerly
known as "local scope"). Likewise, more aggressive summarization can take
place when the "lower scope" registers into the "upper scope" (formerly known
as "global scope"). This is analogous to the aggregation that occurs in IGPs
(lower scope) and EGPs (upper scope).
-
+Summarization will be performed using
specialized summary algorithm. Topology information such as IP addresses will
be summarized using algorithms basing on radix tree (the IP addresses
summarization algorithm is described in section <a href="#IP-summary"
title="IP addesses summarization algorithm">Section 2.1.1</a>) .
+In addition to that either Extensible Stylesheet
Language Transformation (XSLT) documents or the XQuery language may be used
for transformation eventType elements.
+
 
 
- START_NOTE (Jason 9/18/07): 
- Question 2) 
- END_NOTE: 
+ START_NOTE (Jason 9/18/07): 
+ Question 3) Are additional 'aggressive' summaries still needed? At the
upper levels it seems to be less of 'summarization' and more of an aggregate
of summaries (unless we are dropping things out). 
+ END_NOTE: 
 
 

-Summarization will be performed using either
Extensible Stylesheet Language Transformation (XSLT) documents or the XQuery
language. Each of these approaches has pros and cons. XQuery is supported by
XML databases and many people find it easier to read and understand. XSLT is
also in wide use and is available as a standalone application. The key issue
is the format of the output so it is less important which particular
mechanism is used.
-
+These documents 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. The output of this
process becomes a "service summary" that represents a breadth of the original
input. See <a href="#LSControl-Summary" title="LS Summary
Message">Section 4.6</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.
+In early discussions, we left the possibility
open for multiple types of summarization for different types of services and
data. This is still possibility. There are arguments to simplify the types of
summarizations that can occur. The first is that arbitrary summarizations
will yield arbitrary XML data, making discovery queries more difficult to
construct. Thus it seems to be sufficient to summarize over the Topology
elements in a regular fashion and simply include the eventTypes and drop the
Parameters. This will ease query construction.
+We may target cases where various
summarizations are possible, but for now summarization on the basis of
topology seems sufficient.
+A related question is that of policy. In our
discussions, we had the intuition that some domains would want to register
less information than others. One example is whether the actual IP addresses
of MPs capable of launching active measurements. These hosts, if compromised,
can pose significant denial of service threat.
+<h3 id="rfc.section.2.1.1">
+<a href="#rfc.section.2.1.1">2.1.1</a> <a id="IP-summary"
href="#IP-summary">IP addesses summarization algorithm</a>
+</h3>
+The IP addresses summarization algorithm is
based on radix tree. The idea of the algorithm is...
+
 
 
- START_NOTE (Jason 9/18/07): 
- Question 3) 
- END_NOTE: 
+ START_NOTE (Maciej 10/2/07): 
+ To be done... I'd expect detailed recipe here. 
+ END_NOTE: 
 
 

-These documents 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. The output of this
process becomes a "service summary" that represents a breadth of the original
input. See <a href="#LSToken-Summary" title="LS Summary
Message">Section 4.6</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.
-In early discussions, we left the possibility
open for multiple types of summarization for different types of services and
data. This is still possibility. There are arguments to simplify the types of
summarizations that can occur. The first is that arbitrary summarizations
will yield arbitrary XML data, making discovery queries more difficult to
construct. Thus it seems to be sufficient to summarize over the Topology
elements in a regular fashion and simply include the eventTypes and drop the
Parameters. This will ease query construction.
-We may target cases where various
summarizations are possible, but for now summarization on the basis of
topology seems sufficient.
-A related question is that of policy. In our
discussions, we had the intuition that some domains would want to register
less information than others. One example is whether the actual IP addresses
of MPs capable of launching active measurements. These hosts, if compromised,
can pose significant denial of service threat.
<h2 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2</a> <a id="scope" href="#scope">Scope</a>
</h2>
-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 poznan.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.
+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.
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>).
With the generalities of what a scope is taken
care of, we now turn our attention to central algorithms of the dLS: 
<ul>
@@ -469,14 +489,19 @@
<a href="#rfc.section.2.2.1">2.2.1</a> <a id="join" href="#join">Join
Procedure</a>
</h3>
When an LS instance comes online it will have
some bootstrapping knowledge of potential peers (both inter and intra
domain). 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.
-An LS will continuously search it's LSRing
information (see <a href="#LSRing" title="LS Ring File
Structure">Section 4.3</a>) until a successful response to an LSToken
message (with a 'join' eventType, see <a href="#LSToken-Join" title="LS
Joining Message for Joining a Ring">Section 4.4</a>) is seen. The LS
will search though the successful response 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 LS's size (i.e. how many services are
registering with it) and 'live-ness' (i.e. were we successful in contacting
it recently).
-After updating the LS will broadcast another
LSToken message (with a 'summary' eventType, see <a href="#LSToken-Summary"
title="LS Summary Message">Section 4.6</a>) to all of the 'active' LS
instances from it's LSRing. Again the responses will be parsed to get any
useful updated information. Each of the recipient LS instances will do the
same, including adding this new member to their own lists (as many of them
will not know of it's existence yet).
+An LS will continuously search it's LSRing
information (see <a href="#LSRing" title="LS Ring File
Structure">Section 4.3</a>) until a successful response to an LSControl
message (with a 'join' eventType, see <a href="#LSControl-Join" title="LS
Joining Message for Joining a Ring">Section 4.4</a>) is seen. The LS
will search though the successful response 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 LS's size (i.e. how many services are
registering with it) and 'live-ness' (i.e. were we successful in contacting
it recently).
+After updating the LS will broadcast another
LSControl message (with a 'summary' eventType, see <a
href="#LSControl-Summary" title="LS Summary Message">Section 4.6</a>) to
all of the 'active' LS instances from it's LSRing. Again the responses will
be parsed to get any useful updated information. Each of the recipient LS
instances will do the same, including adding this new member to their own
lists (as many of them will not know of it's existence yet).
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.
+<h4 id="rfc.section.2.2.1.1">
+<a href="#rfc.section.2.2.1.1">2.2.1.1</a> <a id="join_algorithm"
href="#join_algorithm">Join algorithm</a>
+</h4>
+This paragraph describes the Join procedure
for LS1. 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 2. LS2 receives join message from L1 and decides
whether to accept it or not. A security policy may occur here 3. LS1 gets the answer - success joining (result
code: http://perfsonar.net/result/success/LS/join) or failure (error
code) 4. If succcess LS1 will be waiting
for token and LS2 updates its local peer list 5. In the meantime LS2 receives Token. Then it
synchronizes peer lists - the local one and the one in token. LS2 sends local
summary to all peers from list (due to summary broadcasting algotirhm -
see...). LS2 sends Token to next peer from the l
ist (not necessarily to LS1). 6. When
there is LS1 turn it will get the Token. Then it synchronizes peer lists -
local and the one in token, sends its local summary to all peers from list
and sends Token to next peer
+
<h3 id="rfc.section.2.2.2">
<a href="#rfc.section.2.2.2">2.2.2</a> <a id="tokens"
href="#tokens">Token Passing</a>
</h3>
-The 'token' is a message (see <a
href="#LSToken-Token" title="LS Token Message">Section 4.5</a>) meant to
be passed around an LSRing to the various members in some order. We will pass
from smallest 'contentSize' to largest (with appropriate wrap around), and at
any given time an LS instance will know where the next token message should
go.
-The token can be viewed as 'permission to
talk' and permits the holder to send it's summary information to all
available LS instances (see <a href="#LSToken-Summary" title="LS Summary
Message">Section 4.6</a>). The responses will be parsed to get any
useful updated information.
+The 'token' is a message (see <a
href="#LSControl-Token" title="LS Token Message">Section 4.5</a>) meant
to be passed around an LSRing to the various members in some order. We will
pass from smallest 'contentSize' to largest (with appropriate wrap around),
and at any given time an LS instance will know where the next token message
should go.
+The token can be viewed as 'permission to
talk' and permits the holder to send it's summary information to all
available LS instances (see <a href="#LSControl-Summary" title="LS Summary
Message">Section 4.6</a>). The responses will be parsed to get any
useful updated information.
The holder of the token, after completing
summarization, will wait some pre-determined amount of time before sending
the token to the next LS instance. LS instances should be sensitive (although
not overly sensitive) to the progression of the token through the ring. A
token should expect to arrive in some interval equal to the size of the ring
times the waiting interval, with tolerance above and below this value.
If the token has been 'dropped' along its path
the next LS in line will detect this and re-send it to not break the
communication chain. If for some reason a second token appears too quickly
after the previous token, any LS instance should see this dispose of the
duplicate message.
<h3 id="rfc.section.2.2.3">
@@ -489,28 +514,32 @@
</ol>
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 the next cycle. The second case is
the routine exchange started when a token arrives from a peer.

-<a href="#LSToken-Summary" title="LS Summary Message">Section 4.6</a>
contains 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).
+<a href="#LSControl-Summary" title="LS Summary Message">Section 4.6</a>
contains 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).
Building on the previous algorithms, we turn our
attention to the upper scope. This logical ring should consist of one
representative from each of the lower scopes. 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.
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. This also allows a domain to impose leadership on a specific LS by
having it not accept registrations for example, and only serving in the
leader role.
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.
-The Leader and Vice-Leader LS instances should
exchange messages periodically to ensure that in the event of a failure the
lower level will still have a link to the upper level (see <a
href="#LSToken-Leader" title="LS Leader Message">Section 4.7</a>). 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.
-The timeout mechanism(s) will need to be further
specified. It can be computed as a function of the number of nodes in the
ring. This is the Target Token Rotation Time (TTRT). There may be a future
point at which we need to think about ring splitting, but we believe that
this can be managed by further scope levels.
-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: <a
href="http://lsls.perfsonar.net/master/internet2.edu/";>http://lsls.perfsonar.net/master/internet2.edu/</a>.
Actual syntax doesn’t matter that much but I would like the following
components: 
+The Leader and Vice-Leader LS instances should
exchange messages periodically to ensure that in the event of a failure the
lower level will still have a link to the upper level (see <a
href="#LSControl-Leader" title="LS Leader Message">Section 4.7</a>). 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.
+The timeout mechanism(s) will need to be further
specified. It can be computed as a function of the number of nodes in the
ring. This is the Target Token Rotation Time (TTRT), for details see section:
<a href="#TTRT" title="TTRT computing algorithm">Section 2.2.4</a>TTRT
computing. There may be a future point at which we need to think about ring
splitting, but we believe that this can be managed by further scope
levels.
+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: <a
href="http://lsls.perfsonar.net/master/internet2.edu/";>http://lsls.perfsonar.net/master/internet2.edu/</a>.
Actual syntax doesn't matter that much but I would like the following
components: 
<ol>
<li>well-known hostname to get the current root.hints from (lsls)</li>
<li>a place holder for where we can break the scope between organization and
upper levels (master)</li>
<li>a zero-conf default name for the organization (internet2.edu)</li>
<li>A way to sub-divide the organization (everything after trailing / )</li>
</ol>
+<h3 id="rfc.section.2.2.4">
+<a href="#rfc.section.2.2.4">2.2.4</a> <a id="TTRT" href="#TTRT">TTRT
computing algorithm</a>
+</h3>
+TBD.
<h2 id="rfc.section.2.3">
<a href="#rfc.section.2.3">2.3</a> <a id="search"
href="#search">Search</a>
</h2>

 
 
- START_NOTE (Jason 9/18/07): 
- Question 4) 
- END_NOTE: 
+ START_NOTE (Jason 9/18/07): 
+ Question 4) I think we should go with one algorithm here, and
'improvements' to the protocol in the future can give us two. Can we just
pick iterative and only explain that? 
+ END_NOTE: 
 
 

@@ -519,7 +548,7 @@
<h3 id="rfc.section.2.3.1">
<a href="#rfc.section.2.3.1">2.3.1</a> <a id="discovery"
href="#discovery">Discovery Phase</a>
</h3>
-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="#LSToken-Discovery"
title="LS Discovery Message">Section 4.8</a>).
+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 4.8</a>).
<h4 id="rfc.section.2.3.1.1">
<a href="#rfc.section.2.3.1.1">2.3.1.1</a> <a id="discovery-alg"
href="#discovery-alg">Discovery Algorithm</a>
</h4>
@@ -529,7 +558,7 @@
<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 Metadata
registered to an LS in another scope (domain) is found.</li>
+<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">
@@ -566,15 +595,15 @@

<pre>

-<nmwg:metadata id="metadata.17155427" 
-
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
- <netutil:subject id="subject.17062918" 
-
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">
- <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
+<nmwg:metadata id="metadata.17155427"
+ xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+ <netutil:subject id="subject.17062918"
+
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">
+ <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
<nmwgt:hostName>Gallup's.fr</nmwgt:hostName>
<nmwgt:ifName>ge-1/1/0</nmwgt:ifName>
<nmwgt:ifDescription>Gallup's description:
ge-1/1/0</nmwgt:ifDescription>
- <nmwgt:ifAddress
type="ipv4">229.148.7.224</nmwgt:ifAddress>
+ <nmwgt:ifAddress
type="ipv4">229.148.7.224</nmwgt:ifAddress>
<nmwgt:direction>in</nmwgt:direction>
<nmwgt:capacity>250000000</nmwgt:capacity>
</nmwgt:interface>
@@ -582,15 +611,15 @@

<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
</nmwg:metadata>

-<nmwg:metadata id="metadata.171558" 
-
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
- <netutil:subject id="subject.17062919" 
-
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">
- <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
+<nmwg:metadata id="metadata.171558"
+ xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+ <netutil:subject id="subject.17062919"
+
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">
+ <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
<nmwgt:hostName>Gallup's.fr</nmwgt:hostName>
<nmwgt:ifName>ge-1/1/0</nmwgt:ifName>
<nmwgt:ifDescription>Gallup's description:
ge-1/1/0</nmwgt:ifDescription>
- <nmwgt:ifAddress
type="ipv4">229.148.7.224</nmwgt:ifAddress>
+ <nmwgt:ifAddress
type="ipv4">229.148.7.224</nmwgt:ifAddress>
<nmwgt:direction>out</nmwgt:direction>
<nmwgt:capacity>250000000</nmwgt:capacity>
</nmwgt:interface>
@@ -607,9 +636,9 @@

<pre>

-<nmwg:metadata
id="http://shower.fr:8080/axis/services/MeasurementArchiveService">
- <perfsonar:subject id="subject.15977808">
- <psservice:service
id="229.148.249.60.16283379">
+<nmwg:metadata
id="http://shower.fr:8080/axis/services/MeasurementArchiveService">
+ <perfsonar:subject id="subject.15977808">
+ <psservice:service id="229.148.249.60.16283379">
<psservice:serviceName>Java RRD MA</psservice:serviceName>

<psservice:accessPoint>http://shower.fr:8080/axis/services/MeasurementArchiveService</psservice:accessPoint>
<psservice:serviceType>MA</psservice:serviceType>
@@ -618,17 +647,17 @@
</perfsonar:subject>
</nmwg:metadata>

-<nmwg:data
id="http://shower.fr:8080/axis/services/MeasurementArchiveService/1177595435/0";

-
metadataIdRef="http://shower.fr:8080/axis/services/MeasurementArchiveService">
- <nmwg:metadata id="metadata.17155427" 
-
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
- <netutil:subject id="subject.17062918" 
-
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">
- <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
+<nmwg:data
id="http://shower.fr:8080/axis/services/MeasurementArchiveService/1177595435/0";

+
metadataIdRef="http://shower.fr:8080/axis/services/MeasurementArchiveService">
+ <nmwg:metadata id="metadata.17155427"
+ xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+ <netutil:subject id="subject.17062918"
+
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">
+ <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
<nmwgt:hostName>Gallup's.fr</nmwgt:hostName>
<nmwgt:ifName>ge-1/1/0</nmwgt:ifName>
<nmwgt:ifDescription>Gallup's description:
ge-1/1/0</nmwgt:ifDescription>
- <nmwgt:ifAddress
type="ipv4">229.148.7.224</nmwgt:ifAddress>
+ <nmwgt:ifAddress
type="ipv4">229.148.7.224</nmwgt:ifAddress>
<nmwgt:direction>in</nmwgt:direction>
<nmwgt:capacity>250000000</nmwgt:capacity>
</nmwgt:interface>
@@ -637,17 +666,17 @@
</nmwg:metadata>
</nmwg:data>

-<nmwg:data
id="http://shower.fr:8080/axis/services/MeasurementArchiveService/1177595435/1";

-
metadataIdRef="http://shower.fr:8080/axis/services/MeasurementArchiveService">
- <nmwg:metadata id="metadata.171558" 
-
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
- <netutil:subject id="subject.17062919" 
-
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">
- <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
+<nmwg:data
id="http://shower.fr:8080/axis/services/MeasurementArchiveService/1177595435/1";

+
metadataIdRef="http://shower.fr:8080/axis/services/MeasurementArchiveService">
+ <nmwg:metadata id="metadata.171558"
+ xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+ <netutil:subject id="subject.17062919"
+
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/">
+ <nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
<nmwgt:hostName>Gallup's.fr</nmwgt:hostName>
<nmwgt:ifName>ge-1/1/0</nmwgt:ifName>
<nmwgt:ifDescription>Gallup's description:
ge-1/1/0</nmwgt:ifDescription>
- <nmwgt:ifAddress
type="ipv4">229.148.7.224</nmwgt:ifAddress>
+ <nmwgt:ifAddress
type="ipv4">229.148.7.224</nmwgt:ifAddress>
<nmwgt:direction>out</nmwgt:direction>
<nmwgt:capacity>250000000</nmwgt:capacity>
</nmwgt:interface>
@@ -680,13 +709,13 @@

-->

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



- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
<psservice:serviceName>Internet2 LS
#2</psservice:serviceName>

<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
<psservice:serviceType>LS</psservice:serviceType>
@@ -694,14 +723,14 @@
</psservice:service>
</perfsonar:subject>
<nmwg:parameters>
- <nmwg:parameter
name="active">0</nmwg:parameter> 
- <nmwg:parameter
name="contentSize">100</nmwg:parameter>
+ <nmwg:parameter name="active">0</nmwg:parameter>
+ <nmwg:parameter name="contentSize">100</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
+ <nmwg:metadata id="metadata.6">
+ <perfsonar:subject id="subject.6">
+ <psservice:service id="service.6">
<psservice:serviceName>Internet2 LS
#6</psservice:serviceName>

<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
<psservice:serviceType>LS</psservice:serviceType>
@@ -710,14 +739,14 @@
</perfsonar:subject>

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

- <nmwg:metadata id="metadata.1">
- <perfsonar:subject id="subject.1">
- <psservice:service id="service.1">
+ <nmwg:metadata id="metadata.1">
+ <perfsonar:subject id="subject.1">
+ <psservice:service id="service.1">
<psservice:serviceName>Internet2 LS
#1</psservice:serviceName>

<psservice:accessPoint>http://patdev0.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
<psservice:serviceType>LS</psservice:serviceType>
@@ -725,14 +754,14 @@
</psservice:service>
</perfsonar:subject>
<nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter> 
- <nmwg:parameter
name="contentSize">0</nmwg:parameter>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="contentSize">0</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

- <nmwg:metadata id="metadata.9">
- <perfsonar:subject id="subject.9">
- <psservice:service id="service.9">
+ <nmwg:metadata id="metadata.9">
+ <perfsonar:subject id="subject.9">
+ <psservice:service id="service.9">
<psservice:serviceName>Internet2 LS
#9</psservice:serviceName>

<psservice:accessPoint>http://thunderbird.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
<psservice:serviceType>LS</psservice:serviceType>
@@ -740,8 +769,8 @@
</psservice:service>
</perfsonar:subject>
<nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter> 
- <nmwg:parameter
name="contentSize">200</nmwg:parameter>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="contentSize">200</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -753,13 +782,13 @@

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



- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
+ <nmwg:metadata id="metadata.2">
+ <perfsonar:subject id="subject.2">
+ <psservice:service id="service.2">
<psservice:serviceName>ESnet LS
#2</psservice:serviceName>

<psservice:accessPoint>http://mea1.es.net:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
<psservice:serviceType>LS</psservice:serviceType>
@@ -767,14 +796,14 @@
</psservice:service>
</perfsonar:subject>
<nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter> 
- <nmwg:parameter
name="contentSize">1000</nmwg:parameter>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="contentSize">1000</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

- <nmwg:metadata id="metadata.1">
- <perfsonar:subject id="subject.1">
- <psservice:service id="service.1">
+ <nmwg:metadata id="metadata.1">
+ <perfsonar:subject id="subject.1">
+ <psservice:service id="service.1">
<psservice:serviceName>Geant LS
#1</psservice:serviceName>

<psservice:accessPoint>http://ls.perfsonar.pionier.net.pl:8080/XML-LS-1.1.1/services/LookupService</psservice:accessPoint>
<psservice:serviceType>LS</psservice:serviceType>
@@ -782,8 +811,8 @@
</psservice:service>
</perfsonar:subject>
<nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter> 
- <nmwg:parameter
name="contentSize">500</nmwg:parameter>
+ <nmwg:parameter name="active">1</nmwg:parameter>
+ <nmwg:parameter name="contentSize">500</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>

@@ -793,403 +822,47 @@
</pre>

<h2 id="rfc.section.4.4">
-<a href="#rfc.section.4.4">4.4</a> <a id="LSToken-Join"
href="#LSToken-Join">LS Joining Message for Joining a Ring</a>
+<a href="#rfc.section.4.4">4.4</a> <a id="LSControl-Join"
href="#LSControl-Join">LS Joining Message for Joining a Ring</a>
</h2>
-Structure of the LSToken messages focused on
joining a ring.
+Structure of the LSControl messages focused on
joining a ring.

<pre>

-
-
-<nmwg:message type="LSTokenRequest">
-
- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/join</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter
name="contentSize">100</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- <nmwg:data id="data.2" metadataIdRef="metadata.2"
/>
-
-</nmwg:message>
-
-
-
-<nmwg:message type="LSTokenResponse">
-
- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/join/success</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter
name="contentSize">50</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- <nmwg:data id="data.6"
metadataIdRef="metadata.6">
- <nmwg:metadata id="metadata.1">
- <perfsonar:subject id="subject.1">
- <psservice:service id="service.1">
- <psservice:serviceName>Internet2 LS
#1</psservice:serviceName>
-
<psservice:accessPoint>http://patdev0.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="contentSize">0</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- <nmwg:metadata id="metadata.9">
- <perfsonar:subject id="subject.9">
- <psservice:service id="service.9">
- <psservice:serviceName>Internet2 LS
#9</psservice:serviceName>
-
<psservice:accessPoint>http://thunderbird.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="contentSize">200</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
- </nmwg:data>
-
-</nmwg:message>

</pre>

<h2 id="rfc.section.4.5">
-<a href="#rfc.section.4.5">4.5</a> <a id="LSToken-Token"
href="#LSToken-Token">LS Token Message</a>
+<a href="#rfc.section.4.5">4.5</a> <a id="LSControl-Token"
href="#LSControl-Token">LS Token Message</a>
</h2>
-Structure of the LSToken messages serving as the
passable 'token'.
+Structure of the LSControl messages serving as
the passable 'token'.

<pre>

-
-
-<nmwg:message type="LSTokenRequest">
-
- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/token/lower</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter
name="contentSize">50</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- <nmwg:data id="data.6"
metadataIdRef="metadata.6">
-
- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
- <nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter> 
- <nmwg:parameter
name="contentSize">100</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- <nmwg:metadata id="metadata.1">
- 
- </nmwg:metadata>
-
- <nmwg:metadata id="metadata.9">
- 
- </nmwg:metadata>
-
- </nmwg:data>
-
-</nmwg:message>
-
-
-<nmwg:message type="LSTokenResponse">
-
- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/token/lower/success</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter
name="active">1</nmwg:parameter> 
- <nmwg:parameter
name="contentSize">100</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- <nmwg:data id="data.2"
metadataIdRef="metadata.2">
- <nmwgr:datum value="some sort of
message?">
- </nmwg:data>
-
-</nmwg:message>

</pre>

<h2 id="rfc.section.4.6">
-<a href="#rfc.section.4.6">4.6</a> <a id="LSToken-Summary"
href="#LSToken-Summary">LS Summary Message</a>
+<a href="#rfc.section.4.6">4.6</a> <a id="LSControl-Summary"
href="#LSControl-Summary">LS Summary Message</a>
</h2>
-Structure of the LSToken messages focused on
exchanging summary information.
+Structure of the LSControl messages focused on
exchanging summary information.

<pre>

-
-
-<nmwg:message type="LSTokenRequest">
-
- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>Internet2 LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://packrat.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/summary</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter
name="contentSize">100</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- <nmwg:data id="data.2"
metadataIdRef="metadata.2">
- <nmwg:metadata>
- <summary:subject
xmlns:summary="http://ggf.org/ns/nmwg/summary/2.0/">
- <nmtl3:network>
- <nmtl3:subnet>128.4.10.0</nmtl3:subnet>
- <nmtl3:netmask>255.255.255.0</nmtl3:netmask>
- <nmtl3:asn>666</nmtl3:asn>
- </nmtl3:network>
- </summary:subject>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- </nmwg:metadata>
-
- <nmwg:metadata>
- <nmtopo:subject>
- <nmtopo:node>
- <nmtopo:location>
- <nmtopo:country>USA</nmtopo:country>
- </nmtopo:location>
- </nmtopo:node>
- </nmtopo:subject>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- </nmwg:metadata>
- </nmwg:data>
-
-</nmwg:message>
-
-
-
-<nmwg:message type="LSTokenResponse">
-
- 
- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/summary/success</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter
name="contentSize">50</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- <nmwg:data id="data.6"
metadataIdRef="metadata.6">
- <nmwgr:datum value="some sort of
message?">
- </nmwg:data>
-
-</nmwg:message>

</pre>

<h2 id="rfc.section.4.7">
-<a href="#rfc.section.4.7">4.7</a> <a id="LSToken-Leader"
href="#LSToken-Leader">LS Leader Message</a>
+<a href="#rfc.section.4.7">4.7</a> <a id="LSControl-Leader"
href="#LSControl-Leader">LS Leader Message</a>
</h2>
-Structure of the LSToken messages dealing with
when a Leader needs to inform the Vice-Leader of the summaries from above.
+Structure of the LSControl messages dealing with
when a Leader needs to inform the Vice-Leader of the summaries from above.

<pre>

-
-
-<nmwg:message type="LSTokenRequest">
-
- <nmwg:metadata id="metadata.6">
- <perfsonar:subject id="subject.6">
- <psservice:service id="service.6">
- <psservice:serviceName>Internet2 LS
#6</psservice:serviceName>
-
<psservice:accessPoint>http://mead.internet2.edu:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/leader</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter
name="contentSize">50</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- <nmwg:data id="data.6"
metadataIdRef="metadata.6">
-
- 
-
- <nmwg:metadata id="metadata.2">
- <perfsonar:subject id="subject.2">
- <psservice:service id="service.2">
- <psservice:serviceName>ESnet LS
#2</psservice:serviceName>
-
<psservice:accessPoint>http://mea1.es.net:8080/perfSONAR_PS/services/LS</psservice:accessPoint>
- <psservice:serviceType>LS</psservice:serviceType>
-
<psservice:serviceDescription>...</psservice:serviceDescription>
- </psservice:service>
- </perfsonar:subject>
-
<nmwg:eventType>http://perfsonar.net/services/LS/summary</nmwg:eventType>
- <nmwg:parameters>
- <nmwg:parameter
name="contentSize">100</nmwg:parameter>
- </nmwg:parameters>
- </nmwg:metadata>
-
- 
-
- <nmwg:data id="data.2"
metadataIdRef="metadata.2">
- <nmwg:metadata>
- <summary:subject
xmlns:summary="http://ggf.org/ns/nmwg/summary/2.0/">
- <nmtl3:network>
- <nmtl3:subnet>128.4.10.0</nmtl3:subnet>
- <nmtl3:netmask>255.255.255.0</nmtl3:netmask>
- <nmtl3:asn>666</nmtl3:asn>
- </nmtl3:network>
- </summary:subject>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- </nmwg:metadata>
-
- <nmwg:metadata>
- <nmtopo:subject>
- <nmtopo:node>
- <nmtopo:location>
- <nmtopo:country>USA</nmtopo:country>
- </nmtopo:location>
- </nmtopo:node>
- </nmtopo:subject>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/tools/snmp/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType>
-
<nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/errors/2.0</nmwg:eventType>
- </nmwg:metadata>
- </nmwg:data>
-
- 
-
- </nmwg:data>
-
-</nmwg:message>

</pre>

<h2 id="rfc.section.4.8">
-<a href="#rfc.section.4.8">4.8</a> <a id="LSToken-Discovery"
href="#LSToken-Discovery">LS Discovery Message</a>
+<a href="#rfc.section.4.8">4.8</a> <a id="LSControl-Discovery"
href="#LSControl-Discovery">LS Discovery Message</a>
</h2>
Structure of the LSDiscovery Message used to
locate info-sets.

@@ -1202,7 +875,7 @@
<a href="#rfc.section.4.9">4.9</a> <a id="Message Types" href="#Message
Types">Message Types</a>
</h2>
<ol>
-<li>Discovery – The Discovery request will contain a subject of the
relevant type. This will essentially be either an ipAddress or a Network (for
the query by IP case) or an abstract node with a location element expressing
the location requirements of interest. <ol style="list-style-type:
lower-alpha">
+<li>Discovery - The Discovery request will contain a subject of the relevant
type. This will essentially be either an ipAddress or a Network (for the
query by IP case) or an abstract node with a location element expressing the
location requirements of interest. <ol style="list-style-type: lower-alpha">
<li>LSDiscoveryRequest</li>
<li>LSDiscoveryResponse <ol style="list-style-type: lower-alpha">
<li>Success</li>
@@ -1212,9 +885,9 @@
</li>
</ol>
</li>
-<li>Token – Token messages will be used to exchange information
between LS instances. The can be specialized (by eventType) to handle
different tasks such as Joining, exchanging summary information, or used for
leader communication. <ol style="list-style-type: lower-alpha">
-<li>LSTokenRequest</li>
-<li>LSTokenResponse <ol style="list-style-type: lower-alpha">
+<li>Token - Token messages will be used to exchange information between LS
instances. The can be specialized (by eventType) to handle different tasks
such as Joining, exchanging summary information, or used for leader
communication. <ol style="list-style-type: lower-alpha">
+<li>LSControlRequest</li>
+<li>LSControlResponse <ol style="list-style-type: lower-alpha">
<li>Success</li>
<li>Refer</li>
<li>Failure</li>
@@ -1251,14 +924,14 @@
<a href="#rfc.section.6.1">6.1</a> <a id="glossary"
href="#glossary">Glossary</a>
</h2>
<ul>
-<li>Service – A Service is an application that communicates with other
perfSONAR Services via standarized protocol set (SOAP+XML+NMWGv2)</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>Summary Information – aggregated information from Lookup
Information that is sent by one LS to another</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>Home LS (HLS) – The Home LS of a Service is the LS where the
Service registers its Lookup Information</li>
-<li>Upper (Global) Scope – The scoping paradigm meant to indicate
intra-domain relationships.</li>
-<li>Lower (Local) Scope – The scoping paradigm meant to indicate
inter-domain relationships.</li>
+<li>Service - A Service is an application that communicates with other
perfSONAR Services via standarized protocol set (SOAP+XML+NMWGv2)</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>Summary Information - aggregated information from Lookup Information
that is sent by one LS to another</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>Home LS (HLS) - The Home LS of a Service is the LS where the Service
registers its Lookup Information</li>
+<li>Upper (Global) Scope - The scoping paradigm meant to indicate
intra-domain relationships.</li>
+<li>Lower (Local) Scope - The scoping paradigm meant to indicate
inter-domain relationships.</li>
</ul>
<h1 class="np" id="rfc.references">
<a href="#rfc.section.7">7.</a> References</h1>
@@ -1323,9 +996,9 @@
Maciej


-Poznań Supercomputing and Networking Center
+Poznan Supercomputing and Networking Center
ul. Noskowskiego 10
- 61-704 Poznań
+ 61-704 Poznan
Poland
</address>
</body>

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

Modified: trunk/nmwg/doc/dLS/dLS.xml
===================================================================
--- trunk/nmwg/doc/dLS/dLS.xml 2007-10-01 23:54:49 UTC (rev 279)
+++ trunk/nmwg/doc/dLS/dLS.xml 2007-10-02 14:35:02 UTC (rev 280)
@@ -35,12 +35,12 @@
</author>
<author initials='M' surname='Glowiak' fullname='Maciej Glowiak'
role='Contributor'>
- <organization abbrev='PSNC'>Poznań Supercomputing and Networking
Center
+ <organization abbrev='PSNC'>Poznan Supercomputing and Networking
Center
ul. Noskowskiego 10
- 61-704 Poznań
+ 61-704 Poznan
Poland</organization>
</author>
- <date month="September" year="2007"/>
+ <date month="October" year="2007"/>
</front>

@@ -62,14 +62,14 @@
<figure anchor="ls-op">
<preamble>LS Operation</preamble>
<artwork>
- _____ _____
-| | Register Metadata | |
-| LS | <------------------------> | MA |
-|_____| <--------- |_____|
- | _____
- | | |
- ----------------> | TS |
- Query for Services |_____|
+ _____ __________
+| | Register/De-register | Service |
+| LS | <------------------------> | Service |
+|_____| <--------- |__________|
+ | _________________
+ | | |
+ ----------------> | Client/Service |
+ Query for Services |_________________|

</artwork>
<postamble>Services interacting with an LS</postamble>
@@ -82,15 +82,15 @@
</t>

<list style="symbols">
- <t>Summarization – to reduce the amount of information sent over the
+ <t>Summarization - to reduce the amount of information sent over the
network or to anonymize sensitive data, some form of data
reduction
must take place.
</t>
- <t>Scope – to enable a hierarchy of systems, some form of scoping
+ <t>Scope - to enable a hierarchy of systems, some form of scoping
must exist that forms logical communication and data exchange
channels.
</t>
- <t>Search – information location is key and the way in which
+ <t>Search - information location is key and the way in which
distributed location and search is handled is the crux of this
service.
</t>
@@ -112,7 +112,7 @@
<t>The first step of information flow is when a service registers
with
an LS. The service may know the name of an LS via static
configuration, or other forms of bootstrapping may occur. A
service
- registers a metadata record about itself and full metadata (i.e.
+ registers metadata record about itself and full metadata (i.e.
containing all information such as subject, eventType(s), and any
parameters, see <xref target="service-metadata" />) about stored
(or gathered) data. Such a record is called Lookup Information
@@ -127,15 +127,13 @@
</t>

-<t>
-<vspace blankLines="2" />
-START_NOTE (Jason 9/18/07):
-<vspace blankLines="1" />
-Question 1)
-<vspace blankLines="1" />
-END_NOTE:
-<vspace blankLines="2" />
-</t>
+<t><vspace blankLines="2" />START_NOTE (Jason 9/18/07):<vspace
blankLines="1" />
+Question 1) In the first level of summarization (i.e. 'local' ring) what is
being
+exchanged between HLS instances? Are they exchanging full information, or
+summaries? Where is this info stored (i.e. seperate collection)? If we are
exchanging
+summaries it is natural to use a different collection, if we are exchanging
+full info it doesn't seem to be necessary.
+<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" /></t>

<t>The LS that a service contacts to register becomes the "Home LS"
@@ -151,27 +149,41 @@
<figure anchor="hls-cloud">
<preamble>HLS Cloud</preamble>
<artwork>
+
+A) Token passing
_____ _____
| | | |
-| LS | <----------------- | LS |
+| LS1 | <----------------- | LS2 |
|_____| Communicate via |_____|
| token exchange ^
- | | Broadcast Summary info to
- | _____ | all peers when holding
- | | | | the token
- |-------> | LS | ---------|
+ | |
+ | _____ |
+ | | | |
+ |-------> | LS3 | ---------|
|_____|

+B) Broadcast summary
+ _____ _____
+| | | |
+| LS1 | < > | LS2 |
+|_____| \ / |_____|
+ \ /
+ \ / Broadcast Summary info to
+ \ _____ / all peers when holding the token
+ | |
+ | LS3 |
+ |____/T\ Token
+ \_/
+
</artwork>
- <postamble>HLS instances communicating via token. The holder
- of the token will inform everyone of summary
- information.</postamble>
+ <postamble>HLS instances communicating via token (A). The holder
+ of the token (LS3) will inform everyone of summary
+ information (B).</postamble>
</figure>

<t>
- The most natural
- summarization is based on the topology of the network (like in
- network routing). Thus, a given HLS will perform topology-based
+ The most natural summarization is based on the topology of the
network
+ (like in network routing). Thus, a given HLS will perform
topology-based
summarization and will include this information as well as
eventType
information to other LSs in its "lower scope" (formerly known as
"local scope"). Likewise, more aggressive summarization can take
@@ -181,44 +193,25 @@
scope).
</t>

-
-<t>
-<vspace blankLines="2" />
-START_NOTE (Jason 9/18/07):
-<vspace blankLines="1" />
-Question 2)
-<vspace blankLines="1" />
-END_NOTE:
-<vspace blankLines="2" />
-</t>
-
-
- <t>Summarization will be performed using either Extensible Stylesheet
- Language Transformation (XSLT) documents or the XQuery language.
Each
- of these approaches has pros and cons. XQuery is supported by XML
- databases and many people find it easier to read and understand.
XSLT
- is also in wide use and is available as a standalone application.
The
- key issue is the format of the output so it is less important
which
- particular mechanism is used.
+ <t>
+ Summarization will be performed using specialized summary
algorithm. Topology information such as IP addresses will be summarized using
algorithms basing on radix tree (the IP addresses summarization algorithm is
described in section <xref target="IP-summary" />) .</t>
+
+ <t>In addition to that either Extensible Stylesheet Language
Transformation (XSLT) documents or the XQuery language may be used for
transformation eventType elements.
</t>
-
+
+
+<t><vspace blankLines="2" />START_NOTE (Jason 9/18/07):<vspace
blankLines="1" />
+ Question 3) Are additional 'aggressive' summaries still needed? At the
upper levels
+ it seems to be less of 'summarization' and more of an aggregate of
summaries
+ (unless we are dropping things out).
+<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" /></t>

-<t>
-<vspace blankLines="2" />
-START_NOTE (Jason 9/18/07):
-<vspace blankLines="1" />
-Question 3)
-<vspace blankLines="1" />
-END_NOTE:
-<vspace blankLines="2" />
-</t>
-

<t>These documents 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. The output of this process
becomes a "service summary" that represents a breadth of the
original
- input. See <xref target="LSToken-Summary" /> for a mock-up of the
+ input. See <xref target="LSControl-Summary" /> 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.
@@ -238,13 +231,24 @@
<t>We may target cases where various summarizations are possible, but
for now summarization on the basis of topology seems sufficient.
</t>
-
+
<t>A related question is that of policy. In our discussions, we had
the
intuition that some domains would want to register less
information
than others. One example is whether the actual IP addresses of
MPs
capable of launching active measurements. These hosts, if
compromised, can pose significant denial of service threat.
</t>
+
+ <section anchor="IP-summary" title="IP addesses summarization
algorithm">
+ <t>The IP addresses summarization algorithm is based on radix
tree. The idea of the algorithm is...</t>
+
+<t><vspace blankLines="2" />START_NOTE (Maciej 10/2/07):<vspace
blankLines="1" />
+To be done... I'd expect detailed recipe here.
+<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" /></t>
+
+ </section>
+
+
</section>

@@ -256,9 +260,9 @@
<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 poznan.pl to potentially operate
more
+ 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
+ scalability.) As LS instances come online they will invoke
bootstrapping procedures to find and join a lower scoped group
first.
</t>
@@ -301,9 +305,9 @@

<t>
An LS will continuously search it's LSRing information (see
- <xref target="LSRing" />) until a successful response to an
LSToken
+ <xref target="LSRing" />) until a successful response to an
LSControl
message (with a 'join' eventType, see
- <xref target="LSToken-Join" />) is seen. The LS will search
though
+ <xref target="LSControl-Join" />) is seen. The LS will search
though
the successful response 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
@@ -313,8 +317,8 @@
</t>

<t>
- After updating the LS will broadcast another LSToken message
(with
- a 'summary' eventType, see <xref target="LSToken-Summary" />) to
all
+ After updating the LS will broadcast another LSControl message
(with
+ a 'summary' eventType, see <xref target="LSControl-Summary" />)
to all
of the 'active' LS instances from it's LSRing. Again the
responses
will be parsed to get any useful updated information. Each of
the
recipient LS instances will do the same, including adding this
new
@@ -327,11 +331,25 @@
etiquette and remain silent until it is contacted with a token,
or
it has not seen one in a very long time.
</t>
+
+ <section anchor="join_algorithm" title="Join algorithm">
+ <t>
+ This paragraph describes the Join procedure for LS1.
+ <t>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</t>
+ <t>2. LS2 receives join message from L1 and decides whether
to accept it or not. A security policy may occur here</t>
+ <t>3. LS1 gets the answer - success joining (result code:
http://perfsonar.net/result/success/LS/join) or failure (error code)</t>
+ <t>4. If succcess LS1 will be waiting for token and LS2
updates its local peer list</t>
+ <t>5. In the meantime LS2 receives Token. Then it
synchronizes peer lists - the local one and the one in token. LS2 sends local
summary to all peers from list (due to summary broadcasting algotirhm -
see...). LS2 sends Token to next peer from the list (not necessarily to
LS1).</t>
+ <t>6. When there is LS1 turn it will get the Token. Then it
synchronizes peer lists - local and the one in token, sends its local summary
to all peers from list and sends Token to next peer</t>
+
+ </t>
+ </section>
+
</section>

<section anchor="tokens" title="Token Passing">
<t>
- The 'token' is a message (see <xref target="LSToken-Token" />)
+ The 'token' is a message (see <xref target="LSControl-Token" />)
meant to be passed around an LSRing to the various members in
some
order. We will pass from smallest 'contentSize' to largest
(with appropriate wrap around), and at any given time an LS
@@ -341,7 +359,7 @@
<t>
The token can be viewed as 'permission to talk' and permits the
holder to send it's summary information to all available LS
- instances (see <xref target="LSToken-Summary" />). The responses
+ instances (see <xref target="LSControl-Summary" />). The
responses
will be parsed to get any useful updated information.
</t>

@@ -382,7 +400,7 @@
</t>

<t>
- <xref target="LSToken-Summary" /> contains examples of the
message
+ <xref target="LSControl-Summary" /> contains 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).
@@ -421,7 +439,7 @@
The Leader and Vice-Leader LS instances should exchange messages
periodically to ensure that in the event of a failure the lower
level will still have a link to the upper level (see
- <xref target="LSToken-Leader" />). A Vice-Leader will be
monitoring
+ <xref target="LSControl-Leader" />). 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.
@@ -429,7 +447,7 @@

<t>The timeout mechanism(s) will need to be further specified. It
can
be computed as a function of the number of nodes in the ring.
This
- is the Target Token Rotation Time (TTRT). There may be a future
+ is the Target Token Rotation Time (TTRT), for details see
section: <xref target="TTRT" />TTRT computing. There may be a future
point at which we need to think about ring splitting, but we
believe that this can be managed by further scope levels.
</t>
@@ -441,7 +459,7 @@
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
+ Actual syntax doesn't matter that much but I would like the
following components:

<list style="numbers">
@@ -455,6 +473,11 @@
trailing / )</t>
</list>
</t>
+
+ <section anchor="TTRT" title="TTRT computing algorithm">
+ <t>TBD.</t>
+ </section>
+
</section>

@@ -464,15 +487,11 @@
<section anchor="search" title="Search">

-<t>
-<vspace blankLines="2" />
-START_NOTE (Jason 9/18/07):
-<vspace blankLines="1" />
-Question 4)
-<vspace blankLines="1" />
-END_NOTE:
-<vspace blankLines="2" />
-</t>
+<t><vspace blankLines="2" />START_NOTE (Jason 9/18/07):<vspace
blankLines="1" />
+ Question 4) I think we should go with one algorithm here, and
'improvements' to the
+ protocol in the future can give us two. Can we just pick iterative and
+ only explain that?
+<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" /></t>

<t>The search operation is obviously critical to the Lookup Service's
function. It is envisioned that searching could take one of two
@@ -502,7 +521,7 @@
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
- <xref target="LSToken-Discovery" />).
+ <xref target="LSControl-Discovery" />).
</t>

<section anchor="discovery-alg" title="Discovery Algorithm">
@@ -531,7 +550,7 @@
(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
+ 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.
@@ -670,57 +689,57 @@
</t>
</section>

- <section anchor="LSToken-Join" title="LS Joining Message for
Joining a Ring">
- <t>Structure of the LSToken messages focused on joining a
ring.</t>
+ <section anchor="LSControl-Join" title="LS Joining Message for
Joining a Ring">
+ <t>Structure of the LSControl messages focused on joining a
ring.</t>
<t>
<artwork>
<![CDATA[
- <inline file="LSToken-Join.xml"/>
+ <inline file="LSControl-Join.xml"/>
]]>
</artwork>
</t>
</section>

- <section anchor="LSToken-Token" title="LS Token Message">
- <t>Structure of the LSToken messages serving as the passable
'token'.</t>
+ <section anchor="LSControl-Token" title="LS Token Message">
+ <t>Structure of the LSControl messages serving as the passable
'token'.</t>
<t>
<artwork>
<![CDATA[
- <inline file="LSToken-Token.xml"/>
+ <inline file="LSControl-Token.xml"/>
]]>
</artwork>
</t>
</section>

- <section anchor="LSToken-Summary" title="LS Summary Message">
- <t>Structure of the LSToken messages focused on exchanging
summary information.</t>
+ <section anchor="LSControl-Summary" title="LS Summary Message">
+ <t>Structure of the LSControl messages focused on exchanging
summary information.</t>
<t>
<artwork>
<![CDATA[
- <inline file="LSToken-Summary.xml"/>
+ <inline file="LSControl-Summary.xml"/>
]]>
</artwork>
</t>
</section>

- <section anchor="LSToken-Leader" title="LS Leader Message">
- <t>Structure of the LSToken messages dealing with when a Leader
needs to inform the Vice-Leader
+ <section anchor="LSControl-Leader" title="LS Leader Message">
+ <t>Structure of the LSControl messages dealing with when a
Leader needs to inform the Vice-Leader
of the summaries from above.</t>
<t>
<artwork>
<![CDATA[
- <inline file="LSToken-Leader.xml"/>
+ <inline file="LSControl-Leader.xml"/>
]]>
</artwork>
</t>
</section>

- <section anchor="LSToken-Discovery" title="LS Discovery Message">
+ <section anchor="LSControl-Discovery" title="LS Discovery
Message">
<t>Structure of the LSDiscovery Message used to locate
info-sets.</t>
<t>
<artwork>
<![CDATA[
- <inline file="LSToken-Discovery.xml"/>
+ <inline file="LSControl-Discovery.xml"/>
]]>
</artwork>
</t>
@@ -728,7 +747,7 @@

<section anchor="Message Types" title="Message Types">
<list style="numbers">
- <t>Discovery – The Discovery request will contain a subject of the
+ <t>Discovery - The Discovery request will contain a subject of the
relevant type. This will essentially be either an ipAddress or
a
Network (for the query by IP case) or an abstract node with a
location element expressing the location requirements of
@@ -745,13 +764,13 @@
</list>
</t>

- <t>Token – Token messages will be used to exchange information
+ <t>Token - Token messages will be used to exchange information
between LS instances. The can be specialized (by eventType)
to handle different tasks such as Joining, exchanging summary
information, or used for leader communication.
<list style="numbers">
- <t>LSTokenRequest</t>
- <t>LSTokenResponse
+ <t>LSControlRequest</t>
+ <t>LSControlResponse
<list style="numbers">
<t>Success</t>
<t>Refer</t>
@@ -796,11 +815,11 @@
<section anchor="glossary" title="Glossary">
<list style="symbols">

- <t>Service – A Service is an application that communicates with
+ <t>Service - A Service is an application that communicates with
other perfSONAR Services via standarized protocol set
(SOAP+XML+NMWGv2)</t>

- <t>Lookup Service (LS) – The Lookup Service is a key element of the
+ <t>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
@@ -809,23 +828,23 @@
Basic Lookup Service supports registration, query, keepalives
and de-registration actions (additionally updates?).</t>

- <t>Lookup Information – information registered by a Service in the
+ <t>Lookup Information - information registered by a Service in the
Lookup Service</t>

- <t>Summary Information – aggregated information from Lookup
+ <t>Summary Information - aggregated information from Lookup
Information that is sent by one LS to another</t>

- <t>Multidomain / Distributed Lookup Information (mLS) – Lookup
+ <t>Multidomain / Distributed Lookup Information (mLS) - Lookup
Service which supports summarization and communication with
other
Lookup Services (which might be in the same domain...)</t>

- <t>Home LS (HLS) – The Home LS of a Service is the LS where the
+ <t>Home LS (HLS) - The Home LS of a Service is the LS where the
Service registers its Lookup Information</t>

- <t>Upper (Global) Scope – The scoping paradigm meant to indicate
+ <t>Upper (Global) Scope - The scoping paradigm meant to indicate
intra-domain relationships.</t>

- <t>Lower (Local) Scope – The scoping paradigm meant to indicate
+ <t>Lower (Local) Scope - The scoping paradigm meant to indicate
inter-domain relationships.</t>

</list>

nmwg: r280 - trunk/nmwg/doc/dLS, svnlog, 10/02/2007

List archive

nmwg: r280 - trunk/nmwg/doc/dLS