X400 Operations Group U. Eppenberger Internet Draft SWITCH 11 November 1992 Expires: May 1993 Routing coordination for X.400 MHS services within a multi protocol / multi network environment Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. It is intended that this document will be submitted to the IESG for consideration as a experimental standard. Distribution of this document 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 Eppenberger Expires: May 1993 [Page 1] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 information. The format has been designed to allow the information to be stored in a X.500 directory service while managers without directory service access may still use a table based approach. 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. 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. 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: 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. WEP Well known Entry Point, an X.400 MTA serving one or several MHS domains. (Note that this term is used here in a different way than in the early X.400ies (1987/88), where WEP has been used as the term for an X.400 MTA serving a whole country.) 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. Eppenberger Expires: May 1993 [Page 2] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 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 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. 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. All contact persons and WEP 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. Eppenberger Expires: May 1993 [Page 3] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 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 primary 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. Optional WEPs may be added, generally with higher priority, to allow more precise routing. 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. 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 The PERSON document All administrators and responsible persons are documented in PERSON documents. The COMMUNITY, WEP and DOMAIN documents contain just keys pointing to a PERSON document. If such a person can already be found in a 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 Eppenberger Expires: May 1993 [Page 4] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 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, 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 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.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 kind of mail relays are defined, the primary WEPs and the secondary WEPs. All primary and secondary WEPs allow incoming connections from each other. The primary WEPs can decide if they also use more precise routing and send to the secondary WEPs too. A secondary WEP must connect to at least one primary WEP. 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 documentation. Automated update has to be studied carefully. Eppenberger Expires: May 1993 [Page 5] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 An MHS community should also define procedures for new WEPs 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 support this by allowing mandatory and optional WEPs. All WEPs accept incoming connections from each other. Sending messages can be done by using the mandatory WEPs only. This allows new WEPs to join the community as optional and to get mandatory status when traffic flow increases. 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 ()...is used to group choices '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 '. Since the documents should still be 'human readable', it is possible to use multiple spaces wherever at least one space is required. Please note that for some field values the number of spaces is significant. Comments may be placed anywhere in the document but only on separate lines. Such a comment line must either start with a '#' sign followed by white space and the comment or consist of a single '#' on a single line. If the information on a line in a document exceeds 80 characters, it is suggested to do line wrapping according RFC822: Wrap the line at any convenient place, generally at a white space, then continue on the second line with leading white space. Some field values are case sensitive (TSAP, Password). In order to handle this issue in a consistent way all keys and values must use the same case as the BNF definitions. Eppenberger Expires: May 1993 [Page 6] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 5.1 Basic Definitions ::= \ \ { } \ { } \ { } A set of one COMMUNITY document and several WEP, DOMAIN and PERSON documents belong together. ::= 'Distinguished Name' The string representation of a Distinguished Name is defined in the IETF OSI-DS document 23. It is still an Internet Draft, but the latest version is very likely to be accepted at the Nov '92 IETF meeting. If a Distinguished Name is used as a key in the documents, then the information can be fetched from the directory instead of checking the appropriate document. However the same information must also be present in a document as long as not all managers in the same community have directory access. ::= "Community: " \ ('community name' | ) 'CR' The 'community name' is a string identifying the MHS community to be used in the first line of all documents. ::= ([ "P=" 'PRMDname' "; " ] \ ["A=" 'ADMDname' "; " ] \ "C=" "; " \ "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. A Distinguished Name may be used instead. ::= ( | ) A unique key is needed to make the links from the documents where a responsible person or an administrator is needed to the PERSON documents. It is either the OR address of the person or a Distinguished Name (if the person is already registered in the directory). ::= 'Two Character Country Code ISO-3166' Eppenberger Expires: May 1993 [Page 7] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 ::= 'OR address, ISO 10021-2 Annex F' See Appendix B for a brief description of this format. It has been used consequently all over the document. This explains also the syntax of the and the . ::= "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 a printed address label. Especially if the community spans several countries it does make sense to give the full address including the country. 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 ::= "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. Eppenberger Expires: May 1993 [Page 8] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 ::= 'String encoded Presentation Address' The format of this string follows RFC1278, A string encoding of Presentation Address and RFC1277, Encoding Network Addresses to support operation over non-OSI layers. See chapter 5.2 about the usage of macros in a Presentation Address. ::= "/" \ "/" \ ::= '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 identifies 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 two 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 Expires: May 1993 [Page 9] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 ::= ["OU4=" 'OrganizationalUnit-name' "; "] \ ["OU3=" 'OrganizationalUnit-name' "; "] \ ["OU2=" 'OrganizationalUnit-name' "; "] \ ["OU1=" 'OrganizationalUnit-name' "; "] \ ["O=" 'Organization-name' "; "] \ ["P=" 'PRMDname' "; "] \ "A=" 'ADMDname' "; " \ "C=" ";" 5.2 The COMMUNITY document ::= \ \ The first line of the COMMUNITY document specifies the to be used in the header of all other documents belonging to the same community. 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". Eppenberger Expires: May 1993 [Page 10] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 ::= "FTAM-server: " \ ('P-address' | ) "; " \ ["; " 'password'] 'CR' The account name is often case sensitive. Some FTAM server offer anonymous access with the account-name ANON. Documenting a FTAM server with a Distinguished Name is only allowed if the server is registered in the directory. ::= "Macro: " 'Macro name' " " \ 'Macro value' 'CR' Presentation addresses without the usage of macros are generally unreadable. RFC1278 suggests a few macros. All macros which are allowed in a communities must be defined in the community document. It is recommended to use the proposed macros in RFC1278 and add new ones if necessary: Macro: Int-X25(80) TELEX+00728722+X25(80)+01+ Macro: Janet-X25(80) TELEX+00728722+X25(80)+02+ Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+ ::= {} \ {[]} At least one service type is mandatory. ::= "Mandatory-Service: " \ 'CR' ::= "Optional-Service: " \ 'CR' 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' ::= \ ::= "Status: " ("primary" | "secondary") This defines if the WEP has 'primary' or 'secondary' status. See section 4.3 and 6 for more information. Eppenberger Expires: May 1993 [Page 11] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 ::= \ {} \ [] \ [] \ [] More than one set of connection information may be present for WEPs supporting several networks and protocol stacks. ::= "Password: " \ ("***secret***" | "***none***" | 'password') 'CR' If the keyword ***none*** is present, then no password is used. If the keyword ***secret*** is present, then the connection needs a password which is not made publicly available. The community might for example decide to keep a list of the passwords at the central coordination point. The list is then faxed to the WEP managers. If any other string is present, then this is the password to be used for the connection. ::= \ [ ] ::= "RTS-dialog-mode: " \ ("TWA" | "MONOLOGUE") 'CR' ::= "RTS-checkpoint-size: " \ 'checkpoint size' 'CR' ::= "RTS-window-size: " \ 'window size' 'CR' ::= "Called-address: " \ "; " \ "; " 'CR' ::= "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. Eppenberger Expires: May 1993 [Page 12] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 ::= "Calling-address: " \ "; " \ '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. (Note: a calling X.121 address might change if the X.25 switch is reconfigured. This will stop a WEP from connecting to other WEPs using address validation without having changed anything at the higher layers!) ::= "System: COM=" 'computer type' "; " \ "OPS=" 'operating system' "; " \ "MHS=" 'MHS software' 'CR' It is optional to provide HW/SW information. Experience,however, has shown that a number of communication problems were more easily identified and solved with this information present and up-to-date. ::= "LocalDomain: " 'CR' This is a useful but optional extension to the documentation. Such an address should be routed through the WEP or even end up on the WEP. This is not a routing definition! The LocalDomain attributes might be used together with S=nosuchuser to do connectivity and availability tests. ::= "EchoServer: " 'CR' Some of the WEPs might offer an echo server functionality. It does make sense to document this in the WEP document for test purpose. This field is optional. ::= {"Administrator: " 'CR'} The contact details for the WEP administrator can be found in the appropriate PERSON document. It is possible to document a whole team using a distribution list if this is desired. It is generally better to document one or more 'real' persons. 5.4 The DOMAIN document ::= \ \ ::= {} \ {} ::= "Domain: " 'CR' Eppenberger Expires: May 1993 [Page 13] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 ::= ( "* " | "= " ) This qualifier defines how the following OR address attributes should be handled for the routing algorithm. If a '*' is present, a destination address of a message is matched by the "Domain:" entry if at least the OR address attributes in the "Domain:" entry are equal to the destination address. If a "=" is present, a destination address of a message is matched by the "Domain:" entry if there are exactly the same OR attributes in the destination address as in the "Domain:" entry. (This restriction works for OU*, O, P, A and C only.) Example: a) Domain: * P=switch; A=arcom; C=ch; b) Domain: = P=switch; A=arcom; C=ch; The address S=eppenberger; P=switch; A=arcom; C=ch; matches both cases, a) and b). The address S=eppenberger; O=unibe; P=switch; A=arcom; C=ch; matches only case a). Note that it is not allowed to have equal lines in different DOMAIN documents belonging to the same MHS community. An MHS subtree can only appear in one DOMAIN document. ::= {"Administrator: " 'CR'} This is the person responsible for the listed domains. His task is to get the agreement of the relaying WEPs and keep the DOMAIN document up-to-date. This person is the only one authorized to make changes to this document. ::= "WEP: " \ 'UniqueWEPkey' "; " \ "; " \ 'CR' \ [ { "Net: " "; " \ 'CR' } ] A WEP has a default priority and a delay field. The priority is used to define the sequence in which different WEPs may be tried in case of failure. The delay defines how long a sending WEP needs to wait until it is allowed to select this WEP in case the connection to the preferred WEP has failed. It is also possible to set different priorities on each network type. This may be chosen, for example, to distribute the load amongst different networks according to their available bandwith. ::= ::= Eppenberger Expires: May 1993 [Page 14] INTERNET-DRAFT Routing Coordination for X.400 Services November 1992 ::= The exact meaning of these values and how they should be used is explained in the next section. 5.5 The PERSON document ::= \ \ \ ::= "Key: " 'CR' ::= {} {} \ ::= "Name: " 'name of person' 'CR' The name of the person is given. The issue of the character set problem is not addressed in this document. Especially international communities should restrict themselves to IA5. ::= "RFC822: " 'CR' This is the RFC-822 address of the person. It is often a big help to know the RFC822 address of someone, for example if the X.400 system is not reachable. This is also the reason why it is possible to provide multiple OR and RFC822 addresses. The first one is considered the primary one. ::= "Reachable: " {