jas@proteon.com (John A. Shriver) (08/06/90)
The solution seems very simple to me. When an FDDI/Ethernet bridge is passing AppleTalk packets from Ethernet to FDDI, it will have to encapsulate the Phase 1 and Phase 2 packets differently on the FDDI. I would suggest that the phase 2 ones be sent unmodified, and that the phase 1 ones be sent with a different SNAP code. (Perhaps Apple's prefix followed by the EtherTalk Ethernet type (80-9B), rather than 00-00-00-80-9B.) The converse would be done on the other end. The same would have to be done for AppleARP. This makes sense in a lot of ways. Apple has basically set the precedent that 802.2 networks are phase 2 only. Look at 802.5, it only supports phase 2. FDDI is in the same boat. I would note that the FDDI/Ethernet bridge vendors are the pioneers in heterogenous bridging, so the onus is upon them to be creative and work their way out of this bind. It is not impossible, although they are obviously working assiduously to minimize the amount of frame re-writing they will have to do. This is not the only protocol that those bridge vendors might like redesigned, but it I think that they will find that they have to solve their own problems. I don't think Apple will find it in their heart (or budget) to re-implement all of their AppleTalk phase 2 impelmentations for the sake of other companies. Let's face it, it would wind up being AppleTalk phase 3, and I don't think anyone wants another protocol cutover. He who drives the protocol stake in the ground first usually has the strongest claim. Sort of like European colonization of Africa and the New World. One cannot expect protocol designers to have the ability to see into the future and anticipate future technologies and products. One cannot blame Apple for doing something wrong in this case. The new kid on the block is always responsible for figuring out how to provie backwards compatability with all the old protocols. The FDDI/Ethernet bridge vendors are the new kids on the block now. They have software engineers, who presumably understand protocols. They can architect solutions. Admittedly, this might require those competing vendors to cooperate on the design of the solution, which they may not want to do.