Movatterモバイル変換

Network Working Group                                      H. AlvestrandRequest for Comments: 1802                                       UNINETTCategory: Informational                                        K. Jordan                                                    Control Data Systems                                                             S. Langlois                                                   Electricite de France                                                            J. Romaguera                                                              NetConsult                                                               June 1995Introducing Project Long Bud:Internet Pilot Project for the Deployment of X.500 DirectoryInformation in Support of X.400 RoutingStatus 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   availability and global Directory data accuracy are not in the scope   of Long Bud, care must be taken that Directory resources used by Long   Bud participants are administrated well.   If they have the technical ability to do so, Long Bud participants   are encouraged to replicate routing information in their Directory to   improve data availability.   Directory data used by the pilot must be accurate:  solutions to this   problem will be recommanded as the project matures.5. Participation Guide   The existing operational X.400 service, the GO-MHS service, uses the   following method to distribute and manage X.400 routing information:   A group of MTAs is organized into a routing community.  The community   keeps its routing information up to date by assigning to each MTA   manager the responsibility of determining the routing information for   his/her MTA, formalizing this routing information in the syntax   defined by the community and sending the result to the GO-MHS   coordination service.  Once the information has been validated   against the other data provided by all managers in the community, the   coordination service will advertise it to the whole community.  Each   manager will then have to update his/her MTA configuration with theAlvestrand, et al            Informational                      [Page 6]

RFC 1802              Introducing Project Long Bud             June 1995   verified information.   The purpose of Project Long Bud is to allow a manager to operate an   MTA without having to perform ANY manual steps when another MTA   manager adds new or changes existing routing information.  This will   facilitate efficient, dynamic, and manageable interconnection of very   large communities of MTAs.  It will allow the Internet X.400   community to overcome the limitations in scalability which it is   currently encountering.5.1 Prerequisites for participation   The prerequisites for joining Project Long Bud are:   Step 1:  Participants in the pilot must have a good knowledge of            the IETF MHS-DS Working Group activities and documents:          1. Participants must join the MHS-DS distribution list:RFC-822:  mhs-ds@mercury.udev.cdc.com                     X.400:  PN=mhs-ds; OU=mercury; OU=OSS;                             OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US             Requests to join the MHS-DS distribution list may be sent             to the following email address:RFC-822:  mhs-ds-request@mercury.udev.cdc.com                    X.400:  PN=mhs-ds-request; OU=mercury; OU=OSS;                            OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US          2. Participants must retrieve and become familiar with all             relevant tools and documents stored on the Project Long             Bud anonymous FTP server                           Host name:  ftp.css.cdc.com                           Directory:  pub/mhs-ds/long-bud             In particular, openly available software related to Long             Bud activities will be kept up-to-date at this location.Alvestrand, et al            Informational                      [Page 7]

RFC 1802              Introducing Project Long Bud             June 1995          3. If not already done, participants must do one of the             following:               * Upgrade their X.400 and X.500 software such that it                 supports the MHS-DS specifications as in [Kille 94].               * Use the tools which extract MHS-DS information from                 the directory and generate whatever local                 configuration files are necessary to allow local MTA's                 to use the information.  This should be done                 frequently (at least once per day).   Step 2:  Participants must register required entries in the            Directory so that their MTA(s) is (are) known to the            Directory.          1. Arrange with the appropriate DSA Manager (who can be a             local manager if the DSA is run by the participating             organization, or a manager who is in charge of running the             organization's DSA) to create an entry for the local             MTA(s) involved in the pilot.  At this stage, only             connection information is required.          2. Check, test and verify the connection information with at             least one other participant.  The mhs-ds distribution list             should be used for announcing the new registration and             asking volunteers for testing.          3. Participants must establish sensible default X.400 routes             to existing GO-MHS destinations for which X.500-based             routing information will not exist initially.   Step 3:  Participants can then enter their routing information in            the Directory.          1. Before any routing is entered in the DIT, participants             must check with the GO-MHS Coordination Service that the             routes they want to register can be properly handled by             the GO-MHS community (contact information is             mailflow@mailflow.dante.net).  It is crucial for the Pilot             that any routing information entered in the Directory is             kept carefully accurate if the experiment is to be             meaningful.  Participants may also consider the need for             mapping rules (see [RFC 1465] for details).          2. Once the above step is validated by the GO-MHS             Coordination Service, participants must record routing             information for their MTA(s) in the Internet X.500Alvestrand, et al            Informational                      [Page 8]

