X400 Operations Group U. Eppenberger Internet Draft SWITCH March 3 1992 Routing coordination for X.400 MHS services within a multi protocol / multi network environment Status of this Memo This memo defines a specification on how the routing of X.400 services within the Internet community and other networking communities can be managed. The distribution of this memo is unlimited. 1. Introduction The usage of the X.400 Message Handling System (MHS) is growing rapidly, especially 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 however, 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 how these problems can be solved in the short term. 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. 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 and Paul-Andre Pays. Tom Oliphant did an excellent proofreading job. 2. Terminology MHS community One or more MHS domains form together an MHS community. Mail exchange between these MHS domains is defined by the coordination procedures within this document. An example of an MHS community is the global X.400 MHS service. Eppenberger [Page 1] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 MHS domain One or more MHS subtrees form together 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: C=CH; ADMD=ARCOM; PRMD=SWITCH; O=SWITCH; MHS domain of SWITCH in Switzerland, consisting of all mailboxes with C=CH; ADMD=ARCOM; PRMD=SWITCH; O=SWITCH; in the OR address. WEP Well known Entry Point, an X.400 MTA serving one or several MHS domains. 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 IXI 1,4 RARE-IXI RARE connectionless pilot 2 RARE-CLNS Internet 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. Eppenberger [Page 2] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 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. 4. Outline of the proposal This proposal offers a solution for describing information about X.400 message routing within an MHS community in WEP and DOMAIN documents. Basic information on the MHS community is documented in the corresponding COMMUNITY document. 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 WEP and DOMAIN documents. An MHS community must agree on its own set of mandatory and optional networks and stacks. 4.2 The WEP document Every MHS domain in the community may designate one or more MTAs as WEPs. These WEPs accept incoming connections from the WEPs of the other MHS domains and in return are allowed to send messages to these WEPs. A WEP is documented with all the needed connection information in the corresponding WEP 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 WEPs 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. An MHS domain may also decide not to operate a WEP. It will then only need agreements with one or more WEPs from other MHS domains which will relay for this domain. The domain itself, however, must always create a DOMAIN document. Eppenberger [Page 3] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 The structure of the DOMAIN document is very straightforward. It starts of 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 relaying WEP(s) are listed with appropriate priorities. 4.4 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 WEPs joining the service are tested and support is given to create the WEP document. - New MHS domains joining the MHS community get assistance to set up WEP(s) and find appropriate relaying WEP(s) and to create DOMAIN documents. - Updated documents are announced to the WEP managers. - All the WEP and DOMAIN documents are made available on a file server together with the COMMUNITY document. The file server must at least be reachable via email. MHS communites 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 WEPs. The format of the documents has especially been choosen to enable the use of automated tools. 4.5 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. Common to each community is that each WEP is connected to each other WEP where technically possible. This creates a meshed network with as few hops as possible and the possibility of integrating backup WEPs to avoid single points of failure. The WEP managers must be aware that a large number of WEPs in an MHS community may require significant operational recources to keep the local routing tables up-to-date and to constantly monitor the correct functioning of the connections. MHS communities may decide on additional mandatory requirements for the operation of a WEP. These may include a hot line, echo services, exchange of statistics, response time to problem reports, uptime of the WEP, etc. This will ensure a certain quality of service for the end users. Each MHS community must define update procedures for the routing based on the documention. Automated update has to be studied carefully. An MHS community should also define procedures for new WEPs and MHS Eppenberger [Page 4] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 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. 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 [] means optional {} means repeated one or more times 'CR' is a Carriage Return and means that the next section starts on its own line. The definition is complete only to a certain level of detail. Below this level, all expressions are to be replaced with text strings. The format and semantics should be clear from the names of the expressions and the comments given. Expressions without more detailed definition are marked with single quotes '. Comments may be placed anywhere in the document but only on separate lines. Such a comment line must start with a '#' sign followed by a space. If the information on a line in a document exceeds 80 characters, it is suggested to do line wrapping according RFC822: Continue on the second line with a leading space. 5.1 Basic Definitions ::= \ \ { } \ { } ::= "Community: " 'community name' 'CR' # The 'community name' is a string identifying the MHS community to # be used in the first line of all documents. ::= "C=" 'Two Character Country Code ISO-3166' \ [";ADMD=" 'ADMDname' ] \ [ ";PRMD=" 'PRMDname' ] \ ";MTAname=" 'MTAname' # A unique key is needed to identify the WEP. In addition to the MTA # name itself, it is proposed to use OR address attributes of the # management domain where the WEP resides. ADMD and PRMD fields are # both optional and may be used to guarantee uniqueness of the key. # The values used are irrelevant. Even non-printable characters like # @ or ! are acceptable. The result is not an address but a key # string. Eppenberger [Page 5] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 ::= "C=" 'Two Character Country Code ISO-3166' \ ";ADMD=" 'ADMDname' \ [ ";PRMD=" 'PRMDname' ] \ [ ";O=" 'Organization-name' ] \ [ { ";OU=" 'OrganizationalUnit-name' } ] \ ";S=" 'surname' \ [ ";G=" 'given name'] 'CR' # This is a restricted subset of the possibilities allowed by the # Standard for an OR address. ::= "Address: " 'CR' ::= [{"; " }] ::= {"+" " " " " \ } ::= 'international prefix' ::= 'area code' ::= 'local telefone number' ::= "Phone: " 'CR' # One or more phone numbers ::= "FAX: " 'CR' # One or more FAX numbers ::= "Mail: " 'postal address information' 'CR' # The items of the postal address are separated by '/' wherever # the next item goes onto the next line for the label. # Example: # Mail: SWITCH Head Office/Urs Eppenberger/Limmatquai 138/ # CH-8001 Zurich/Switzerland # results in the following mailing label: # SWITCH Head Office # Urs Eppenberger # Limmatquai 138 # CH-8001 Zurich # Switzerland Eppenberger [Page 6] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 ::= "Update: DATE=" 'yymmdd' \ ["; START=" 'yymmdd'] \ ["; END=" 'yymmdd'] 'CR' # The date of the last update of a document is given in the # form 'yymmdd'. # An optional start date can be set. A document can be published this # way before the information in it is valid. (This is especially # useful in absence of automated tools. WEP managers get more time to # prepare their systems.) # An end date is used to set an expiration date for the document. 5.2. The COMMUNITY document ::= \ \ # At this place the Community-Identifier is specified. It is # recommended to add a few comment lines to describe the members of # this MHS community. ::= {} ::= \ # Set of contact information for the coordination point ::= [{}] \ [{]} # All documents must be available at least to the managers of the MHS # domains and the WEPs through an email server. If FTAM and FTP are # also available, the generation of automated update tools is much # easier. # It is suggested to have a single server. If there is only one, # knowing a single X.400 OR address will allow you to reach the # server. However for FTP and FTAM more system addresses may be # possible depending on the number of available network connections # (or service types as they are called in this document). ::= "Mail-server: " 'CR' # The email address of the file server. ::= "FTP-server: " 'domain name' "; " 'account-name' ["; " 'password'] 'CR' # In addition to the domain name of the server, an account name # and a password is given. In most cases this will probably be # something like "anonymous" and "guest". ::= "FTAM-server: " 'P-address' "; " \ ["; " 'password'] 'CR' Eppenberger [Page 7] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 ::= 'String encoded Presentation Address' # The format of this string follows RFC1xxx, a string encoding # of Presentation Address. ::= {} \ {[]} # At least one service type is mandatory. ::= "Mandatory-Service: " 'CR' ::= "Optional-Service: " 'CR' ::= "/" \ "/" \ ::= 'Name of a network' # The network-name string identifies a network. A well known # key word should be choosen. (No '/' character is allowed.) # Examples: Public-X.25, Internet, RARE-IXI, RARE-CLNS, WIN, ::= "X.25" | "CONS" | "CLNS" | "TCP" # One of the four values identiefies the 'network service' used. # (TCP is considered a network service together with RFC1006) ::= "TP0" | "TP2" | "TP4" | "RFC1006" # The service type consists of a string with three parts concatenated # with a "/": # Network-name/Network-service/Transport-Protocol. # Since network and stack information forms one string, it identifies # in an easy way a connection possibility between to WEPs. The # community document defines the strings to be used in the WEP and # DOMAIN documents. Some examples: # Internet/TCP/RFC1006 # Public-X.25/X.25/TP0 # RARE-IXI/CONS/TP0 # RARE-CLNS/CLNS/TP4 # (It is probably important to mention here that this string has # nothing to do with the format of a presentation address as defined # by Steve Hardcastle-Kille in RFC1278. The problem of networks using # the same address structure (X.121 DTEs, 4 Byte Internet addresses) # but not beeing connected is not addressed in RFC1278 but solved by # using the proposed service identifier above in addition to the # presentation address. As long as there are network islands, there is # no other way than the addition of an 'island'-identifier. As soon as # all systems have an NSAP and are connected to a global OSI network, # this problem will disappear.) Eppenberger [Page 8] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 5.3. The WEP document ::= \ \ \ # A WEP document contains the full description of a single WEP. # Only one community is allowed. Since some of the information # is community dependent, it would not be easily possible to # have a single WEP document used in different communities. ::= "WEP: 'CR' ::= # More than one set of connection information may be present for # WEPs supporting several networks and protocol stacks. ::= \ { } \ [] ::= "Password: used" | "Password: not used" 'CR' # The usage of passwords significantly increases the effort to # establish a connection. The password is not documented but must be # exchanged during connection configuration by other means. This line # just expresses wether a password is used at all. ::= "C: " "; " "; " \ 'CR' # Very short key word to save space! For easier usage all # information related to the connection is placed in one entry. # However multiple lines may be used if, for example, X.400(84) # and X.400(88) are supported. ::= "MTS-T" | "MTS-TP" | "MTS-TP-84" # MTS-T: mts-transfer # MTS-TP: mts-transfer-protocol # MTS-TP-84: mts-transfer-protocol-1984 # See ISO 10021-6, Section 3, chapter 11.1 for more details on this # matter. X.400(84) systems only support mts-transfer-protocol-1984. ::="R: " "; " 'CR' # Since called and calling network addresses may differ in # certain configurations and some X.400 systems do validation # on calling network addresses, it is important to have this # information in the WEP document also. ::= "System: COM=" 'wep computer type' "; " \ "OPS=" 'wep operating system' "; " \ "MHS=" 'wep MHS software' 'CR' # It is optional to provide HW/SW information. Experience, Eppenberger [Page 9] INTERNET-DRAFT Routing Coordination for X.400 Services February 1992 # however, has shown that a number of communication problems # were more easily identified and solved with this information # present and up-to-date. ::= { \ } # It is important to have the name of a 'real' person. # For email, however, distribution lists and aliases # (i.e. postmaster, WEP-manager, ...) may be used. ::= "Name: " 'name of person' 'CR' # The name of the WEP manager is given. The issue of the character set # problem is not addressed in this document. In general one should # restrict itself to IA5. ::= "RFC822: " 'CR' # This is the RFC-822 address of the WEP manager. It is often a big # help to know the RFC822 address of the WEP manager, for example if # the X.400 system is not reachable. ::= "Reachable: " {