The IEEE 802.1h is the formal standard for AppleTalk and FDDI. Below are four third-party vendors which support this standard:
- UB Networks' current products supports the 802.1h standard. Users should contact them regarding their bridges and for upgraded information.
- 3Com Corporation's LANPlex bridge supports the 802.1h standard and AppleTalk. For more information see the following web page: http://www.3com.com/cgi-bin/mfs/01/0files/products/dsheets/lpfamspc.html
- Kalpana's EtherSwitch supports 802.1h.
- Grand Junction's FastSwitch supports 802.1h.
We believe there are other bridges that support 802.h as well.
Below Is Information Outlining Issue Before The IEEE 802.1h Was Set
-------------------------------------------------------------------
First, some background:
AppleTalk Phase 2 packets crossing a transparent FDDI bridge are translated into Ethernet-style packets. If these packets translate incorrectly, the bridged Ethernet segments can't communicate with each other over EtherTalk Phase 2. This problem relates to the way vendors implement the OUI 0000 (organizational unique identifier) in the 802 SNAP header.
Some bridge vendors base their products on the IEEE 802.1 standard. However, there are questions about how the standard handles translating "all zeros" in the OUI field of an 802.2 SNAP header.
The problem has to do with the way Apple implements AARP in SNAP in AppleTalk Phase 2. The 802.1 specification says that all SNAP PDUs need a 40-bit protocol identifier. The first 24 bits are unique organizational identifiers assigned by the IEEE; the remaining 16 bits are administered by the assignee:
UI Assignee Administered
0011 0101 0111 1011 0001 | 0010 0000 0000 0000 0001
| |
lsb msb
Apple's assigned identifier is 08 00 07
1000 0000 0111
network bit order 0001 0000 1110
||
IEEE 802.1 states that: ||
MX
M = 0: (M=1 is reserved)
X = 0: Globally Administered Protocol Identifier
X = 1: Locally Administered Protocol Identifier
For all AppleTalk protocols, Apple uses the identifier 08007809B. But for AARP, Apple uses 00000080F3. This is really where the problem begins--in the use of OUI 00000.
Because Apple uses 0000 as a UI, there are conflicts with FDDI-Ethernet bridges that also use the same UI to recognize and translate Ethernet-style packets. The question is: who's right--Apple, the vendor, or both?
The all-zero OUI was not intended to be used for translating Ethernet frames to 802.2/SNAP. Its original intention was (and is) not completely clear; all that was agreed upon was:
1) The low-order 16 bits of the SNAP protocol discriminator indicated an Ethernet protocol type; and
2) The format of the data part of the SNAP packet was the same as the format of the data part of the Ethernet packet of this protocol type.
This "general agreement," was never written down--AppleTalk Phase 2 and TCP/IP just adopted it. Unfortunately, on an Ethernet/802.3 data link, AppleTalk Phase 2 runs on top of 802.3 (and 802.2) and TCP/IP runs on top of Ethernet. Thus, when TCP/IP Ethernet nodes communicate with TCP/IP 802.2 nodes (on token ring or FDDI, say) some type of packet translation must occur. But AppleTalk Phase 2 Ethernet nodes communicating with AppleTalk Phase 2 802.2 nodes (on Ethernet, token ring or FDDI) MUST NOT have any translation done.
This is why it's not so simple to build a bridge that "transparently" allows both forms of communication. What's needed is a bridge with a small Ethernet protocol translation table. The smaller the table, the less translation that happens, and the better the bridge's performance. Any bridge between Ethernet and 802 media that does not translate OUI zero packets prevents TCP/IP nodes (and any others using the same OUI convention) from communicating between the two media. Any bridge between Ethernet and an 802 media that translates all OUI zero packets prevents AppleTalk nodes (and any others with an OUI of zero who don't expect translation) from communicating between the two media. In both cases, routers can, of course, be set up to communicate.
A similar problem happens if two bridges connect two Ethernet/802.3 data links across an 802 backbone (say FDDI). In this case, some type of translation/encapsulation of Ethernet (non-802.3) packets must happen so they can pass across the 802 backbone. There are many ways to do this, one of which is to translate all Ethernet packets to OUI zero packets, shipping them across the backbone, and then converting them back. This, however, does not work for any OUI zero packets that start out on the Ethernet/802.3 data link. Such packets will not be translated on the way into the backbone but will be incorrectly translated before being delivered on the destination Ethernet. Such packets should be forwarded entirely without translation.
In terms of actual product implementations, unfortunately DEC is already shipping an Ethernet-to-FDDI bridge (LanBridge 500) that translates all OUI zero packets, and thus does not work with AppleTalk Phase 2. DEC is aware of this issue. At the recent 802 meetings in Denver, it was clear that this type of translation is not part of the 802.1d (Mac Bridging) standard, but is something that many bridge manufacturers wish to include as a non-802-standard option with their products. Most have said they will have some type of translation (or non-translation) table to ensure it is possible to work with all known protocols.
Current Status:
At a recent IEEE 802.1 meeting, there was agreement about the translation of Ethernet-like packets from an FDDI backbone to an Ethernet segment. The creation of a new OUI for Ethernet (non 802.3) packets will be required. The Bridge translation decision from an FDDI backbone to Ethernet segment will be as follows:
If OUI = NEW, then translate back to Ethernet (e.g., Phase 1
EtherTalk) Otherwise if (OUI=0 and TYPE=80F3 or other defined types do
NOT translate), Do not translate (e.g., Phase 2 EtherTalk AARP)
Apple and DEC were major sponsors of this proposal, and DEC has agreed to make changes to their bridges. This means is that EtherTalk Phase 2 AppleTalk end nodes will work correctly (without modification to the end nodes), when transversing an Ethernet/FDDI bridge. Furthermore, EtherTalk phase 1 end nodes will also work using the new OUI translation scheme.
The IEEE 802.1 committee is currently formalizing the use of OUI in Ethernet to FDDI bridges that will define what to do if a bridge encounters SNAP headers with OUI=0.