IEN 180 Danny Cohen USC / ISI March 1981 A suggestion for internet message forwarding for MOSIS ------------------------------------------------------ Messages are forwarded across (between) networks by Message Forwarding Programs (MFP) which live on hosts with access to more than one network. Note that in this discussion the term NETWORK means a message system. These message systems typically live on different networks but this is not necessarily so. The operation of the scheme is based on the following two fields: - FSR: Forward-Source-Route, and - RSR: Return-Source-Route. These two field are to be included in the BODY of the messages. However, the TO, the FROM and the SUBJECT fields, mentioned later in this note, are the native ones of the message systems in use, if any. The basic operation of an MFP is: - To verify that this message was indeed sent to it (this MFP), by comparing the first address in the FSR field with its (the MFP's) address. This address is expacted to be the same as the TO field (if any) of the message in the previous hop, augmented by the designation of that network. - To direct each message to its next destination which is the second address in the FSR field. - To appends to the beginning of the the RSR its own (the MFP's) address as used in the environment to which the message is forwarded. This is expacted to be the same as the FROM field (if any) of the message in its next hop, augmented by the designation of that network. -1- Each address in the FRS should contain an indication (designation) of the network to which the message should be forwarded. This indication has to be stripped before forwarding the message to that environment because most (all?) networks do not recognize the fact that their address space (name space) does not cover the entire universe. Similarly, when any address is appended to the RSR the name of the network in which it is valid has to be included, too. If the final destination of the FSR is an MFP then it will not be forwarded any further, obviously. Similarly, if a MFP is asked to forward a message to an environment (net) to which it has no immediate access it may (i) discard the message, (ii) discard the messages and send an error message to the originator, or (iii) cooperate with a smarter MFP which is as smart as internet gateways and can figure how to get there from here. For the MOSIS application, type-(i) MFPs will suffice. When the message arrives to its final destination, the FSR field includes only the address of this destination. Similarly, when a message leaves its source, the RSR field includes only the address of this source. It is suggested that the SUBJECT field will be carried through without changes, whenever possible. Hence, it is an End/End entity. It is also suggested that all the other header fields (i.e., except the SUBJECT field) will be discarded at each MFP. -2- E x a m p l e Suppose that S on net-A wants to send a message to R on net-C. Suppose also that S knows that MFP-1 has access both to net-A and to net-B, and that MFP-2 has access both to net-B and to net-C. The addresses of MFP-1 are a1 and b1 on nets A and B, respectively, and those of MFP-2 are b2 and c2 on nets B and C. While traversing net-A (from S to MFP-1) the message will have the following format: To: a1 From: S FSR: [A] a1 // [B] b2 // [C] R RSR: [A] S While traversing net-B (from MFP-1 to MFP-2) the message will have the following format: To: b2 From: b1 FSR: [B] b2 // [C] R RSR: [B] b1 // [A] S While traversing net-C (from MFP-2 to R) the message will have the following format: To: R From: c2 FSR: [C] R RSR: [C] c2 // [B] b1 // [A] S While traversing net-C (from R to MFP-2) the reply will have the following format: To: c2 From: R FSR: [C] c2 // [B] b1 // [A] S RSR: [C] R and so on. Note that the total number of addresses, in both the FSR and the RSR fields, does not change while traversing the IN-environment. -3- An Actual Proposal for InterMailing ----------------------------------- We propose to implement the above by having a TOPS-20 program running in [ISIF]. This program would run periodically, every 10 minutes or so and check the mail box of this directory. Any message which is found there will be forwarded according to its FSR list. Messages with bad format or illegal FSR or RSR will not be forwarded, and NO error message will be sent anywhere. Hence, they are discarded for all practical purposes. Such illegal messages are those without an FSR starting within the first 20 lines, bad format, any network (i.e., mail system) not served yet, first net in the RSR not same as in the FSR, etc. The format of the FSR is a contiguous set of lines each of the format: "FSR: []
" where is either "ARPANET" or "TELEMAIL" (more may be added later) and
is a mail box address in that mail-system. Note that the net designation must be in brackets. The RSR is of similar format as the FSR except that each of its lines starts with "RSR:" instead of "FSR:". The first RSR line must follow immediately the last FSR line, without any blank lines in between. The addresses of this InterMailer are: On the ARPAnet side: InterMail@ISIF, and On the TELEMAIL side: InterMail/USCISI. Hence, a message from the user FOO at UCLA on TELEMAIL addressed to MOSIS at ISIF on the ARPAnet may have the following lines when given to TELEMAIL for delivery via InterMail/USCISI: FSR: [TELEMAIL]InterMail/USCISI FSR: [ARPAnet] MOSIS@ISIF RSR: [TELEMAIL]FOO/UCLA The return message from MOSIS may have the following lines when given to the ARPAnet for delivery via InterMail@ISIF: FSR: [ARPAnet] InterMail@ISIF FSR: [TELEMAIL]FOO/UCLA RSR: [ARPAnet] MOSIS@ISIF -4-