Mesh of Multiple DAG servers - Results from TISDAG
RFC 2968

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                          L. Daigle
Request for Comments: 2968                                      T. Eklof
Category: Informational                                     October 2000

           Mesh of Multiple DAG servers - Results from TISDAG

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   The Common Indexing Protocol ([CIP1]) is designed to facilitate the
   creation not only of query referral indexes, but also of meshes of
   (loosely) affiliated referral indexes.  The purpose of such a mesh of
   servers is to implement some kind of distributed sharing of indexing
   and/or searching tasks across different servers.  So far, the TISDAG
   (Technical Infrastructure for Swedish Directory Access Gateways)
   project ([TISDAG], [DAGEXP]) has focused on creating a single
   referral index; the obvious next step is to integrate that into a
   larger set of interoperating services.

1. Introduction

1.1 Overview of mesh possibilities

   Two different possibilities are possible for extending the TISDAG
   service to a mesh model (or some combination of both).  First, it
   should be possible to create a mesh of DAG-based services.  Or, it
   might be interesting to use the mesh architecture to incorporate
   access to other types of services (e.g., the Norwegian Directory of
   Directories).  In either case, the basic principle for establishing a
   mesh is that interoperating services should exchange index objects,
   according to the architecture of the mesh (e.g., hierarchical, or
   graph-like, preferably without loops!).

   As is outlined in the CIP documentation ([CIP1]), many possibilities
   exist for mechanisms for creating indexes over multiple referral
   servers -- for example, WDSP index objects could be passed along

Daigle & Eklof               Informational                      [Page 1]
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                      [Page 2]
RFC 2968              Mesh of Multiple DAG servers          October 2000

   Consider the following illustration (only relevant CAPs, SAPs, etc,