rfc1802.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

Network Working Group                                      H. Alvestrand
Request for Comments: 1802                                       UNINETT
Category: Informational                                        K. Jordan
                                                    Control Data Systems
                                                             S. Langlois
                                                   Electricite de France
                                                            J. Romaguera
                                                              NetConsult
                                                               June 1995


                     Introducing Project Long Bud:
      Internet Pilot Project for the Deployment of X.500 Directory
                Information in Support of X.400 Routing

Status of this Memo

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

Abstract

   The Internet X.400 community (i.e., GO-MHS) currently lacks a
   distributed mechanism providing dynamic updating and management of
   message routing information.  The IETF MHS-DS Working Group has
   specified an approach for X.400 Message Handling Systems to perform
   message routing using OSI Directory Services.  The MHS-DS approach
   has been successfully tested in a number of local environments.

   This memo describes a proposed Internet Pilot Project that seeks to
   prove the MHS-DS approach on a larger scale.  The results of this
   pilot will then be used to draw up recommendations for a global
   deployment.

1. Background

   The 1988 edition of X.400 introduces, among other extensions or
   revisions, the concept of O/R Names which assumes the existence of a
   widely available Directory Service.  This Directory Service is needed
   to support several MHS operations (support for names to identify
   senders and receivers of messages in a user-friendly fashion, support
   for distribution lists, authentication of MHS components, description
   of MHS components capabilities...).

   The prime advantage of Directory Names, as perceived by many users,
   was to release users from the remembering of complex O/R Addresses
   for their correspondents.



Alvestrand, et al            Informational                      [Page 1]

RFC 1802              Introducing Project Long Bud             June 1995


   In the MHS infrastructure, as compared to other protocols, a name by
   itself does not contain enough information to allow the Message
   Transfer Agents (MTAs) to route a message to the User Agent (UA)
   servicing this name.  The routing process is based on information
   provided by different MHS Management Domains, whether they are public
   or private.

   An MHS community combines several administrative MHS domains among
   which agreements for cooperative routing exist:  the GO-MHS community
   is the set of MTA's taking care of X.400 mail operations on the
   Internet [RFC 1649].

   In the absence of a distributed Directory Service, an interim
   technique has been developed within the GO-MHS community to collect
   and advertise routing information.  This resulted in an experimental
   IETF protocol [RFC 1465].

2. Rationale

   A number of routing problems are preventing the present Internet
   X.400 service from expanding its number of participating message
   transfer agents to a global scale.  The two most critical problems
   are:

      * The present mechanism of centrally maintained and advertized
        MTA routing tables has been optimized as far as possible.
        Increasing the number of directly connected MTAs increases also
        the workload on the MHS managers.  The current solution does
        not scale.  Routing must be a fully dynamic and distributed
        process.

      * Manual propagation and installation of routing tables do not
        guarantee consistency of routing information (even in a loose
        fashion) when it is accessed by different MTAs scattered across
        the globe.

   It is commonly accepted that a distributed mechanism providing for
   dynamic updating and management of X.400 routing information is
   highly desirable.  The focus of the project is to establish X.500-
   based support of X.400 routing, at a very large scale.

3. Benefits

   Using the Directory as a dynamic means of information storage and
   advertisement will guarantee participants in Project Long Bud that
   their updated data are globally available to the community.  As a
   direct consequence of the above, a participating MHS manager will be
   released from configuring connections to the other participants.



Alvestrand, et al            Informational                      [Page 2]

RFC 1802              Introducing Project Long Bud             June 1995


   Directory-capable MTAs will be able to discover more optimal and more
   direct routes to X.400 destinations than are practical today.  This
   will enable faster delivery of messages.

   The infrastructure reliability will be improved:  the information
   stored in the Directory will allow automatic use of backup
   connections in case of remote MTA or network problems.  X.400 mail
   managers in the GO-MHS Community should then be released from the
   need to know the complexity of the whole mail routing infrastructure.
   Providing a dynamic routing infrastructure will eliminate
   inconsistencies introduced by unsynchronized static tables and
   improve quality of service.

   Furthermore, besides the robustness and the optimization of the new
   routing infrastructure, the Long Bud approach should bring to the
   participating organizations better control over how they establish
   and maintain their interconnection with the GO-MHS community.

   Participants will share in building an X.400 network which can expand
   to a very large scale.  They will develop experience using a global
   messaging architecture which scales well and requires minimal
   administrative overhead.  They will be able to discuss experience
   with the MHS-DS experts and architects in the ongoing standards
   development cycle.

4. Definition of project LONG BUD

   The Long Bud pilot wishes to demonstrate that the X.500 Directory is
   able to provide a global-scale service to messaging applications.

   Although MHS-DS provides ways to use private routing trees, Long Bud
   will focus on the Open Community Routing Tree as used by the GO-MHS
   community.

