As per Relevance of the word establish, we have this rfc below:
Network Working Group L.
Request for Comments: 2968 T.
Category: Informational October 2000
Mesh of Multiple DAG servers - Results from
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
The Common Indexing Protocol ([CIP1]) is designed to facilitate
creation not only of query referral indexes, but also of meshes
(loosely) affiliated referral indexes. The purpose of such a mesh
servers is to implement some kind of distributed sharing of
and/or searching tasks across different servers. So far, the
(Technical Infrastructure for Swedish Directory Access Gateways
project ([TISDAG], [DAGEXP]) has focused on creating a
referral index; the obvious next step is to integrate that into
larger set of interoperating services
1.
1.1 Overview of mesh
Two different possibilities are possible for extending the
service to a mesh model (or some combination of both). First,
should be possible to create a mesh of DAG-based services. Or,
might be interesting to use the mesh architecture to
access to other types of services (e.g., the Norwegian Directory
Directories). In either case, the basic principle for establishing
mesh is that interoperating services should exchange index objects
according to the architecture of the mesh (e.g., hierarchical,
graph-like, preferably without loops!).
As is outlined in the CIP documentation ([CIP1]), many
exist for mechanisms for creating indexes over multiple
servers -- for example, WDSP index objects could be passed
Daigle & Eklof Informational [Page 1]
RFC 2968 Mesh of Multiple DAG servers October 2000
untouched, or a referral index server's contents could be
into a new index object, generating referrals back to that server
The proposal is that the mesh should be constructed using
objects aggregated over participating services' servers. That is
referrals will be generated to other recognized services, not
individual participants. This can be done as a hierarchy or a
mesh one-layer deep, but the important reason for not simply
forward index objects (unaggregated) is that individual services
support different ranges of access protocols, have
security requirements, etc. Referrals should be directed to a CAP
CAPs -- either the standard ones used by the DAG system, or new
established to support particular semantics of remote systems (e.g.,
other query types, etc). Within a given DAG system, referrals
these remote servers will look just like any other referral,
a particular SAP or SAPs may be established to provide
fulfillment (again, to enable translations between variations
service, to allow secure access if the relationship between
services is restricted, etc).
In the following scenarios of mesh traversal, the assumption is
the primary service in discussion (Country A in Scenario 1, Country
in Scenario 2) is a DAG-based service. The scenarios are
in the light of interoperating DAG services, but in most cases
would be equally applicable if the remote service was provided
some other service architecture. Again, the key element
establishing a mesh of any sort is the exchange of the CIP
object, not internal system architecture
1.1.1 Scenario 1: Top
Suppose 2 countries tie their services together. A user makes
query in Country A. A certain number of hits are made against
index objects of A's WDSPs. There is also a hit in the
index of Country B. There are 3 possible cases under which this
be handled
Case 1:
Country A and Country B are running services that are essentially
same -- in terms of protocols, queries, and schema that
supported. In this case, one referral should be generated
protocol supported by Country B's service. The referral can
passed back as far as the client, if its protocol supports referrals
Alternatively, the CAP may chain the referral through an
SAP, in the usual fashion. In other words, the CAPs of Country B'
service act as WDSPs to Country A's service
Daigle & Eklof Informational [Page 2]
RFC 2968 Mesh of Multiple DAG servers October 2000
Consider the following illustration (only relevant CAPs, SAPs, etc
are shown; others suppressed for lack of room):
+-----------------+
(1) |-----+ Country A | +-------+
------>|Prot1| DAG | |A-WSDP1|
<------| CAP | +-----| | Prot1 |
(2) |-----+ |Prot1| +-------+
| | SAP |
----+ | +-----| +-------+
(3)| | +-------+ | |A-WDSP2|
| | | RI-A | | | Prot1 |
| +-----------------+ +-------+
|
| +-------+
| |A-WDSP3|
| | Prot2 |
+----------------+ +-------+
| [...]
|
| +-----------------+
| |-----+ Country B | +-------+
+-------->|Prot1| DAG | |B-WSDP1|
| CAP | +-----| | Prot2 |
|-----+ |Prot1| +-------+
| | SAP |
| +-----| +-------+
| +-------+ | |B-WDSP2|
| | RI-B | | | Prot1 |
+-----------------+ +-------+
[...]
Prot[i] is some particular query
RI-A has an index over all A-WDSP[i] and RI-
RI-B has an index over all B-WDSP[i
(1) is the query to the Country A DAG system,
yields a referral based on the index object from RI-
(2) is that
(3) is the resolution of that referral, which the client
to the Country B DAG system directly (to find out which,
any, B-WDSP[i] have relevant information
Daigle & Eklof Informational [Page 3]
RFC 2968 Mesh of Multiple DAG servers October 2000
Case 2:
Country A and Country B are running services that address the
service type (e.g., whitepages), but are not using an
collection of protocols, allowed queries, or schema. The
object that Country B sent to Country A's DAG service must
constructed in terms of Country A's service, in order for
hits to be generated against the index object (i.e. for referrals
Country B's service). However, to resolve the referral, it will
necessary to do some further protocol/schema/query mapping. This
be done by a special SAP established within Country A's service,
maps Country A's service into the published service of Country B
Country A may then elect to support only one of Country B's
protocols, and the designated SAP will always contact one type of
at Country B
Alternatively, Country B can establish a particular CAP that does
mapping from Country A's service into something that is
appropriate against the internal structure of its service. In
case, Country A's referral will be to a special CAP in Country B'
service (which, again, will look like a WDSP to the Country
service); in fact, the referral may be handled directly by the
software. The difference between the two possible approaches lies
the responsibility of managing the relationship between the 2
types. On the one hand, Country A could handle it if it knows
service as well as the published access to Country B. On the other
Country B could be responsible for establishing a CAP for
country that may want to connect to it. The latter can, in
cases, be justified by the amount of internal optimization that
be done, and because it reduces the overhead for Country A's
(can pass the referral directly back to the client software).
Consider the following illustration (only relevant CAPs, SAPs, etc
are shown; others suppressed for lack of room):
Daigle & Eklof Informational [Page 4]
RFC 2968 Mesh of Multiple DAG servers October 2000
+-----------------+
(1) |-----+ Country A | +-------+
------>|Prot1| DAG | |A-WSDP1|
<------| CAP | +-----| | Prot1 |
(2) |-----+ |Prot1| +-------+
| | SAP |
----+ | +-----| +-------+
(3)| | +-------+ | |A-WDSP2|
| | | RI-A | | | Prot1 |
| +-----------------+ +-------+
|
| +-------+
| |A-WDSP3|
| | Prot2 |
+----------------+ +-------+
| [...]
|
| +-----------------+
| |-----+ Country B | +-------+
| |Prot3| DAG | |B-WSDP1|
| | CAP | +-----| | Prot3 |
| |-----+ |Prot3| +-------+
| |---------+ | SAP |
| |Country A| +-----|
+-------->|CAP:Prot1| |
|---------+ | +-------+
| +-------+ | |B-WDSP2|
| | RI-B | | | Prot3 |
+-----------------+ +-------+
[...]
Prot[i] is some particular query
RI-A has an index over all A-WDSP[i] and RI-
RI-B has an index over all B-WDSP[i
(1) is the query to the Country A DAG system,
yields a referral based on the index object from RI-
(2) is that
(3) is the resolution of that referral, which the client
to the Country B DAG system directly, but to a CAP
is specifically designed to accommodate protocols
Country A's service, and map it (and schema) into
B's service. Likely, all Country B referrals will
chained for the Country A
Daigle & Eklof Informational [Page 5]
RFC 2968 Mesh of Multiple DAG servers October 2000
Case 3:
The third possibility is, in fact, a refinement of the first.
Country A and Country B are running services that are every
identical except for the data (WDSPs covered), then it may make
to NOT aggregate Country B's WDSP index objects, but to copy them
Country A's server. Then, Country A's CAPs might be given access
the SAPs of Country B in order to carry out chaining directly at
remote service (instead of implicating Country A's SAPs and
B's CAPs, as in the first example above). The answer does not
from technology -- it depends entirely on the nature of
relationship that can be established between Country A and
B's services
1.1.2 Scenario 2: Working
The above scenario implicitly assumes that Country A's server
received index objects from Country B's server. This will be
case if Country A's server is higher in the levels of a hierarchy
services (established by agreements between the service operators),
or if the network is comprised of servers that share their
objects with all others, for example. In the latter case,
at any one of the servers in the service yields the full range
results -- referrals will be made to any other server that might
data that fulfills the user's query. The sharing of the
objects is a mechanism to allow each server to manage local data
while enabling distributed load-sharing on the basic query handling
However, if a hierarchical, or at least not-completely-
model is used for the server network, queries carried out at a
other than the top of the hierarchy, or in one particular branch
the hierarchy, will not actually be matched against all
objects. Therefore, there may be other servers to which the
should be directed if the full space needs to be searched. Suppose
for example, that in the above example Country B is in fact lower
the hierarchy than Country A. A user sending a query to Country B'
service may be content to limit the scope of the query to
country's information (this is true in enough real-life
that this hierarchical relationship becomes an effective
for scoping queries and avoiding having to flood the entire
with every single query or keep full copies of all data in
server).
Still in theoretical stages, the DAG/IP provides control
to allow DAG components to act according to the topology of the mesh
A CAP might use the "polled-by" system command to establish
other servers in the mesh exist in higher levels (and therefore
be worth contacting if the scope of the search is to be increased).
Daigle & Eklof Informational [Page 6]
RFC 2968 Mesh of Multiple DAG servers October 2000
In the example above, a CAP in Country B's system could
that Country A's service was polling Country B, and therefore make
a logical target for expanding the scope of the query.
experience (primarily with server mesh topologies) is
before it will be clear how to best make use of these capabilities
. should the CAP always broaden the scope? only if there are
local referrals? under user direction
. should the CAP use a local SAP to contact the remote service'
CAP
. is it better to completely connect the mesh of servers,
produce some kind of hierarchy
.
2. Other
Depending on the context in which a mesh is established (e.g.,
between national white pages services, or different units of
corporate organization, etc), it may be useful to allow
WDSPs to indicate whether they are willing to have their
included in a DAG system's aggregated index object (i.e.,
the DAG system to receive referrals from other systems in the mesh).
3. Security
This document describes different configurations for
information between information services. It introduces no
considerations beyond those attendant in (and addressed by
particular directory service access protocols
4.
The work described in this document was carried out as part of an on
going project of Ericsson. For further information regarding
project, contact
Bjorn
bjorn.x.larsson@era.ericsson.
Daigle & Eklof Informational [Page 7]
RFC 2968 Mesh of Multiple DAG servers October 2000
5. Authors'
Leslie L.
Thinking Cat
EMail: leslie@thinkingcat.
Thommy
Hotsip
EMail: thommy.eklof@hotsip.
6.
Request For Comments (RFC) and Internet Draft documents are
from numerous mirror sites
[CIP1] Allen, J. and M. Mealling, "The Architecture of the
Indexing Protocol (CIP)", RFC 2651, August 1999.
[TISDAG] Daigle, L. and R. Hedberg "Technical Infrastructure
Swedish Directory Access Gateways (TISDAG)," RFC 2967,
October 2000.
[DAGEXP] Eklof, T. and L. Daigle, "Wide Area Directory
Experiences", RFC 2969, October 2000.
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification,
Norwegian Directory of Directories (NDD)", Work in Progress
Daigle & Eklof Informational [Page 8]
RFC 2968 Mesh of Multiple DAG servers October 2000
7. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Daigle & Eklof Informational [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
