rfc1465.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                     U. Eppenberger
Request for Comments: 1465                                        SWITCH
                                                                May 1993


              Routing Coordination for X.400 MHS Services
          Within a Multi Protocol / Multi Network Environment
                   Table Format V3 for Static Routing

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

1. Introduction

   The usage of the X.400 Message Handling System (MHS) is growing
   rapidly, especially in the commercial world but much interest can
   also be found in the academic and research community.  New networks
   and new addresses come into use each and every day.  The underlying
   technology for different X.400 networks can vary depending on the
   transport network and the X.400 MHS implementations used.  As a large
   number of X.400 implementations now support multiple stacks, this
   offers the chance of implementing a world wide message handling
   service using the same electronic mail standard and, therefore,
   without the need of gateways with service reduction and without the
   restriction to a single common transport network.  This, however,
   leads to several problems for the MHS manager, two of which are:

   - Where do I route new X.400 addresses and

   - How do I connect to a MHS domain that uses an underlying
     technology that I do not support.

   This document proposes short term solutions to these problems.  It
   proposes a strategy for maintaining and distributing routing
   information and shows how messages can travel over different networks
   by using multi stack MTAs as relays.  Document formats and
   coordination procedures bridge the gap until an X.500 directory
   service is ready to store the needed connectivity and routing
   information.  The format has been designed to allow the information
   to be stored in an X.500 directory service while managers without
   directory service access may still use a table based approach.

   The routing structure proposed can be applied to a global MHS service



Eppenberger                                                     [Page 1]

RFC 1465        Routing Coordination for X.400 Services         May 1993


   but may also be used at a national level or even within an
   organisation.

   Many experts from IETF X.400-Operations Group and RARE Working Group
   1 on Message Handling Systems have read drafts of this document and
   contributed ideas and solutions.  I would especially like to thank
   Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan Cargille and
   Paul-Andre Pays.

   This is the third version of a table format.  The first one was in
   use within COSINE-MHS for about two years.  A second version with
   major enhancements was then proposed which has been in use for the
   past year.  The third version will probably be the last one before it
   will be possible to switch to dynamic, directory service based
   routing.

2. Terminology

   MHS community

      One or more MHS domains form an MHS community.  Mail exchange
      between these MHS domains is defined by the coordination
      procedures within this document.  Examples of such communities are
      the Global Open MHS service GO-MHS and the COSINE-MHS service.

   MHS domain

      One or more MHS subtrees form an MHS domain.  This is a purely
      administrative grouping of MHS subtrees.  It is helpful, if
      someone is responsible for several MHS subtrees, to refer to an
      MHS domain instead of listing all the subtrees.

   MHS subtree

      An MHS subtree consists of the total of the mailboxes addressable
      within a subtree of the X.400 OR address space.

        Example:  O=SWITCH; P=SWITCH; A=ARCOM; C=CH;

        MHS domain of SWITCH in Switzerland, consisting of all
        mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the OR
        address.

   RELAY-MTA

      An X.400 MTA serving one or several MHS domains.  Note that the
      term WEP -Well Known Entry Point- has been used since the early
      X.400ies (1987/88) until now, giving the wrong impression of a



Eppenberger                                                     [Page 2]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      single entry point (and therefore a single point of failure).
      This document proposes to use the term RELAY-MTA, reflecting more
      clearly the functionality of the MTA.

   COSINE-MHS

      The COSINE-MHS community is mainly formed by European X.400
      service providers from the academic and research area, each of
      which is a member of RARE.  The COSINE-MHS community is used in
      the annex as an example for the usage of this document in a
      multinational environment.

3. Requirements

   X.400 MTAs can communicate using different transport and network
   protocol stacks.  For this document the stacks used in a WAN
   environment need to be considered:

                           Stack 1    Stack 2    Stack 3    Stack 4

      Transport Layer 4    TP0        TP4        RFC1006    TP0
      Networkservice 1-3   X.25       CLNS       TCP/IP     CONS

   A common protocol stack is not the only requirement to enable
   communication between two MTAs.  The networks to which the MTAs
   belong need to be interconnected.  Some well known networks are
   listed together with the stacks they use.

      Network                                Stack   Abbreviation

      Public Switched Packet Data Networks     1     Public-X.25
      International X.25 Infrastructure EMPB   1,4   EMPB-X.25
      US and European connectionless pilot     2     Int-CLNS
      Internet                                 2,3   Internet

   Note that several stacks may be supported over a single network.
   However communication between MTAs is only possible if the MTAs share
   at least a common stack AND a common network.

   Unlike SMTP/TCP/IP systems, there is no directory service available
   which would allow an MTA to look up the next MTA to which it should
   submit a message.  Routing within X.400 will continue to be table
   based until a solution using X.500 directory services is available.

   Furthermore it is not generally allowed to connect to any MTA even on
   the same network without being registered on the destination MTA.
   These restrictions require a large coordination effort and carefully
   configured and updated systems.



Eppenberger                                                     [Page 3]

RFC 1465        Routing Coordination for X.400 Services         May 1993


4. Outline of the proposal

   This proposal offers a solution for describing information about
   X.400 message routing within an MHS community in RELAY-MTA and DOMAIN
   documents.  Basic information on the MHS community is documented in
   the corresponding COMMUNITY document.  All contact persons and
   RELAY-MTA administrators can be found in PERSON documents.  A future
   X.500 based solution may need extended information to overcome still
   unsolved problems like optimal routing or traffic optimization for
   messages with multiple recipients.  The information collected for the
   intermediate solution however is very basic.  All established
   coordination procedures will help and even speed up the future
   introduction of an X.500 based solution.

