RFC 2968 (rfc2968) - Page 2 of 9

Mesh of Multiple DAG servers - Results from TISDAG

RFC 2968              Mesh of Multiple DAG servers          October 2000


   untouched, or a referral index server's contents could be aggregated
   into a new index object, generating referrals back to that server.

   The proposal is that the mesh should be constructed using index
   objects aggregated over participating services' servers.  That is,
   referrals will be generated to other recognized services, not their
   individual participants.  This can be done as a hierarchy or a level
   mesh one-layer deep, but the important reason for not simply passing
   forward index objects (unaggregated) is that individual services may
   support different ranges of access protocols, have particular
   security requirements, etc.  Referrals should be directed to a CAP or
   CAPs -- either the standard ones used by the DAG system, or new ones
   established to support particular semantics of remote systems (e.g.,
   other query types, etc).  Within a given DAG system,  referrals to
   these remote servers will look just like any other referral, although
   a particular SAP or SAPs may be established to provide query
   fulfillment (again, to enable translations between variations of
   service, to allow secure access if the relationship between the
   services is restricted, etc).

   In the following scenarios of mesh traversal, the assumption is that
   the primary service in discussion (Country A in Scenario 1, Country B
   in Scenario 2) is a DAG-based service.  The scenarios are presented
   in the light of interoperating DAG services, but in most cases it
   would be equally applicable if the remote service was provided by
   some other service architecture.  Again, the key element for
   establishing a mesh of any sort is the exchange of the CIP index
   object, not internal system architecture.

1.1.1  Scenario 1:  Top Down

   Suppose 2 countries tie their services together.  A user makes a
   query in Country A.  A certain number of hits are made against the
   index objects of A's WDSPs.  There is also a hit in the aggregate
   index of Country B.  There are 3 possible cases under which this must
   be handled:

   Case 1:

   Country A and Country B are running services that are essentially the
   same -- in terms of protocols, queries, and schema that are
   supported.  In this case, one referral should be generated per
   protocol supported by Country B's service.  The referral can be
   passed back as far as the client, if its protocol supports referrals.
   Alternatively, the CAP may chain the referral through an appropriate
   SAP, in the usual fashion.  In other words, the CAPs of Country B's
   service act as WDSPs to Country A's service.




Daigle & Eklof               Informational