Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!daemon From: William "Chops" Westfield Newsgroups: comp.dcom.sys.cisco Subject: Re: cisco - proteon interop on FDDI Message-ID: <35356@boulder.Colorado.EDU> Date: 24 May 91 09:08:16 GMT Sender: daemon@boulder.Colorado.EDU Lines: 63 > Exactly right. "transit bridging" == "encapsulating bridging". > Nearly guaranteed not to interoperate with any other vendor. Are you saying that cisco can't ROUTE to/from a node on FDDI, or does it do that as well ? Sigh. Since you are the second person to mis-interpret my remarks, perhaps a public statement is in order... "encapsulation bridging" or "transit bridging" is a scheme whereby you bridge together a bunch of ethernets, using an FDDI ring as the backbone. This is similar to bridging two ethernets across a T1 line, only different. Each ethernet packet is "encapsulated" entirely (including ethernet headers) inside an FDDI packet. The FDDI packet will be given a type code like "cisco transit bridging", flooding might be done by sending packets to the "cisco transit bridging multicast address", and so on. There are currently no standard values for any of these typecodes or addresses, so each vendor has picked their own, and it is doubtfull that they interoperate WHILE DOING TRANSIT BRIDGING. Eventually, there will probably be a standard, and everyone will eventually support it. "transparent bridging" is reaonsably standardized. You take your ethernet, token ring, or FDDI packets, fiddle their header bits, change back and forth (maybe) between "ethernet" and "SNAP" encapsulation, and send the new packet out on the new interface, where it hopefully looks as though it was originated by a host on the same local media. Cisco currently doesn't support transparent bridging to or from FDDI at all - while not conceptually difficult, transparent bridging potentially requires filtering (discarding) FDDI packets at media rate (400k pps or so). This can be done with special hardware, but it's a bit beyond the capability of even the RISCy VLIW buzzword buzzword bitslice processor on cisco's current FDDI card. In addition, the FDDI chipset needs to be able to tell which frames to strip from the ring, even though neither the source nor destination address matches the local address. This capability is not present in the current implementation either (ah, the curse of being first). So transparent bridges ought to interoperate ok, but they aren't common yet. Of course, WE all know that bridging is a terrible idea anyway, and what one really wants to do is route... The cisco should be compatible with all other FDDI routers for any protocol whose format on FDDI has been defined. I think this includes IP, DECNet, Appletalk (phase 2) and CLNS. In addition, there are a set of protocols whose FDDI formats are "obvious" (eg, same as Token Ring, or ethernet typecodes converted to SNAP), and there is a very good chance we inter-operate with any vendor routing those protocols (I think this includes XNS, Novell, Vines, and 3com). There are some whose encapsulation is somewhat strange (Apollo explicitly made their FDDI encapsulation compatible with transparent bridging to ethernet, rather than the more obvious token-ring like encapsulation). Finally, there are a couple protocols done in the obvious way (ether-->SNAP) that you probably can't find another router to do anyway (PUP, Chaos). Summary: A cisco router/bridge should interoperate correctly with any other vendors' devices on an FDDI ring runnin ANY protocol EXCEPT "transit" or "encapsulation" bridging... Bill Westfield cisco Systems. -------