4.1 The COMMUNITY document

   For each MHS community there exists one single COMMUNITY document
   containing basic information.  First the contact information for the
   central coordination point can be found together with the addresses
   for the file server where all the documents are stored.  It also
   lists network names and stacks to be used in the RELAY-MTA and DOMAIN
   documents.  An MHS community must agree on its own set of mandatory
   and optional networks and stacks.

4.2 The RELAY-MTA document

   Every MHS domain in the community may designate one or more MTAs as
   RELAY-MTAs.  These RELAY-MTAs accept incoming connections from the
   RELAY-MTAs of the other MHS domains and in return are allowed to send
   messages to these RELAY-MTAs.  A RELAY-MTA is documented with all the
   necessary connection information in the corresponding RELAY-MTA
   document.

4.3 The DOMAIN document

   An MHS domain has a responsible person who sets up the routing
   entries for the domain in the DOMAIN document.  The primary RELAY-
   MTAs listed in the DOMAIN document as serving this MHS domain must,
   TOGETHER, offer at least connectivity to all networks and stacks
   listed as mandatory in the COMMUNITY document.  Optional RELAY-MTAs
   may be added, generally with higher priority, to allow more precise
   routing.

   An MHS domain may also decide not to operate a RELAY-MTA.  It will
   then only need agreements with one or more RELAY-MTAs from other MHS
   services which will relay for this domain.  The domain itself,
   however, must either create its own DOMAIN document or document its
   MHS subtrees jointly with another MHS domain.



Eppenberger                                                     [Page 4]

RFC 1465        Routing Coordination for X.400 Services         May 1993


   The structure of the DOMAIN document is very straightforward.  It
   starts off with one or more MHS subtrees, each on its own line.
   After the domains follows a line indicating the responsible person
   for the MHS subtrees mentioned.  Finally the responsible RELAY-MTA(s)
   are listed with appropriate priorities.

4.4 The PERSON document

   All administrators and responsible persons are documented in PERSON
   documents.  The RELAY-MTA and DOMAIN documents contain just keys
   pointing to a PERSON document.  If such a person can already be found
   in an X.500 directory service, then the key consists of a
   Distinguished Name, else the key is just its OR address.

4.5 Coordination

   This approach requires an identified coordination point.  It is up to
   the MHS community to decide on the level of coordination and support
   to be provided and on the funding mechanisms for such activities.
   Basic information can be found in the COMMUNITY document.  The
   following list of support activities is considered mandatory for an
   operational service:

    - New RELAY-MTAs joining the service are tested and support is
      given to create the RELAY-MTA document.

    - New MHS domains joining the MHS community get assistance to set
      up RELAY-MTA(s) and/or find appropriate RELAY-MTA(s) and to
      create DOMAIN documents.

    - Updated documents are announced to the RELAY-MTA managers and
      responsible persons for the DOMAIN documents unless automatic
      distribution is used.

    - All the RELAY-MTA, DOMAIN and PERSON documents are made
      available on a file server together with the COMMUNITY document.
      The file server must at least be reachable via email.  MHS
      communities with a big number of documents may consider
      additional access methods like ftp and FTAM.

    - Tools should be made available to manage routing tables for the
      X.400 software used on the RELAY-MTAs or to fill in and check
      the documents.  The format of the documents has specifically
      been chosen to enable the use of automated tools.

   The RELAY-MTA managers must be aware that a large number of RELAY-
   MTAs in an MHS community may require significant operational
   resources to keep the local routing tables up-to-date and to



Eppenberger                                                     [Page 5]

RFC 1465        Routing Coordination for X.400 Services         May 1993


   constantly monitor the correct functioning of the connections.  On
   the other hand more than one RELAY-MTA with a good connectivity to an
   MHS domain improves the overall robustness of the domain and thus the
   QOS.

   MHS communities may decide on additional mandatory requirements for
   the operation of a RELAY-MTA.  These may include a hot line, echo
   services, exchange of statistics, response time to problem reports,
   uptime of the RELAY-MTA, etc.  This will ensure a certain quality of
   service for the end users.

4.6 Routing

   The proposal addresses MHS communities spanning several
   organisations.  But it may also be used to manage routing within a
   single organisation or even a global MHS community.

   Two kinds of mail relays are defined, the primary RELAY-MTAs and the
   secondary RELAY-MTAs.  A primary or secondary RELAY-MTA must allow
   incoming connections from all other primary and secondary RELAY-MTAs
   with a common stack.  Primary RELAY-MTAs must be able to connect to
   all other primary RELAY-MTAs which share a common stack.  A secondary
   RELAY-MTA must connect to at least one primary RELAY-MTA.

   Each MHS community must define update procedures for the routing
   based on the documentation.  Automated update has to be studied
   carefully.

   An MHS community should also define procedures for new RELAY-MTAs and
   MHS domains joining the service.  Since the usage of X.400 is growing
   rapidly a flexible but well coordinated way of integrating new
   members into an MHS community is needed.  The proposed documentation
   format supports this by allowing primary and secondary RELAY-MTAs.
   All RELAY-MTAs accept incoming connections from each other.  Sending
   messages can be done by using the primary RELAY-MTAs only.  This
   allows new RELAY-MTAs to join the community as secondary and to get
   primary status when traffic flow increases.  Secondary RELAY-MTAs may
   also require a longer testing period.

5. The documents

   The definition is given in BNF-like syntax.  The following
   conventions are used:


    |    means choice

    \    is used for continuation of a definition over several lines