rfc2968.txt

RFC 的详细文档！

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,
   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 |
                                     +-----------------+     +-------+
                                                              [...]

   where
      Prot[i] is some particular query protocol
      RI-A has an index over all A-WDSP[i] and RI-B
      RI-B has an index over all B-WDSP[i]
      (1) is the query to the Country A DAG system, which
          yields a referral based on the index object from RI-B
      (2) is that referral
      (3) is the resolution of that referral, which the client takes
          to the Country B DAG system directly (to find out which, if
          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 same
   service type (e.g., whitepages), but are not using an identical
   collection of protocols, allowed queries, or schema.  The index
   object that Country B sent to Country A's DAG service must be
   constructed in terms of Country A's service, in order for appropriate
   hits to be generated against the index object (i.e. for referrals to
   Country B's service).  However, to resolve the referral, it will be
   necessary to do some further protocol/schema/query mapping.  This can
   be done by a special SAP established within Country A's service, that
   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 access
   protocols, and the designated SAP will always contact one type of CAP
   at Country B.

   Alternatively, Country B can establish a particular CAP that does the
   mapping from Country A's service into something that is most
   appropriate against the internal structure of its service.  In this
   case, Country A's referral will be to a special CAP in Country B's
   service (which, again, will look like a WDSP to the Country A
   service); in fact, the referral may be handled directly by the client
   software.  The difference between the two possible approaches lies in
   the responsibility of managing the relationship between the 2 service
   types.  On the one hand, Country A could handle it if it knows its
   service as well as the published access to Country B. On the other,
   Country B could be responsible for establishing a CAP for every
   country that may want to connect to it.  The latter can, in some
   cases, be justified by the amount of internal optimization that can
   be done, and because it reduces the overhead for Country A's service
   (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| +-----|