GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1802

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

  1. - 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.
  1. - 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1802.txt · Last modified: 1995/06/08 21:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki