rfc2970.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


4.0 Proposed service architecture

   Pictorially, the DAG architecture is as follows:

         +-------------------------------------------+
     "a" |         |                +--------+       |
   <----->  CAP a  |                | SAP A  |       |
         |         |                |        |       |
         |---------+                +-+------+---+   |
         |                            |(Internal)|   |
         |           "DAG/IP"         | Server i |   |
         |                            +----------+   |
         |                                           |
         |                                           |
         |                          +--------+       | "B"
         |                          | SAP B  <-------------->
         |                          |        |       |
         |                          +--------+       |
         |                                           |
         +-------------------------------------------+

   Note that the bounding box is conceptual -- all components may or may
   not reside on one server, or a set of servers governed by the
   provider of the service.

   As we saw in the TISDAG project, the provider of this DAG-based
   service may be only loosely affiliated with the remote services that
   are used (Whitepages Directory Service Providers (WDSPs) in this
   case).

4.1 Using the architecture

   Building a service on this architecture requires:

   Service implementation:
      1. definition of the overall application to be supported by the
         system -- whitepages, web resource indexing, medical
         information
      2. requirements
      3. expected behavior

   System architecture:
      1. nature of deployment -- distributed, security requirements,
         etc.
      2. identification of necessary CAPs -- in terms of access
         protocols to be supported, different service levels to be
         provided (e.g., secure and unsecure connections)




Daigle & Eklof               Informational                      [Page 7]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


      3. identification of necessary services -- e.g., proxying to
         remote information search services, lookup services, "AAA[A]"
         (Authentication, Authorization, Accounting, [and Access])
         servers, etc
      4. definition of the transaction process for the service:  insofar
         as the CAPs represent the service to client software, CAP
         modules manage the necessary transactions with other service
         modules

   Data architecture:

      1. selection of schemas to be used (in each protocol)
      2. definition of schema and protocol mappings -- into and out of
         some DAG/IP representation

5.0  Illustrations

5.1 Existing TISDAG Project

   Consider the TISDAG project in the light of the above definitions.

   Service implementation:
      1. A national-scale subset of Whitepages lookups, with specific
         query types supported: only certain schema attributes were
         permitted in queries, and the expected behavior was limited in
         scope.
      2. Requirements: the service had to support multiple query
         protocols (from clients and for servers), and be capable of
         searching the entire space of data without centralizing the
         storage of records.
      3. Given a query of accepted type, provide referrals to whitepages
         servers that might have information to fulfill the query; if
         necessary, proxy the referrals (chain) to retrieve the
         information for the client.

   System architecture:
      1. distributable components
      2. publicly accessible CAPs in HTTP, SMTP, Whois++, LDAPv2, and
         LDAPv3
      3. referral proxies to Whois++, LDAPv2 and LDAPv3 WDSPs, as well
         as a referral query service
      4. the basic transaction process, uniform across all CAPs, is:
              - query the RI for relevant referrals
              - where necessary, chain referrals through SAPs of
                appropriate protocol return, in the native protocol, all
                remaining referrals and data





Daigle & Eklof               Informational                      [Page 8]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


   Data architecture:  see the spec.

   In the TISDAG project, the above diagram could be mapped as follows:

      CAP a           LDAPv2 CAP
      SAP A           the Referral Index (RI) interface
      Server i        the Referral Index (RI)
      SAP B           LDAPv3 SAP

   Note that, in the TISDAG project specification, the designation SAP
   referred exclusively to proxy components designed to deal with
   external servers.  The Referral Index was considered an entity in its
   own right.  However, generalizing the concepts of the TISDAG
   experience lead to the proposal of regarding all DAG/IP-supporting
   service components as SAPs, each designed to carry out a particular
   type of service functionality, and whether the server is managed
   internally to the DAG system or not is immaterial.

5.2 Operator service

   Consider the case of "number portability" -- wherein it is necessary
   to determine the current service provider of a specific phone number.
   The basic assumption is that phone numbers are assigned to be
   globally unique, but are not in any way tied to a specific service
   provider.  Therefore, it is necessary to determine the current
   service provider for the given number before being able to retrieve
   current information.  For the sake of our illustration, let us assume
   that the management of numbers is two-tiered -- suppose the system
   stores (internally) the mapping between these random digit strings
   and the country in which each was originally activated, but relies on
   external (country-specific) services to manage the updated
   information about which service provider currently manages a given
   number.  Then, the service data need only be updated when new numbers
   are assigned, or national services change their access points.

   We can look at a grossly-simplified version of the problem as an
   illustration of some of the concepts proposed in this service
   architecture.  We couple it with the "name search" facet of the
   TISDAG example, to underscore that a single service ("operator") may
   in fact be supported by several disjunct underlying activities.

   Service implementation:
      1. Retrieving service information for a particular (unstructured)
         phone number digit sequence, or searching for numbers
         associated with a particular name (or fragment thereof).
      2. Requirements:  support IP-telephony through HTTP-based
         requests, wireless device requests through WAP [WAP].




