rfc1801.txt

RFC 的详细文档！


RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


8.1  Routing Tree Definition

   Each community has a model of the O/R address space.  Within a
   community, there is a general model of what to do with a given O/R
   Address.  This is structured hierarchically, according to the O/R
   address hierarchy.  A community can register different possible
   actions, depending on the depth of match.  This might include
   identifying the MTA associated with a UA which is matched fully, and
   providing a default route for an O/R address where there is no match
   in the community --- and all intermediate forms.  The name structure
   of a routing tree follows the O/R address hierarchy, which is
   specified in a separate document [15].  Where there is any routing
   action associated with a node in a routing tree, the node is of
   object class routingInformation, as defined in Section 10.

8.2  The Open Community Routing Tree

   The routing tree of the open community starts at the root of the DIT.
   This routing tree also serves the special function of instantiating
   the global O/R Address space in the Directory.  Thus, if a UA wishes
   to publish information to the world, this hierarchy allows it to do
   so.

   The O/R Address hierarchy is a registered tree, which may be
   instantiated in the directory.  Names at all points in the tree are
   valid, and there is no requirement that the namespace is instantiated
   by the owner of the name.  For example, a PRMD may make an entry in
   the DIT, even if the ADMD above it does not.  In this case, there
   will be a "skeletal" entry for the ADMD, which is used to hang the
   PRMD entry in place.  The skeletal entry contains the minimum number
   of entries which are needed for it to exist in the DIT (Object Class
   and Attribute information needed for the relative distinguished
   name).  This entry may be placed there solely to support the
   subordinate entry, as its existence is inferred by the subordinate
   entry.  Only the owner of the entry may place information into it.
   An analogous situation in current operational practice is to make DIT
   entries for Countries and US States.

---------------------------------------------------------------------

routingTreeRoot OBJECT-CLASS ::= {
    SUBCLASS OF {routingInformation|subtree}
    ID oc-routing-tree-root}

                  Figure 1: Location of Routing Trees

---------------------------------------------------------------------




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


8.3  Routing Tree Location

   All routing trees follow the same O/R address hierarchy.  Routing
   trees other than the open community routing tree are rooted at
   arbitrary parts of the DIT. These routing trees are instantiated
   using the subtree mechanism defined in the companion document
   "Representing Tables and Subtrees in the Directory" [15].  A routing
   tree is identified by the point at which it is rooted.  An MTA will
   use a list of routing trees, as determined by the mechanism described
   in Section 9.  Routing trees may be located in either the
   organisational or O/R address structured part of the DIT. All routing
   trees, other than the open community routing tree, are rooted by an
   entry of object class routingTreeRoot, as defined in Figure 1.

8.4  Example Routing Trees

   Consider routing trees with entries for O/R Address:

    P=ABC; A=XYZMail; C=GB;

   In the open community routing tree, this would have a distinguished
   name of:

    PRMD=ABC, ADMD=XYZMail, C=GB

   Consider a routing tree which is private to:

    O=Zydeco Services, C=GB

   They might choose to label a routing tree root "Zydeco Routing Tree",
   which would lead to a routing tree root of:

    CN=Zydeco Routing Tree, O=Zydeco Services, C=GB

   The O/R address in question would be stored in this routing tree as:

    PRMD=ABC, ADMD=XYZMail
    C=GB, CN=Zydeco Routing Tree,
    O=Zydeco Services, C=GB

8.5  Use of Routing Trees to look up Information

   Lookup of an O/R address in a routing tree is done as follows:

   1.  Map the O/R address onto the O/R address hierarchy described in
       [15] in order to generate a Distinguished Name.





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


   2.  Append this to the Distinguished Name of the routing tree, and
       then look up the whole name.

   3.  Handling of errors will depend on the application of the lookup,
       and is discussed later.

   Note that it is valid to look up a null O/R Address, as the routing
   tree root may contain default routing information for the routing
   tree.  This is held in the root entry of the routing tree, which is a
   subclass of routingInformation.  The open community routing tree does
   not have a default.

   Routing trees may have aliases into other routing trees.  This will
   typically be done to optimise lookups from the first routing tree
   which a given MTA uses.  Lookup needs to take account of this.

