summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1802.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1802.txt')
-rw-r--r--doc/rfc/rfc1802.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc1802.txt b/doc/rfc/rfc1802.txt
new file mode 100644
index 0000000..3d27638
--- /dev/null
+++ b/doc/rfc/rfc1802.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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
+ 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 the
+
+
+
+Alvestrand, 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.500
+
+
+
+Alvestrand, 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 Tree
+
+
+
+Alvestrand, 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 1995
+
+
+8. 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=ch
+
+
+
+
+
+
+
+
+
+
+Alvestrand, et al Informational [Page 11]
+