Daigle & Eklof               Informational                      [Page 9]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


      3. Expected behavior:  given a name (fragment), return a list of
         names and numbers to match the fragment; given a phone number,
         return appropriately-structured information re. the current
         service mapping for that number.

   System architecture:
      1. Publicly accessible through CAPs; components widely
         distributed.
      2. Need one CAP for HTTP, one for WAP.
      3. Support services include:  an internal service for lookup of
         number strings (to identify nation of origin of the number), a
         proxy to access national services for registration of numbers
         and service providers, and a proxy for remote service provider
         for retrieval of detailed information regarding numbers.  For
         the name searching, we also need a referral index over the
         names, and a proxy to whatever remote servers are managing the
         whitepages directories.
      4. Now, 2 different types of transaction are possible:  search for
         name, or look-up a number.  In the name search case, the CAP
         receives a name or name fragment, looks it up in the internal
         referral index, and finds associated numbers through external
         whitepages services (WDSPs).  To look-up a number, the CAP
         first uses the internal look-up service to determine the
         country of origin of the number, and then uses a SAP to access
         that nation's number-service provider directory, and finally
         uses a different SAP to access the current service provider to
         determine the information required to make the call.

   Data architecture:
        [Out of scope for the purposes of this illustration]

        Note that some elements of the system architecture are
        deliberately vague.  Per the requirements, no structure is
        expected in the number string, and therefore the lookup server
        must maintain an index of number-to-country mappings and relies
        on an external number-to-service mapping service (in each
        country).  However, were there any structure to the numbers, the
        lookup server could make use of that structure in the indexing,
        or in distribution of the index itself.  This would have no
        effect on the CAPs, which have no inherent reliance on how the
        lookup server performs its task.










Daigle & Eklof               Informational                     [Page 10]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


        Pictorially, the example can be rendered as follows:

         +-------------------------------------------+
     "a" |         |                +--------+       |
   <----->  CAP a  |                | SAP A  |       |
         |         |                |        |       |
         |---------+                +-+------+---+   |
         |                            |(Internal)|   |
         |           "DAG/IP"         | Server i |   |
         |                            +----------+   |
         |                                           |
         |                          +--------+       | "B"
         |                          | SAP B  <-------------->
         |                          |        |       |
         |                          +--------+       |
         |                                           |
         |                          +--------+       | "C"
         |---------+                | SAP C  <-------------->
     "b" |         |                |        |       |
   <----->  CAP b  |                +--------+       |
         |         |                                 |
         |---------+                +--------+       |
         |                          | SAP D  |       |
         |                          |        |       |
         |                          +-+------+---+   |
         |                            |(Internal)|   |
         |                            | Server j |   |
         |                            +----------+   |
         |                                           |
         |                          +--------+       | "E"
         |                          | SAP E  <-------------->
         |                          |        |       |
         |                          +--------+       |
         +-------------------------------------------+

   where

      CAP a           HTTP CAP
      CAP b           WAP CAP
      SAP A           the number-nation lookup interface
      Server i        number-nation lookup server (what country)
      SAP B           nation-service lookup SAP (what service provider)
      SAP C           service-number information lookup SAP (current
                      service details)
      SAP D           referral index interface
      Server j        referral index service
      SAP E           proxy for chaining queries to remote WDSPs




Daigle & Eklof               Informational                     [Page 11]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000


5.3 Medical application

   The service architecture is useful for applications outside the scope
   of "telecoms".  In another hypothetical illustration, consider the
   case of medical information -- records about patients that may be
   created and stored at a variety of institutions which they visit.  It
   is not unusual to need to access all information concerning a
   patient, whether or not the person can recollect (or communicate)
   conditions that were treated, procedures that were performed, or
   medical institutions visited.  The data may include everything from
   prescriptions, to X-rays and other images, to incident reports and
   other elements of medical history, etc.  Typically, the information
   is stored where it is collected (or by an agency authorized by that
   institution) -- not in a central repository.  Any service that looks
   to provide complete answers to queries must deal with these
   realities, and clearly must function with a strong security model.

   Service implementation:
      1. Retrieving all medical information for a particular person.
      2. Requirements:  must retrieve, or at least locate, all
         available information, regardless of its storage location;
         cannot require central repository of information; must
         implement authorization and access controls.  Must
         support a proprietary protocol for secure connections
         within hospitals, wireless access for personnel in
         emergency vehicles (not considered secure access).
      3. Expected behavior:  given a patient's national ID, and
         authorized access by medical personnel in secure locations,
         determine what kinds of records are available, and where;
         given a request for a specific type of record, retrieve
         the record.  Given a patient's national ID, and authorized
         access from a wireless device, provide information re.
         any known medical flags (e.g., medicine allergies,
         conditions, etc).

   System architecture:
      1. Only 2 CAP types are needed, but instances of these will
         be established at major medical institutions.
      2. Need one CAP to support the proprietary protocol, one
         to support wireless access.
      3. Support services include:  an internal server to support
         security authentication and access control determination;
         an internal server to act as referral index for finding
         information pertinent to a particular patient, and one
         or more proxies for accessing remote data storage servers.
      4. The basic transaction requires that the first step be
         to authenticate the end-user and determine access privileges.
         In the case of wireless access, this last will not involve



Daigle & Eklof               Informational                     [Page 12]

RFC 2970       Architecture for IDS - Result from TISDAG    October 2000