9.  Routing Tree Selection

   The list of routing trees which a given MTA uses will be represented
   in the directory.  This uses the attribute defined in Figure 2.

   ---------------------------------------------------------------------

   routingTreeList ATTRIBUTE ::= {
           WITH SYNTAX RoutingTreeList
           SINGLE VALUE
           ID at-routing-tree-list}

   RoutingTreeList ::= SEQUENCE OF RoutingTreeName

   RoutingTreeName ::= DistinguishedName

                   Figure 2: Routing Tree Use Definition

   ---------------------------------------------------------------------

   This attribute defines the routing trees used by an MTA, and the
   order in which they are used.  Holding these in the directory eases
   configuration management.  It also enables an MTA to calculate the
   routing choice of any other MTA which follows this specification,
   provided that none of its routing trees have access restrictions.
   This will facilitate debugging routing problems.

9.1  Routing Tree Order

   The order in which routing trees are used will be critical to the
   operation of this algorithm.  A common approach will be:




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


   1.  Access one or more shared private routing trees to access private
       routing information.

   2.  Utilise the open routing tree.

   3.  Fall back to a default route from one of the private routing
       trees.

   Initially, the open routing tree will be very sparse, and there will
   be little routing information in ADMD level nodes.  Access to many
   services will only be via ADMD services, which in turn will only be
   accessible via private links.  For most MTAs, the fallback routing
   will be important, in order to gain access to an MTA which has the
   right private connections configured.

   In general, for a site, UAs will be registered in one routing tree
   only, in order to avoid duplication.  They may be placed into other
   routing trees by use of aliases, in order to gain performance.  For
   some sites, Users and UAs with a 1:1 mapping will be mapped onto
   single entries by use of aliases.

9.2  Example use of Routing Trees

   Some examples of how this structure might be used are now given.
   Many other combinations are possible to suit organisational
   requirements.

9.2.1  Fully Open Organisation

   The simplest usage is to place all routing information in the open
   community routing tree.  An organisation will simply establish O/R
   addresses for all of its UAs in the open community tree, each
   registering its supporting MTA. This will give access to all systems
   accessible from this open community.

9.2.2  Open Organisation with Fallback

   In practice, some MTAs and MDs will not be directly reachable from
   the open community (e.g., ADMDs with a strong model of bilateral
   agreements).  These services will only be available to
   users/communities with appropriate agreements in place.  Therefore it
   will be useful to have a second (local) routing tree, containing only
   the name of the fallback MTA at its root.  In many cases, this
   fallback would be to an ADMD connection.

   Thus, open routing will be tried first, and if this fails the message
   will be routed to a single selected MTA.




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


9.2.3  Minimal-routing MTA

   The simplest approach to routing for an MTA is to deliver messages to
   associated users, and send everything else to another MTA (possibly
   with backup).

   An organisation using MTAs with this approach will register its users
   as for the fully open organisation.  A single routing tree will be
   established, with the name of the organisation being aliased into the
   open community routing tree.  Thus the MTA will correctly identify
   local users, but use a fallback mechanism for all other addresses.

9.2.4  Organisation with Firewall

   An organisation can establish an organisation community to build a
   firewall, with the overall organisation being registered in the open
   community.  This is an important structure, which it is important to
   support cleanly.

    o  Some MTAs are registered in the open community routing tree to
       give access into the organisation.  This will include the O/R tree
       down to the organisational level.  Full O/R Address verification
       will not take place externally.

    o  All users are registered in a private (organisational) routing
       tree.

    o  All MTAs in the organisation are registered in the organisation's
       private routing tree, and access information in the organisation's
       community.  This gives full internal connectivity.

    o  Some MTAs in the organisation access the open community routing
       tree.  These MTAs take traffic from the organisation to the
       outside world.  These will often be the same MTAs that are
       externally advertised.

9.2.5  Well Known Entry Points

   Well known entry points will be used to provide access to countries
   and MDs which are oriented to private links.  A private routing tree
   will be established, which indicates these links.  This tree would be
   shared by the well known entry points.

9.2.6  ADMD using the Open Community for Advertising

   An ADMD uses the open community for advertising.  It advertises its
   existence and also restrictive policy.  This will be useful for:




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


    o  Address validation

    o  Advertising the mechanism for a bilateral link to be established

9.2.7  ADMD/PRMD gateway

   An MTA provides a gateway from a PRMD to an ADMD. It is important to
   note that many X.400 MDs will not use the directory.  This is quite
   legitimate.  This technique can be used to register access into such
   communities from those that use the directory.

    o  The MTA registers the ADMD in its local community (private link)

    o  The MTA registers itself in the PRMD's community to give access to
       the ADMD.

10.  Routing Information

   Routing trees are defined in the previous section, and are used as a
   framework to hold routing information.  Each node, other than a
   skeletal one, in a routing tree has information associated with it,
   which is defined by the object class routingInformation in Figure 3.
   This structure is fundamental to the operation of this specification,
   and it is recommended that it be studied with care.