4.1 Project Goals

   Project Long Bud has the following goals:

   * Gather pilot experience of the defined framework for X.500
     support of MTA routing, as defined by the IETF MHS-DS Working
     Group [Kille 94].

   * Actively investigate migration of the existing operational
     X.400 service from a routing method based upon distribution of
     centrally maintained static tables, as specified in [RFC 1465],
     to a method based instead upon X.500:





Alvestrand, et al            Informational                      [Page 3]

RFC 1802              Introducing Project Long Bud             June 1995


       -- Deploy X.400 MTAs which are directly capable of reading
          routing information from the X.500 Directory, in
          compliance with the specifications of the MHS-DS Working
          Group.  This type of MTA is called a directory-capable
          MTA.

       -- Deploy tools which read routing information from the X.500
          Directory and use it to generate static routing tables for
          MTAs which are not directory-capable.

   * specify a set of minimal operational requirements needed before
     X.500-based routing of X.400 messages can be widely deployed.

4.2 Phasing

   The first phase of Project Long Bud consists in deploying a small
   number of directory-capable MTAs operated by members of the MHS-DS
   Working Group and GO-MHS community.  These MTAs must be capable of
   using information in the X.500 directory to route messages to all
   other members of the project as well as to the existing GO-MHS
   community.  As of this writing, an initial set of MTAs is already
   operational.

   At the end of this phase, the following goals should be achieved:

   * The X.500 DIT must be populated with enough routing information
     to allow the participating MTAs to route reliably messages to
     each other and to the existing GO-MHS community.

   * The X.500 DSAs holding the routing information must operate at
     a quality of service that is acceptable for an operational
     X.400 service.

   As a prerequisite, a sufficient number of MTA managers must be
   willing to participate in Project Long Bud for the first set of
   results to be significant.  Support for a protocol stack conforming
   to [RFC 1006] is mandatory.  All MTAs participating in the Long Bud
   pilot need to register in the Open Tree and must be prepared to
   accept connections from anyone.

   Note that in the first phase, default routes will be established in
   the DIT such that messages addressed to destinations outside of the
   Long Bud community will be routed to designated MTAs in the GO-MHS
   community.  This will allow for full connectivity between the Long
   Bud community and the GO-MHS community which are related, but
   distinct communities.  Interworking between these two must be
   established and coordinated.




Alvestrand, et al            Informational                      [Page 4]

RFC 1802              Introducing Project Long Bud             June 1995


   In the second phase of Project Long Bud, a greater number of MTAs
   should be added to the experiment.  Cooperation with non directory-
   capable communities must be addressed.

4.3 General Approach

   No large scale resources have been committed to this project.  Yet,
   expedient deployment is desirable.  Therefore, the pilot project
   needs to be focused and relatively short-lived.  The general approach
   for satisfying these requirements includes:

   * Use as many existing MHS-DS tools as possible.  Also, continue
     to track the progress of tools being developed by project
     members and facilitate their deployment as soon as they are
     ready.

   * Coordinate efforts with existing GO-MHS community service.

   * Establish a core infrastructure:  4 DSAs (two in the United
     States and two in Europe) are set up to serve MHS-DS
     information.

   * Wherever it is technically feasable, DSA managers will
     establish bilateral agreements with one (or more) of the core
     DSAs in order to duplicate their routing information.  For
     example, the core DSAs support the replication protocol
     specified in [RFC 1275] as a duplication technique.

   * the Long Bud pilot needs to cooperate actively with DANTE
     NameFlow (the continuation of the PARADISE Pilot) and other
     directory providers in order to promote stability and
     consistency of informations.

4.4 Tools Needed

   To facilitate widespread deployment of MHS-DS routing technology and
   to foster interworking between directory-capable MTAs and MTAs which
   are not directory-capable, tools providing the following
   functionalities need to be developed:

   populate the Directory with routing information:  such a tool must
        accept routing information specified in the standard syntax
        used by the GO-MHS community (see [RFC 1465]) as input, and it
        will load or update entries which convey the same information
        in the X.500 Directory.






Alvestrand, et al            Informational                      [Page 5]

RFC 1802              Introducing Project Long Bud             June 1995


   downloading of routing information from the Directory:  in order to
        provide a migration path for organizations not using
        directory-capable MTAs, a tool is needed which will read X.400
        routing information from the X.500 Directory and generate
        static routing information from it.  The syntax of the static
        information generated will conform to the syntax defined by the
        GO-MHS community, so that "classical" MTAs run as they
        currently do.

   displaying route taken by a message between two end-points:  this
        tool should accept two parameters as input:  the X.500
        distinguished name of an MTA, and an X.400 O/R name.  It will
        display the possible routes which may be taken in order to
        deliver a message from the specified MTA to the specified X.400
        destination.  This tool looks very much the same as the
        traceroute facility used at the IP level.

   These tools must use standard protocols to access the Directory (such
   as DAP [CCITT 88] or LDAP [RFC 1487]).  Portability is encouraged.

   A note on quality

   Pilot use of this Directory information depends heavily on data
   quality and availability.  Although the administration of DSA