rfc1801.txt

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

Network Working Group                                           S. Kille
Request for Comments: 1801                              ISODE Consortium
Category: Experimental                                         June 1995


   X.400-MHS use of the X.500 Directory to support X.400-MHS Routing

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Table of Contents

  1   Introduction                                                     3
  2   Goals                                                            3
  3   Approach                                                         5
  4   Direct vs Indirect Connection                                    6
  5   X.400 and RFC 822                                                8
  6   Objects                                                          9
  7   Communities                                                     10
  8   Routing Trees                                                   11
      8.1    Routing Tree Definition   .   .   .   .   .   .   .      12
      8.2    The Open Community Routing Tree   .   .   .   .   .      12
      8.3    Routing Tree Location     .   .   .   .   .   .   .      13
      8.4    Example Routing Trees     .   .   .   .   .   .   .      13
      8.5    Use of Routing Trees to look up Information   .   .      13
  9   Routing Tree Selection                                          14
      9.1    Routing Tree Order    .   .   .   .   .   .   .   .      14
      9.2    Example use of Routing Trees  .   .   .   .   .   .      15
          9.2.1    Fully Open Organisation     .   .   .   .   .      15
          9.2.2    Open Organisation with Fallback     .   .   .      15
          9.2.3    Minimal-routing MTA     .   .   .   .   .   .      16
          9.2.4    Organisation with Firewall  .   .   .   .   .      16
          9.2.5    Well Known Entry Points     .   .   .   .   .      16
          9.2.6    ADMD using the Open Community for Advertising      16
          9.2.7    ADMD/PRMD gateway   .   .   .   .   .   .   .      17
  10  Routing Information                                             17
      10.1   Multiple routing trees    .   .   .   .   .   .   .      20
      10.2   MTA Choice    .   .   .   .   .   .   .   .   .   .      22
      10.3   Routing Filters   .   .   .   .   .   .   .   .   .      25
      10.4   Indirect Connectivity     .   .   .   .   .   .   .      26
  11  Local Addresses (UAs)                                           27
      11.1   Searching for Local Users     .   .   .   .   .   .      30
  12  Direct Lookup                                                   30
  13  Alternate Routes                                                30



Kille                         Experimental                      [Page 1]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


      13.1   Finding Alternate Routes  .   .   .   .   .   .   .      30
      13.2   Sharing routing information   .   .   .   .   .   .      31
  14  Looking up Information in the Directory                         31
  15  Naming MTAs                                                     33
      15.1   Naming 1984 MTAs  .   .   .   .   .   .   .   .   .      35
  16  Attributes Associated with the MTA                              35
  17  Bilateral Agreements                                            36
  18  MTA Selection                                                   38
      18.1   Dealing with protocol mismatches  .   .   .   .   .      38
      18.2   Supported Protocols   .   .   .   .   .   .   .   .      39
      18.3   MTA Capability Restrictions   .   .   .   .   .   .      39
      18.4   Subtree Capability Restrictions   .   .   .   .   .      40
  19  MTA Pulling Messages                                            41
  20  Security and Policy                                             42
      20.1   Finding the Name of the Calling MTA   .   .   .   .      42
      20.2   Authentication    .   .   .   .   .   .   .   .   .      42
      20.3   Authentication Information    .   .   .   .   .   .      44
  21  Policy and Authorisation                                        46
      21.1   Simple MTA Policy     .   .   .   .   .   .   .   .      46
      21.2   Complex MTA Policy    .   .   .   .   .   .   .   .      47
  22  Delivery                                                        49
      22.1   Redirects     .   .   .   .   .   .   .   .   .   .      49
      22.2   Underspecified O/R Addresses  .   .   .   .   .   .      50
      22.3   Non Delivery  .   .   .   .   .   .   .   .   .   .      51
      22.4   Bad Addresses     .   .   .   .   .   .   .   .   .      51
  23  Submission                                                      53
      23.1   Normal Derivation     .   .   .   .   .   .   .   .      53
      23.2   Roles and Groups  .   .   .   .   .   .   .   .   .      53
  24  Access Units                                                    54
  25  The Overall Routing Algorithm                                   54
  26  Performance                                                     55
  27  Acknowledgements                                                55
  28  References                                                      56
  29  Security Considerations                                         57
  30  Author's Address                                                58
  A   Object Identifier Assignment                                    59
  B   Community Identifier Assignments                                60
  C   Protocol Identifier Assignments                                 60
  D   ASN.1 Summary                                                   61
  E   Regular Expression Syntax                                       71
  List of Figures
      1      Location of Routing Trees     .   .   .   .   .   .      12
      2      Routing Tree Use Definition   .   .   .   .   .   .      14
      3      Routing Information at a Node     .   .   .   .   .      17
      4      Indirect Access   .   .   .   .   .   .   .   .   .      25
      5      UA Attributes     .   .   .   .   .   .   .   .   .      27
      6      MTA Definitions   .   .   .   .   .   .   .   .   .      33
      7      MTA Bilateral Table Entry     .   .   .   .   .   .      36



Kille                         Experimental                      [Page 2]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


      8      Bilateral Table Attribute     .   .   .   .   .   .      37
      9      Supported MTS Extensions  .   .   .   .   .   .   .      39
      10     Subtree Capability Restriction    .   .   .   .   .      40
      11     Pulling Messages  .   .   .   .   .   .   .   .   .      41
      12     Authentication Requirements   .   .   .   .   .   .      43
      13     MTA Authentication Parameters     .   .   .   .   .      45
      14     Simple MTA Policy Specification   .   .   .   .   .      46
      15     Redirect Definition   .   .   .   .   .   .   .   .      48
      16     Non Delivery Information  .   .   .   .   .   .   .      50
      17     Bad Address Pointers  .   .   .   .   .   .   .   .      52
      18     Access Unit Attributes    .   .   .   .   .   .   .      53
      19     Object Identifier Assignment  .   .   .   .   .   .      59
      20     Transport Community Object Identifier Assignments        60
      21     Protocol Object Identifier Assignments    .   .   .      61
      22     ASN.1 Summary     .   .   .   .   .   .   .   .   .      61

