rfc1465.txt

RFC 的详细文档！

   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.

   A message arriving at a RELAY-MTA must either be sent to the next
   RELAY-MTA based on the DOMAIN documents of the MHS community or it is
   sent to an MTA closer to the destination based on local routing
   decisions.  The following algorithm must be used when forwarding a
   message to the next RELAY-MTA:

      1) Select the relevant DOMAIN document by searching for a match of
      the Recipient address in the message with the entries in the
      document.

      If your own RELAY-MTA appears in this list, this indicates one of
      the following:

      - You offered relay services for another RELAY-MTA with higher
        priority.  Continue with step 2 to decide on the next RELAY-MTA.

      - Your RELAY-MTA is the final destination according the DOMAIN
        document of your community.  You need to forward the message to
        the final destination according local routing information.

      2) From the list of RELAY-MTAs select those that have at least one
      common network service type with your own RELAY-MTA.

      3) Now delete all secondary RELAY-MTAs from the list where no
      direct connection is desired.  For remaining RELAY-MTAs in the
      list no difference is made anymore between primary and secondary
      status.

      4) Select from this reduced set of RELAY-MTAs the one with the
      highest RELAY-MTA-priority.  If there is more than one RELAY-MTA



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


      having the same priority, then select a RELAY-MTA of your choice.
      If your own RELAY-MTA appears in that list, then you are not
      allowed to send to a RELAY-MTA with lower or equal priority.

      5) If there are no service-priorities set in the corresponding
      RELAY-MTA document indicating which service type to use, you are
      free to choose the service type for connecting to the RELAY-MTA.
      However, if there are specific priorities set then select the
      service type with the highest priority.

      6) If the connection fails then try other service types in the
      sequence of descending priority.

      7) If no connection works for the selected RELAY-MTA, then check
      in the list for the one with the same priority, if possible, or
      else select one with the next lower priority.  If there is another
      RELAY-MTA with a RELAY-MTA-priority between 0..49, then select it
      and proceed at step 5.  Without another RELAY-MTA to try the
      currently selected RELAY-MTA will be retried.

6.1 How to use RELAY-MTA-priorities

   An example helps to explain the usage of RELAY-MTA-priorities.
   Internet/TCP/RFC1006 and Public-X.25/X.25/TP0 are mandatory service
   types in the community REMOTEmail.  The MHS domain P=REMOTE; A=ARCOM;
   C=CH; operates MTA-B, only connected to public X.25.  A second
   RELAY-MTA which is connected to both, Internet and public X.25 is
   needed to offer relay services.  A connection using Internet is
   considered cheap in this example.  Both service types are available
   at MTA-A.  Since MTA-B is the only RELAY-MTA responsible for relaying
   messages to P=REMOTE; A=ARCOM; C=CH; to the final destination it must
   have the highest priority.

      Community: REMOTEmail
      Domain: * P=REMOTE; A=ARCOM; C=CH;
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 20
      RELAY-MTA:  P=MTA-C; A=ARCOM; C=CH;MTAname=MTA-C; 80

                                       __________________________
      +-------+    X.25     +-------+ (                          )
      | MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
      +-------+             +-------+ (__________________________)
               \           /
         TCP/IP \         /X.25
                 +-------+
                 | MTA-C |
                 +-------+




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


   If MTA-A needs to relay a message for P=REMOTE; A=ARCOM; C=CH; then
   the rules of chapter 6 are evaluated:

        1. MTA-B and MTA-C are possible destinations

        2. MTA-B and MTA-C are reachable from MTA-A

        3. MTA-B is a primary RELAY-MTA (not relevant in this example)

        4. MTA-B has the highest priority.

        5. MTA-B doesn't have specific service type lines documented.
           MTA-A chooses public X.25, since it is the only possibility
           to connect to MTA-B.

        6. No other service types are available if the connection
           fails.

        7. MTA-C has a priority of 80, it is not a backup RELAY-MTA.
           MTA-A must spool the message and try to connect directly to
           MTA-B.

   The organisation running MTA-A could save money by sending messages
   for the MHS domain P=REMOTE; A=ARCOM; C=CH; via MTA-C.  Since the
   connection between MTA-C and the destination MTA-B is also expensive,
   the organisation running MTA-C would have to pay for external relay
   traffic.  Setting a lower priority for MTA-C forces the other RELAY-
   MTAs with public X.25 connectivity to take their share of the cost.

   Note that forcing other RELAY-MTAs to use a specific stack should be
   avoided wherever possible by offering RELAY-MTAs with equal priority
   for all mandatory network services.  This can be an important
   financial issue for MHS communities spanning several organisations,
   it is not relevant in general for an MHS community within a single
   organisation.

