MHS-DS Working Group Harald T. Alvestrand INTERNET-DRAFT Sintef Delab Kevin E. Jordan Control Data Systems Sylvain Langlois Electricite de France James A. Romaguera NetConsult June 14, 1993 Expires: November 25, 1993 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 document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Drafts, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract The Internet R&D X.400 community (i.e. GO-MHS) currently lacks a distributed mechanism providing dynamic update 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 INTERNET--DRAFT describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger global scale. The results of this pilot will then be used to draw recommendations for a global scale deployment. INTERNET--DRAFT Introducing Project Long Bud June 14, 1993 1 Background An MHS community gathers 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 [Hagens et al. 93]. A number of routing problems are preventing the present Internet R&D 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 maintaining and distributing static, centralized MTA routing tables has become too labor intensive. Further practical growth can not be achieved using the current method without sacrificing accuracy and reliability. * X.400 routes are not consistent when accessed by different MTAs scattered across the globe. The existing MTA routing tables are too static. They do not accommodate the variety of routing options which apply when the X.400 service is expanded to a global scale. It is commonly accepted that a distributed mechanism providing for dynamic updating and management of X.400 routing information is highly desirable. For this to occur, it is essential that X.500-based support of X.400 routing be established. The purpose of the Long Bud pilot project is to prove that the concepts and procedures developed within the MHS-DS working group are viable in an operational service environment and that they can be expanded to a global scale in a straightforward fashion. 2 Definition of project LONG BUD 2.1 Project Goals Project Long Bud has the following basic goals: * Gather operational experience of the defined framework for X.500 support of MTA routing, as defined by the IETF MHS-DS Working Group [Kille 92]. This should facilitate and expedite the global deployment of X.500 usage with this particular scope by providing experimental feedback into the current work before any operational deployment is started. Alvestrand et al. Expires: November 25, 1993 [Page 1] INTERNET--DRAFT Introducing Project Long Bud June 14, 1993 * Actively investigate migration of the existing operational R&D 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. This goal is comprised of two subgoals: -- Deploy X.400 MTA's 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 MTA's which are not directory-capable. Long Bud is focused on the use of X.500 Directory. It does not address the problem of communities using proprietary directories mechanisms (e.g. PC mail systems on a private LAN which need to route messages to the Internet X.400 community). However, the second subgoal above may be used as an interim solution to provide such communities, following an appropriate data format conversion method, with global Internet X.400 routing information. Still, use of static tables may also be considered by sites where operational conditions (e.g. very low mail traffic outside the community) do not require external access to a dynamic infrastructure. The principal goal of the first phase of Project Long Bud is to deploy a small number of directory-capable MTA's operated by members of the MHS- DS Working Group and GO-MHS community. These MTA's 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. This initial set of MTA's should be operational by July 1993. Prerequisites for reaching the goal are: * The X.500 DIT must be populated with enough routing information to allow the participating MTA's to route messages to each other and to the existing GO-MHS community. * The X.500 DSA's holding the routing information must operate at a quality of service that is acceptable for an operational R&D X.400 service. * A sufficient number of MTA managers must be willing to participate in Project Long Bud. Alvestrand et al. Expires: November 25, 1993 [Page 2] INTERNET--DRAFT Introducing Project Long Bud June 14, 1993 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 MTA's in the GO-MHS community. This will allow for full connectivity between the Long Bud community and the GO-MHS community. In the second phase of Project Long Bud, a greater number of MTA's should be added to the experiment. Now it is quite possible that the set of destinations reached in Project Long Bud may be different from that which can be convenientlyreached using the GO-MHS table-based approach, and it is therefore important to make tools that can take information from the DIT and produce routing tables foruse in GO-MHS and vice versa. 2.2 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 COSINE/GO-MHS service. 2.3 Tools Needed To facilitate widespread deployment of MHS-DS routing technology and to foster interworking between directory-capable MTA's and MTA's which are not directory-capable, the following tools need to be developed: PutRoutes : this tool will accept routing information, specified in the standard syntax used by the GO-MHS community (see [RFC 1465]), and it will create and/or update X.500 directory entries which convey the same information. GetRoutes : this tool 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. Alvestrand et al. Expires: November 25, 1993 [Page 3] INTERNET--DRAFT Introducing Project Long Bud June 14, 1993 DisplayRoute : this tool will 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. These tools should be implemented using Internet standard API's such as LDAP so that they can be ported easily to multiple platforms. Other standard APIs (e.g. X/Open XDS) will be used when sufficiently deployed in the Internet community. 2.4 Time Frame Long Bud, Phase 1 : July 1993 Phase 1 of the project should be operational by July 1993 so that it can be demonstrated at the IETF meeting in Amsterdam. The DisplayRoute tool should be available in this time frame too so that it can be used as a demonstration device. PutRoutes, GetRoutes : June 1993 These tools will facilitate interworking between directory-capable MTA's and MTA's which are not directory-capable. Availability of these tools is, therefore, very important, but they are not absolutely needed for initial deployment of Phase 1, nor are they absolutely needed as demonstration devices at the IETF meeting in Amsterdam. Nevertheless, the estimated completion date for these tools, if achieved, will allow them to be incorporated into existing GO-MHS procedures (i.e. the AUSSIE tools developped by the COSINE-MHS Service) and will also allow them to be demonstrated in Amsterdam. 3 Participation Guide The existing operational R&D X.400 service, the GO-MHS service, uses the method described hereafter to distribute and manage X.400 routing information. A group of MTA's is organized into a routing community. The community keeps its routing information up to date by assigning the following responsibilities to each MTA manager: 1. Determining the routing information for his/her MTA. 2. Expressing this routing information using the formal syntax defined by and for the community. Alvestrand et al. Expires: November 25, 1993 [Page 4] INTERNET--DRAFT Introducing Project Long Bud June 14, 1993 3. Sending the routing information to a central e-mail coordination center (EMCC) that validates this data against all of the other routing information received from all of the other MTA's in the community. After verification is complete, the EMCC releases the data to the general community. 4. Receiving the verified routing information via electronic mail or some other means. Note that the verified routing information is distributed by the EMCC on an unscheduled basis, as soon as information needs to be updated. 5. Converting the routing information, if necessary, into the format required by his/her local MTA and integrating it with any other local routing information needed. 6. Updating his/her MTA configuration with the new, integrated routing information. Note that this step is a local decision and, as such, is not synchronized with the other MTA's in the community. 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 MTA's. It will allow the Internet X.400 community to overcome the limitations in scalability which it currently is encountering. 3.1 Prerequisites for participati on The prerequisites for joining Project Long Bud are made of different steps organized as follows: Step 1 : participants in the pilot must have a good knowledge of the IETF MHS-DS Workin 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 Alvestrand et al. Expires: November 25, 1993 [Page 5] INTERNET--DRAFT Introducing Project Long Bud June 14, 1993 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 relavent tools and documents stored on the Project Long Bud anonymous FTP server (host name: ftp.css.cdc.com, directory: pub/mhs-ds). 3. If not already done, participants must upgrade their X.400 and X.500 software to a level which conforms to, at least, [Kille 92]. 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 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 create an entry for the local directory-capable MTA 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. Before any routing is entered in the DIT, participants must check with the EMCC (COSINE-MHS Coordination Service) that the routes they want to register can be properly handled by the GO-MHS community. It is crucial for the Pilot that any routing information entered in the Directory is kept carefully accurate for the experiment to be meaningful. Once the above step is validated by the EMCC, participants must record routing information for their MTA(s) in the Internet X.500 directory service. This Alvestrand et al. Expires: November 25, 1993 [Page 6] INTERNET--DRAFT Introducing Project Long Bud June 14, 1993 requires that a participant does one of: 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 help 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. Once the above testing is completed, send email to the mhs-ds distribution list announcing the establishment of new X.500-based routes. 3.2 Benefits Participants in Project Long Bud will become free from having to maintain static X.400 routing information. In addition, participating MTA's will be able to discover more optimal and more direct routes to X.400 destinations than are practical today. X.400 mail managers in the GO-MHS Community should then be released from the knowledge of 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 LongBud approach should bring to the participating organization better control for 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. The Long Bud Pilot wishes to demonstrate that the X.500 Directory is able to provide a global scale service to messaging applications. Author's Address Harald T. Alvestrand Sintef Delab N-7034 Trondheim, Norway Phone: +47-7-59-70-94 E-mail: Harald.T.Alvestrand@delab.sintef.no Alvestrand et al. Expires: November 25, 1993 [Page 7] INTERNET--DRAFT Introducing Project Long Bud June 14, 1993 Kevin E. Jordan Control Data Systems, Inc. 4201 Lexington Avenue North Arden Hills, MN 55126, USA Phone: 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 E-Mail: Sylvain Langlois@der.edf.fr James A. Romaguera NetConsult AG Mettlenwaldweg 20a 3037 Herrenschwanden, Switzerland Phone: +41-31-235750 EMail: romaguera@netconsult.ch X.400: S=romaguera;O=netconsult;P=switch;A=arcom;C=ch References [Hagens et al. 93] R.A. Hagens and A. Hansen. Operational Requirements for X.400 Management Domains in the GO-MHS Community. X400-OPS Internet-Draft draft-ietf-x400ops-mgtdomains-ops-05.txt (working draft). March 1993. [Kille 92] S.E. Kille. MHS use of Directory to support MHS routing. MHS-DS Internet-Draft draft-ietf-mhsds-mhsuse-02.txt (working draft). November 1992. [Kille 92] S.E. Kille. A simple profile for MHS use of the Directory. MHS-DS Internet-Draft draft-ietf-mhsds-mhsprofile-02.txt (working draft). November 1992. [RFC 1465] U. Eppenberger. Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing. May 1993. Alvestrand et al. Expires: November 25, 1993 [Page 8] Sylvain ---------------- Sylvain Langlois (Sylvain.Langlois@der.edf.fr)