| The story is pretty convincing. In a nutshell, an encapsulating bridge
takes the entire Ethernet packet and puts is in the data portion of the
FDDI packet, builds an FDDI header and CRC onto it and send it out over
the ring. Since the encapsulating algorithm isn't standardized, each
bridge vendor could use a different encapsulation scheme, so you need
matching vendors bridges to encapsulate/de-encapsulate (Point 1:
Proprietary solution). Since the FDDI packet doesn't have all the
fields translated from the Ethernet packet into it, any node on the
FDDI ring can't understand it, so you can only send from Ethernet node
to Ethernet node, using the FDDI ring as a tunnel (like our portals).
(Point 2: Limited access of your network FDDI nodes talk to other FDDI
nodes, Ethernet nodes talk to other Ethernet nodes, and ne'er the twain
shall meet).
A translating bridge takes each field out of the Ethernet packet,
translates it into the correct format for an FDDI packet and sends it
out on the ring. Since its a "real" FDDI packet now, it can be
addressed to any node in the network, whether it resides on an Ethernet
segment or an FDDI ring. Each vendor who provides a translating bridge
can interoperate with any other translating vendor because the
translation can only have one output format. So, no proprietary
solution.
Digital has chosen to go with the translating approach.
Hope this helps.
Debbie
|