LIANE%SBU.UFRGS.ANRS.BR@uicvm.uic.edu (07/10/90)
One of my students is just about to start his master degree dissertation on a computer science program. He has been working on our local MHS implementation and have experience with the design/implementtaion of the MTA. We considered that a possible topic for his dissertation could focus on an expert system to help the routing of the messages (selecting the best route or the least expensive way to send a message, for instance). Could some of you provide some feedback/new ideas/other suggestions about the topic selected/other topics to be considered? Thanks in advance Liane Tarouco University Federal of Rio Grande do Sul Institut of Informatics Porto Alegre - RR - Brazil
kit@gateway.mitre.ORG (07/12/90)
Dear Liane Tarouco, There are several interesting real-world issues concerning routing for MHS implementations. I would be very interested in any results of a study or paper in this area. I am working on a project for the Department of Defense (US) on some messaging systems and upgrades of existing non-X.400 networks. One major routing issue relates to whether an MTA may route a message directly to the recipient or whether the MTA has to route the message via a gateway or conversion system. This would be applicable to the world in general, such as in cases where some MTAs perform conversion (e.g., between IA5Text, Telex, Fax, Teletex, etc.), and so the MTAs have to do routing to the MTAs that support the conversion. The example from my project is that there are some User Agents (UAs) that support the Secure Data Network Service (SDNS) Message Security Protocol (MSP) [which uses a double-enveloping of the P2 or P22 or other content into a new content type of P48], and other UAs that do not support MSP. The issue is that if the same MTA supports both UAs, the MTA needs to know whether it can route the message directly to a UA or route it to a conversion/gateway facility. The MTA may touch the message twice, and needs to route it differently the two times, and not think that there is a routing loop. A specific example is that a UA sends a non-msp message to the MTA, the MTA routes it to the MSP gateway, the gateway does the conversion and sends it back to the MTA, and then the MTA routes it to the destination UA. There also is a question about whether the resulting delivery notice routes via the gateway or whether it goes directly to the originating UA. (Since it may be a special MSP-encoded DN, it may have to go through the MSP Gateway.) The only solution I see (if we are using Commercial Off-The-Shelf MTAs) is to divide the network into two sub-networks, where one sub-network is for the UAs that support MSP and the other is for those that do not; but then you need separate MTAs in the two sub-nets, which people are unhappy about. Another general issue is the extent to which a generalized X.500 directory service may be used by MTAs to perform routing. X.500 information is address information that is descriptive of the user or user agent or other entity. The information returned from the directory query is independent of the location of the requestor. Therefore, while address information can be returned that describes the location of the destination, it cannot contain next-hop routing info. The issue here is that I am not aware of standardized addressing info that would be consistently used by different MTAs for routing. (Note that the MTAs probably need separate tables that indicate next-hop routing from the address info returned from the directory.) There are other miscellaneous issues: Blank ADMD name: Where in X.400 ORAddress the Country and PRMD (or organization) are present, but the ADMD (which is a mandatory field) contains a value of a single blank character. This means that the ORAddress identifies a user who is not affiliated with a particular ADMD. ADMDs need to know how to route to these users (without the ORAddress telling them which ADMD supports the user). The Delivery Notice may route back via a different ADMD than the one that handled the message. This may especially be an issue if PRMD or Organization names are not nationally unique. Multinational organizations: For large corporations or international organizations (e.g., NATO), how is addressing/routing to be supported, since all addresses require country fields. If a US representative to NATO is stationed in Belgium (for example), what country is used, and how is routing done? Also, there is the issue of least-cost routing and shortest-path routing. If a large organization has several connections to an ADMD (such as on the east coast and the west coast in the USA), can the ADMD route to the correct connection to achieve the shortest path? Or might a message that originates in the ADMD on the East coast get sent via the connection on the west coast, even though the recipient is located in the east (i.e., the sender and receiver are both on the east coast, but the message was routed via the west coast.). Addressing: You cannot totally separate routing and addressing, since one impacts the other. Using a different PRMD name for each MTA (or a different Organization or Org Units name) is user-unfriendly, since then the user addressing is tied into the topology of the network. If the topology changes, the user address changes. Other addressing issues relate to the fact that some X.400 implementations use Domain Defined Attributes (DDAs) to convey additional addressing information, which may be used for routing. National restricions: I heard that some countries do not allow encrypted messages to be passed, which may affect routing. Also, some national X.400 dialects may not be routed outside the country (e.g., Japan uses Kanji character set in the X.400 ORAddress, which violates the PrintableString definition, for Japan domestic users). Avoiding 1984 MTAs: If the two end-system MTAs and UAs are based upon 1988 X.400, but there are intermediate systems which are based upon 1984 X.400, the 1988 MTAs may want to route in a way to avoid the 1984 MTAs, so that the 1988 X.400 extensions are not discarded. Preferred means of delivery: The directory (or other entry) description may indicate the preferred means of delivery for a recipient user (e.g., mail box, fax, telex, teletex, postal delivery), so the MTA may need to route the message differently based upon this. Also, alternate recipient, redirection, deferred delivery, Distribution List use or expansion, grade of delivery, may all tie in with routing. Also, routing may dynamically change based upon what connections are inoperative or overloaded. Also, small messages may be routed one way, while large messages may be sent via high-bandwidth connections (e.g., satellite, which has a delay time but high throughput), or large but low-priority messages may be deferred until off-peak times. Kit Lueder, MITRE Corporation. (I am repeating the message to which I am responding, below.) Date: Tue, 10 Jul 90 09:01 C From: LIANE%SBU.UFRGS.ANRS.BR@uicvm.uic.edu Subject: sugestion for MS thesis solicited One of my students is just about to start his master degree dissertation on a computer science program. He has been working on our local MHS implementation and have experience with the design/implementtaion of the MTA. We considered that a possible topic for his dissertation could focus on an expert system to help the routing of the messages (selecting the best route or the least expensive way to send a message, for instance). Could some of you provide some feedback/new ideas/other suggestions about the topic selected/other topics to be considered? Thanks in advance Liane Tarouco University Federal of Rio Grande do Sul Institut of Informatics Porto Alegre - RR - Brazil
Stef@nrtc.northrop.COM (Einar Stefferud) (07/12/90)
Hello Liane -- I suspect that you are looking for a more general toic thatn the ones identified by Kit Leuder, so here are some other observations. First, it is clear from looking at the overall routing question that a realy useful MTA is going to have to be much more sophiticated than most of the current crop which like to only route on a subset of the standard attributes of ORAddresses, and whcih act like it is a sin to pay any attention to a DDA. The bottom line is that the winning implementation is going to have to pay full attention to all the relevant facotrs in routing and allow for very sophisticated rules to be tabled and applied. Every available per-user attribute with a value should be legitimately used to form keys to routing tables. For example (as Kit mentioned) conversion is a factor and so conversion (requested/prohibited/etc) information in P1 must be usefully employed. So must DDA values and anything else. It is likely that accouting (billing) information should be considered, else a PRMD operator will have no way to engage in what I call "Bill Control" in whych the PRMD operator sets routing tables to minimize the bills for transferring mail. Also, it is legitimate for multinatrional organizations (NATO comes t mind) will want to form Relaying PRMDs to transfer mail among unitns in different countries without handing mail over to an ADMD, so they will have to route on non-ADMD attriburtes, regardless of what ADMD names in in an ORaddress. So, I simply suggest that your student take as a project the effort to collect all the relevant attributes and values from P1 envelopes and develop ways to use expert system rules to deduce routes from what I would call "complex routing keys" that would be made up of an enriched set of ORAddress attributes and values. The project should also work on ways to cache routes that have been deduced in such a way as to speed recognition of repeated complex keys, and extraction of the resulting route determinations. Cheers...\Stef