Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!CERNVAX.BITNET!kik
From: kik@CERNVAX.BITNET.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Message-ID: <8702170807.AA26038@cernvax.UUCP>
Date: Tue, 17-Feb-87 03:07:53 EST
Article-I.D.: cernvax.8702170807.AA26038
Posted: Tue Feb 17 03:07:53 1987
Date-Received: Tue, 17-Feb-87 23:17:42 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 44
Approved: tcp-ip@sri-nic.arpa

Path: cernvax!kik
From: kik@cernvax.UUCP (kik)
Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans
Subject: IEEE/Blue Book problem and MAC-level bridges
Message-ID: <439@cernvax.UUCP>
Date: 17 Feb 87 08:07:52 GMT
References: <12277078297.16.ROMKEY@XX.LCS.MIT.EDU>
Reply-To: kik@cernvax.UUCP ()
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw
Lines: 33
 
    The discussion on MAC-level bridging seems to have concentrated so  far
on  the  difference  between  the Ethernet 2.0 and IEEE 802.3 formats (i.e.
Type/length field).  What seems considerably more worrying is  the  problem
raised  by  the  IBM  insistence  for the acceptance by the standardisation
bodies of their "source-level routing" for Token Ring (TR).
 
   For those of you in the happy state of ignorance about this approach, it
works  as  follows:  for  an unknown MAC-level address, an enquiry frame is
broadcast through all TR-bridges,  which  add  their  own  address  to  the
recorded  route.  The  bridge  on the ring that carries the desired address
returns the  enquiry  (with  the  recorded  route)  to  the  enquirer.  All
subsequent  frames  to this address then carry this routing (ISO level 3!!)
information directly after the destination and source address fields  (i.e.
before  the  LLC).  In  addition,  to  indicate  that  source routing is in
action, the source address has the "casting" bit (least significant of most
significant byte) set.
 
     One can imagine the excitement that this sort of frame will  cause  if
it  appears  via a (normal) bridge on an Ethernet segment.  Even if the IBM
pollution is purged by an intelligent bridge,  the  reverse  path  for  the
response  is  somewhat  problematical,  and  would entail maintaining a "TR
routing table" in the bridge.
 
     It is clear that the IBM approach is (to say the least) not  optimised
for  a  connectionless environment.  What is not clear, however, is whether
it has *any* advantages over a true MAC-level bridge.
 
     I would be grateful for clarification from people who understand  both
approaches more cpmpletely than I.
 
                      Crispin (KIK) Piney
 
CERN, Geneva, Switzerland