RFC 1802              Introducing Project Long Bud             June 1995             directory service.  This requires that a participant does             the following:               * Arrange with the appropriate DSA Manager (who can be                 either a local manager if the DSA is run by the                 participating organization or a manager which is in                 charge of running the organization's DSA) to enter                 X.400 routing information in a routing tree held by                 the participating organization.  This routing tree                 should contain all necessary information for the local                 mail domain.               * Check, test and verify the registered routing                 information with at least one other participant.  The                 mhs-ds distribution list should be used for announcing                 the new registration and asking volunteers for                 testing.          3. If a participant adds new nonleaf entries to the Open             Community Routing Tree, then s/he must find at least one             other participant who will maintain a slave copy of the             children of the nonleaf entry.  Send email to the mhs-ds             distribution list in order to find a partner who is             willing to do this.          4. If a participant adds new nonleaf ADMD or PRMD entries to             the directory, then s/he must contact the managers of the             Long Bud core DSA's and arrange to provide slave copies of             the children of the ADMD and/or PRMD entries to all of the             core DSA's.  Send email to the mhs-ds distribution list in             order to contact the core DSA managers.          5. Once the above testing is completed, send email to the             mhs-ds distribution list announcing the establishment of             new X.500-based routes.6. Notes on side effects   The Long Bud Pilot Project, with its specific scope, is investigating   a new direction in X.500 service usage.  This should facilitate and   expedite the global deployment of X.500 on the Internet.   Once the routing infrastructure illustrated by the Long Bud   experiment is in place, the routing process will be able to take into   account additional information to improve quality of service   (minimizing messages conversions, enforcing various security policies   established by MHS domains, taking advantage of recipients's   capabilities stored in the Directory, ...).  While the Open TreeAlvestrand, et al            Informational                      [Page 9]

RFC 1802              Introducing Project Long Bud             June 1995   provides global connectivity, multiple private routing trees allow   the use of various routing trees.7. Acknowledgements   The authors would like to thank Urs Eppenberger (SWITCH) and Allan   Cargille (University of Wisconsin) for their constructive comments on   earlier drafts of this document.References   [CCITT 88]          International Telegraph and Telephone                       Consultative Committee. X.500 Recommendations                       series. December 1988.   [RFC 1649]          Hagens, R., and A. Hansen, "Operational                       Requirements for X.400 Management Domains in the                       GO-MHS Community",RFC 1649, ANS, UNINETT,                       July 1994.   [Kille 94]          Kille, S., "MHS Use of the X.500 Directory to                       Support MHS Routing",RFC 1801, ISODE Consortium,                       June 1995.   [RFC 1006]          Rose, M., and D. Cass, "ISO Transport Service on                       top of the TCP Version: 3", STD 35,RFC 1006,                       Northrop Research and Technology Center,                       May 1987.   [RFC 1275]          Hardcastle-Kille, S., "Replication Requirements                       to provide an Internet Directory using X.500",RFC 1275, University College London,                       November 1991.   [RFC 1465]          Eppenberger, U., "Routing Coordination for X.400                       MHS Services Within a Multi Protocol / Multi                       Network Environment Table Format V3 for Static                       Routing",RFC 1465, SWITCH, May 1993.   [RFC 1487]          Yeong, W., Howes, T., and S. Kille, "X.500                       Lightweight Directory Access Protocol",RFC 1487, Performance Systems International,                       University of Michigan, ISODE Consortium,                       July 1993.Alvestrand, et al            Informational                     [Page 10]

RFC 1802              Introducing Project Long Bud             June 19958. Security Considerations   Security issues are not discussed in this memo.Authors' Addresses   Harald T. Alvestrand   UNINETT   P.O. box 6883 Elgeseter   N-7002 Trondheim, Norway   Phone:  +47-73-59-70-94   EMail:  Harald.T.Alvestrand@uninett.no   Kevin E. Jordan   Control Data Systems, Inc.   4201 Lexington Avenue North   Arden Hills, MN 55126, USA   Phone:  +1-612-482-6835   EMail:  Kevin.E.Jordan@cdc.com   Sylvain Langlois   Electricite de France   Direction des Etudes et Recherches   1, avenue du General de Gaulle   92141 Clamart Cedex, France   Phone:  +33-1-47-65-44-02   EMail:  Sylvain.Langlois@der.edf.fr   James A. Romaguera   NetConsult AG   Morgenstrasse 129 3018 Bern, Switzerland   Phone:  +41-31-9984141   EMail:  Romaguera@NetConsult.ch   X.400:  S=Romaguera;O=NetConsult;P=switch;A=arcom;C=chAlvestrand, et al            Informational                     [Page 11]