A024012@RUTVM1.BITNET (Ross Patterson) (07/28/87)
I posted a copy of Bill Westfield's question to IBMTCP-L@CUNYVM.BITNET,
which discusses IBM's new TCP/IP for VM/SP program (IBM program #5798-FAL,
not to be confused with WiscNet (5798-DRG)). It elicited two reponses,
one from Jay Elinsky at IBM's Watson Research Center, and one from John
Shriver at Proteon. Both are enclosed below.
Ross Patterson
Rutgers University
------------------ Start of included file TCPIP REPLIES -----------------
Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1161;
Mon, 27 Jul 87 17:47:57 EDT
Received: by CUNYVM (Mailer X1.23b) id 8954; Mon, 27 Jul 87 17:47:06 EDT
Date: Monday, 27 Jul 1987 17:39:33 EDT
Reply-To: IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
Sender: IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
From: Jay Elinsky <ELINSKY@YKTVMX>
Subject: Does IBM TCP/IP source route all its packets?
To: Ross Patterson <A024012@RUTVM1>
If he's referring to the IP source routing options e.g. strict
source routing, the answer is No. On Token Ring, we use Token
Ring source routing for packets that must pass through bridges.
Jay Elinsky
IBM T.J. Watson Research Center
Yorktown Heights, NY
---------------------------
Received: from CUNYVM(MAILER) by RUTVM1 (Mailer X1.24) id 1245;
Mon, 27 Jul 87 19:10:26 EDT
Received: by CUNYVM (Mailer X1.23b) id 3703; Mon, 27 Jul 87 19:08:54 EDT
Date: Mon, 27 Jul 87 18:58:50 EDT
Reply-To: IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
Sender: IBM TCP/IP For VM List <IBMTCP-L@CUNYVM>
X-To: IBMTCP-L%CUNYVM.BITNET@WISCVM.WISC.EDU
From: "John A. Shriver" <JAS@MONK.PROTEON.COM>
Subject: Re: Does IBM TCP/IP source route all its packets?
To: Ross Patterson <A024012@RUTVM1>
In-Reply-To: Jay Elinsky's message of Monday,
27 Jul 1987 17:39:33 EDT <8707272226.AA25652@monk.proteon.com>
Yes, it indeed source routes.
A bit of background on how the 802.2 class 2 does it's source routing.
When opening a connection, the first thing done in 802.2 is to swap
XID (exchange ID) packets, to see that you both speak class 2. The
calling interface sends the XID to the called address as a normal
packet. If it does not get "address recognized" in the frame status
byte after some number of tries, it decides the called host is
off-ring. It then modifies the XID packet to set the U bit of the
source address (I call this "bridge-me"), and to include an empty
routing information field (RIF) with the broadcast (all rings) bit
set. Each bridge will add it's entry to the RIF. The called party
will receive the XID, and will (1) store the source route in the
connection block, (2) clear the broadcast bit in the RIF, (3) flip the
direction bit in the RIF, and (4) update the XID information and send
the packet back. The caller will receive the reply XID, and store
that source route in the connection block.
The IBM and TI 802.2 software does not offer this convenience for
class 1 operations. Probably the main reason is that there is no
connection block to store the data in. This does not bother the
architects of source routing, since all IBM applications (except
TCP/IP) use class 2. The network layer is repsonsible for developing
and providing RIF fields.
However, since TCP/IP uses ARP to find addresses, there is a
convenient broadcast packet to use to thread bridges. You just send
the ARP as a "all rings" broadcast, setting the "bridge-me" bit and
the broadcast bit in the RIF.
This does not make for a standard ARP implementation. You've got to
add an entry to the data blocks for the RIF, as well as the hadrware
address, for each protocol (IP) address. You've also got to extend
the calling interface into the datalink, but only for 802.5. This is
not clean when you are trying to use the same code to support multiple
datalinks or network protocols at the same time.
The details of what IBM did for ARP/source routing in each TCP/IP
vary. In the PC version, they do not try and do a "this ring only"
broadcast before doing an "all rings" braodcast. (This is due to the
way PC/IP does ARP without a seperate ARP task). Thus it cannot make a
connection with an implementation that does not source route. Other
versions have a switch to turn on source routing (eg AIX?). It would
be nice if all versions tried without RIF first, looking for addresses
recognized, to talk to other versions that don't do RIFs. Only if
they don't get address recognized would they start trying to
source-route via ARP.
Another thought: one way to make this clean would be to switch to a
special ARP hardware type just for 802.5, and put the RIF in as part
the hardware address. This would make code a lot cleaner, since 802.2
also has to support non-source-route LANs, like 802.3 and 802.4.
------------------ End of included file TCPIP REPLIES -----------------