6.2 How to use RELAY-MTA-priorities for backup RELAY-MTAS

   Two RELAY-MTAs offer real backup connectivity for the MHS domain
   P=REMOTE; A=ARCOM; C=CH;.  It is therefore possible to set RELAY-MTA
   priorities in the range of 0..49 for both RELAY-MTAs.  MTA-B will be
   the preferred one since it has the higher priority.  If the
   connection to MTA-B fails, a sending RELAY-MTA may immediately try to
   connect to MTA-C.

      Community: REMOTEmail
      Domain: * P=REMOTE; A=ARCOM; C=CH;
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10



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


      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30

                                       __________________________
      +-------+             +-------+ (                          )
      | MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
      +-------+             +-------+ (__________________________)
               \                     /
                \           +-------+
                 -----------+ MTA-C |
                            +-------+

6.3 Load Sharing

   It is possible to set equal priorities to do some sort of load
   sharing.  However, most implementations are not able to do random
   selection of RELAY-MTAs with equal priorities but have a fixed
   configuration.  If load sharing is really needed then it is suggested
   to split up the MHS domain into several MHS subtrees and document
   them separately with a set of RELAY-MTAs with different priorities.

   An example is provided for illustration of the first possibility with
   equal RELAY-MTA-priorities:

      Community: REMOTEmail
      Domain: * P=REMOTE; A=ARCOM; C=CH;
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
          _               __________________________
           )  +-------+  (                          )
           )--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
           )  +-------+  (__________________________)
           )            /
           )  +-------+/
           )--+ MTA-C |
          _)  +-------+

      And here is an example where the MHS domain
    C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org is documented with its own
    DOMAIN document: Note that in this example both RELAY-MTAs serve
    as backup RELAY-MTAs.

      Community: REMOTEmail
      Domain: * P=REMOTE; A=ARCOM; C=CH;
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30

      Community: REMOTEmail
      Domain: * O=Big-Org; P=REMOTE; A=ARCOM; C=CH;



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


      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 30
          _               __________________________
           )  +-------+  (                          )
           )--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
           )  +-------+  (__________________________)
           )           \/
           )           /\ _____________________________________
           )  +-------+  (                                     )
           )--+ MTA-C |--( O=Big-Org; P=REMOTE; A=ARCOM; C=CH; )
          _)  +-------+  (_____________________________________)

7. Open issues

   Currently there are about 35 RELAY-MTAs within the COSINE-MHS
   service.  A rough guess is that a network with about 60 RELAY-MTAs is
   still manageable provided there are automated tools for MTA
   configuration.  If there are more MTAs applying for RELAY-MTA status
   in an MHS community, then either an X.500 based solution should be
   ready or a core set of about 30 well operated super-RELAY-MTAs should
   form a backbone, documented within a specific MHS community.

   Since the RELAY-MTA document contains information about the supported
   X.400 version (84 or 88), it is possible for an X.400(88) system to
   select with higher priority an (88)RELAY-MTA.  The rules in chapter 6
   could be modified to select X.400(88) systems first if the sending
   RELAY-MTA is an (88) system itself.  The issue of how to establish an
   X.400(88) RELAY-MTA infrastructure within an MHS community is for
   further study.






















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


Appendix A:  Document examples for the COSINE-MHS community

   Instead of creating artificial documents to show an example document
   set, this appendix contains extracts from a real operational X.400
   service.  The research and development community in Europe has used
   X.400 for several years.  This proposal was initially written to
   address this community only and solve the urgent routing and
   coordination problems.  Contributions from different experts have
   made it more flexible and therefore hopefully useful for other MHS
   communities.

Appendix A1:  The COMMUNITY document

  Community: COSINE-MHS
  # The COSINE-MHS service is a MHS community formed by the European
  # academic and research networks with additional contacts in all
  # other continents.
  #
  # The coordination is done by the COSINE-MHS project team.
  #
  Update: FORMAT=V3; DATE=921218; START=930201
  #
  Address: S=Project-Team; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
  #
  Phone: [phone]
  Fax:   [phone]
  #
  Mail:  SWITCH Head Office /
         MHS Coordination Service /
         Limmatquai 138 /
         CH-8001 Zurich /
         Switzerland
  #
  Reachable: 09:00-12:00; 14:00-17:30; UTC+1
  #
  Mail-server: S=mhs-server; O=switch; OU1=nic;
               P=SWITCH; A=ARCOM; C=CH;
  FTP-server:  nic.switch.ch; cosine; user@domain
  #
  Macro: Int-X25(80)        TELEX+00728722+X.25(80)+01+
  Macro: Internet-RFC-1006  TELEX+00728722+RFC-1006+03+
  Macro: IXI                TELEX+00728722+X.25(80)+06+
  #
  Mandatory-Service: Public-X.25/X.25/TP0
  # The public X.25 network.  X.25 is supported in most X.400
  # applications and mandatory in X.400 anyhow.
  #
  Mandatory-Service: Internet/TCP/RFC1006



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


  # The Internet, standing for the global TCP/IP network of the
  # research and development community