1.  Introduction

   MHS Routing is the problem of controlling the path of a message as it
   traverses one or more MTAs to reach its destination recipients.
   Routing starts with a recipient O/R Address, and parameters
   associated with the message to be routed.  It is assumed that this is
   known a priori, or is derived at submission time as described in
   Section 23.

   The key problem in routing is to map from an O/R Address onto an MTA
   (next hop).  This shall be an MTA which in some sense is "nearer" to
   the destination UA. This is done repeatedly until the message can be
   directly delivered to the recipient UA. There are a number of things
   which need to be considered to determine this.  These are discussed
   in the subsequent sections.  A description of the overall routing
   process is given in Section 25.

2.  Goals

   Application level routing for MHS is a complex procedure, with many
   requirements.  The following goals for the solution are set:

 o  Straightforward to manage.  Non-trivial configuration of routing
    for current message handling systems is a black art, often
    involving gathering and processing many tables, and editing
    complex configuration files.  Many problems are solved in a very
    ad hoc manner.  Managing routing for MHS is the most serious
    headache for most mail system managers.

 o  Economic, both in terms of network and computational resources.





Kille                         Experimental                      [Page 3]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


 o  Robust.  Errors and out of date information shall cause minimal
    and localised damage.

 o  Deal with link failures.  There needs to be some ability to choose
    alternative routes.  In general, it is desirable that the routing
    approach be redundant.

 o  Load sharing.  Information on routes shall allow "equal" routes
    to be specified, and thus facilitate load sharing.

 o  Support format and protocol conversion

 o  Dynamic and automatic.  There shall be no need for manual
    propagation of tables or administrator intervention.

 o  Policy robust.  It shall not allow specification of policies which
    cause undesirable routing effects.

 o  Reasonably straightforward to implement.

 o  Deal with X.400, RFC 822, and their interaction.

 o  Extensible to other mail architectures

 o  Recognise existing RFC 822 routing, and coexist smoothly.

 o  Improve RFC 822 routing capabilities.  This is particularly
    important for RFC 822 sites not in the SMTP Internet.

 o  Deal correctly with different X.400 protocols (P1, P3, P7), and
    with 1984, 1988 and 1992 versions.

 o  Support X.400 operation over multiple protocol stacks (TCP/IP,
    CONS, CLNS) and in different communities.

 o  Messages shall be routed consistently.  Alternate routing
    strategies, which might introduce unexpected delay, shall be used
    with care (e.g., routing through a protocol converter due to
    unavailability of an MTA).

 o  Delay between message submission and delivery shall be minimised.
    This has indirect impact on the routing approaches used.

 o  Interact sensibly with ADMD services.

 o  Be global in scope





Kille                         Experimental                      [Page 4]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


 o  Routing strategy shall deal with a scale of order of magnitude
    1,000,000 -- 100,000,000 MTAs.

 o  Routing strategy shall deal with of order 1,000,000 -- 100,000,000
    Organisations.

 o  Information about alterations in topology shall propagate rapidly
    to sites affected by the change.

 o  Removal, examination, or destruction of messages by third parties
    shall be difficult.  This is hard to quantify, but "difficult"
    shall be comparable to the effort needed to break system security
    on a typical MTA system.

 o  As with current Research Networks, it is recognised that
    prevention of forged mail will not always be possible.  However,
    this shall be as hard as can be afforded.

 o  Sufficient tracing and logging shall be available to track down
    security violations and faults.

 o  Optimisation of routing messages with multiple recipients, in
    cases where this involves selection of preferred single recipient
    routes.

The following are not initial goals:

 o  Advanced optimisation of routing messages with multiple
    recipients, noting dependencies between the recipients to find
    routes which would not have been chosen for any of the single
    recipients.

 o  Dynamic load balancing.  The approach does not give a means to
    determine load.  However, information on alternate routes is
    provided, which is the static information needed for load
    balancing.

3.  Approach

   A broad problem statement, and a survey of earlier approaches to the
   problem is given in the COSINE Study on MHS Topology and Routing [8].
   The interim (table-based) approach suggested in this study, whilst
   not being followed in detail, broadly reflects what the research
   X.400 (GO-MHS) community is doing.  The evolving specification of the
   RARE table format is defined in [5].  This document specifies the
   envisaged longer term approach.





Kille                         Experimental                      [Page 5]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


   Some documents have made useful contributions to this work:

 o  A paper by the editor on MHS use of directory, which laid out the
    broad approach of mapping the O/R Address space on to the DIT [7].

 o  Initial ISO Standardisation work on MHS use of Directory for
    routing [19].  Subsequent ISO work in this area has drawn from
    earlier drafts of this specification.

 o  The work of the VERDI Project [3].

 o  Work by Kevin Jordan of CDC [6].

 o  The routing approach of ACSNet [4, 17] paper.  This gives useful
    ideas on incremental routing, and replicating routing data.

 o  A lot of work on network routing is becoming increasingly
    relevant.  As the MHS routing problem increases in size, and
    network routing increases in sophistication (e.g., policy based
    routing), the two areas have increasing amounts in common.  For
    example, see [2].

4.  Direct vs Indirect Connection

   Two extreme approaches to routing connectivity are:

   1.  High connectivity between MTAs.  An example of this is the way
       the Domain Name Server system is used on the DARPA/NSF Internet.
       Essentially, all MTAs are fully interconnected.