Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!sdcsvax!ucbvax!MONK.PROTEON.COM!jas
From: jas@MONK.PROTEON.COM (John A. Shriver)
Newsgroups: comp.protocols.tcp-ip
Subject: ... Transmission of IP Datagrams over IEEE 802 ...
Message-ID: <8710221558.AA23939@monk.proteon.com>
Date: Thu, 22-Oct-87 11:58:35 EST
Article-I.D.: monk.8710221558.AA23939
Posted: Thu Oct 22 11:58:35 1987
Date-Received: Sun, 25-Oct-87 14:02:24 EST
References: <8710220534.AA26692@opal.berkeley.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 47

Source routing is not soley in internal 802.5 issue.  Unfortunately
IBM (a/k/a 802.5) source routing IS an LLC issue, and in turn a
Network layer issue.

IBM source routing is implemented in 802.2 class 2 quite
transparently.  When the stations begin their virtual circuit, they
exchange XID messages.  These XID messages are sent as limited
broadcast, and serve as the needle to resolve a source route.  The
source route is stored inside the LLC connection block, and the class
2 application can be completely ignorant of it.  The arguments to
L_DATA_CONNECT.request remain the same for all three of the MAC
layers.  (This is the TRANSMIT.I.FRAME in the PC, you only supply the
data, it provides all LLC and MAC headers.)

The problem is that 802.2 class 1 cannot implement source routing
transparently, or does not in any current IBM implmentation.  It is
the responsibility of the LLC user (the NETWORK layer) to discover and
provide the source route.  Basically, there is an extra argument to
the L_DATA.request in 802.2 of "remote_source_route" ONLY in the case
of 802.5 as the MAC layer.  (This is the TRANSMIT.UI.FRAME in the PC,
you have to supply the LLC & MAC headers, including the Routing
Information Field.)

The reason class 1 is not transparent is very primitive: there is no
connection block to store the source route in.  IBM has no reason to
be concerned, since all of their "important" software uses class 2
(SNA, NetBios).  Unfortunately, the rest of the world (IP, DECnet,
XNS, Novell IPX, Banyan Vines) is using class 1.  So far, only IBM has
tried to implment source routing on any class 1 application, namely
their IP.

The most interesting point to note is that if any of the bridges on a
source route fail, everything goes crazy.  There is no dynamic
recovery implemented.  Your 802.2 class 2 virtual circuit will DIE.
Your class 1 application will have packets black holing.  The frame
copied bits will not provide the sender ANY indication that this is
happening.  (I don't even know if the first-hop bridge sets the frame
copied bit.)  This is distinctly inferior to the current state of the
art in IP, XNS, or DECnet routing, where the routers will find a new
route before the Transport layer times out.

This black-hole phenomenon will cause users to ask for more layering
violations.  As is, ARP has become hardware dependent for 802.5.  Now
people will want to flush the 802.5 ARP/source route cache when a TCP
connection is getting timeouts.  The problem is that one layering
violation usually causes more of them to propogate up through the
layers.