Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/ien/ien180.txt Дата изменения: Tue Jun 26 00:38:42 2001 Дата индексирования: Tue Oct 2 09:26:21 2012 Кодировка:

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-