🚀 go-pugleaf

In article <1992Nov20.231911.8841@umr.edu>, rfranken@mcs213d.cs.umr.edu (Richard Brett Frankenberger) writes:
> In article <1992Nov20.191046.20897@netcom.com> seifert@netcom.com (Rich Seifert) writes:
> >
> >Most IBM LAN systems run NetBIOS directly on top of the Data Link. Because
> >there is no Network Layer, routers are NOT possible. This is, in fact,
> >the reason Source Routing exists in the first place. It is a "mini-Network"
> >Layer protocol embedded into the Data Link.
> >
> >I strongly discourage the use of Source Routing over WANs, since the
> >Explorer (route discovery) traffic is incredibly bandwidth-intensive.
> >  
> I agree with both of these statements; however, they are NOT indications that
> EtherNet is superior.  IBM LAN Systems that run NetBIOS do so because the
> applications they use require it, and they would run NetBIOS over EtherNet
> also.  NetBIOS works on Ethernet or Token-Ring and does require more broadcast
> traffic than other protocols, or it can be encapsulated in IPX or IP
> to reduce some of that traffic.  his is true on E-Net and TR.
>  
> In short, yes, NetBIOS has many limitations, but that is a protocol issue, not
> a network physical layer issue.
>

Agreed. My point was, however, that very few people (none I have seen) run
BetBIOS directly on top of the Ethernet Data Link. While you can IN THEORY
separate the issues of NetBIOS, Source Routing, and Token Ring, IN PRACTICE,
they are often (always?) found together.

This is primarily because IBM is the major computer-manufacturer-proponent
of Token Ring, and IBM systems use NetBIOS and Source Routing. The major
proponents of Ethernet-based systems are DEC, Sun, H-P, Apple, etc., all
of whom use a traditional protocol stack on top of the data link
(TCP/IP, DECnet, AppleTalk, etc.) and transparent bridges. There is
often a NetBIOS interface provided above the Transport to simplify
application migration from system to system.
  
> Also, one can have a token-ring and not use source routing.  Thus, ANY
> limitations of the source-route protocol are limitations of source-routing,
> not of Token-Ring.  There are some situations where source-route is the best
> option, and one that is not available on ethernet.
> 
> >> On ether net, you can get between segments one of two ways.  Transparent
> >> bridges or Routers.  On token-ring, you have those two options PLUS  
> >> Source-Routing.  Source-Routing is just another option.  You don't have
> >> to use it. 
> >>
> >
> >In practice, it is NOT possible to use transparnet bridges in a Token
> >Ring environment. First, they are not made by many manufacturers (although
> >this is an implementation, not an architecvtural problem). More important,
> >IBM Hosts are generally configured with multiple FEPs (3745s) connected
> >to redundant backbones for high availability and load sharing. IBM 
> >configures (actually, the users configure according to IBM recommendations)
> >the two FEPs to have the same MAC address. This is what provides the 
> >redundancy and load sharing. When a route discovery is made to the host, the
> >station may be connecting to either FEP, without regard. This is the reason
> >why IBM makes such widespread use of the Locally administered address
> >space, rather than global addressing used by Ethernet.
> >
> >Transparent bridges require that all devices have unique MAC addresses,
> >otherwise the table learning algorithms are unstable. This is one of
> >the key invariants of the underlying LAN that Transparent bridges
> >demand.
> >  
> There are transparent birdges for Token-Ring (I believe CrossCom, among
> other companies, make them.  Not as widely available as for E-Net, of
> course, but they are available).  You can transparently bridge TR except for 
> the Duplicate MAC address situation you mentioned above.  
>  
> What does your IBM Host statement have to do with a problem with Token-Ring.
> Basically, you are saying there is a problem with Token-Ring because I am
> forced to use source-routeing if I want to redundantly connect FEPs.  I would
> submit that there is, by that logic, an even greater problem with Ethernet
> because I can't do it at all.  If IBM hosts are not being used, then there is
> no problem.  If they are, you can go non-redundant and work with TR and
> transparent bridging or go redundant and use source-route.  Its not as if
> you can go Ethernet and have transparent bridges AND redundancy.  You can't.
>  

No, what I am saying is that the vast majority of Token Ring users are
running 3270-emulation to connect to IBM hosts (in addition to other
applications, of course), and the scenario I described is quite common.
Yes, there are transparent bridge products available for Token Ring,
and the reason you don't see them very often in the real world is because
in most practical situations, they do not work well. A forgotten (or just
unmentioned) problem has to do with whether a bridge should set the A and C
bits in frames. Older applications often depend upon these bits as a low-level
acknowledgement mechanism. It is not possible for transparent Token Ring
bridges to set or clear these bits in any manner that will allow all
applications to operate as they did on a single ring.


-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"