Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!brooks From: brooks@Apple.COM (Kevin Brooks) Newsgroups: comp.protocols.appletalk Subject: Re: Phase 1 vs. Phase 2 Message-ID: <48667@apple.Apple.COM> Date: 30 Jan 91 21:34:06 GMT References: <48241@apple.Apple.COM> <29515@usc> <48379@apple.Apple.COM> Organization: Apple Computer Inc., Cupertino, CA Lines: 157 The Real Story - AppleTalk Phase 2 and FDDI bridges First, the problems with AppleTalk phase 2 and FDDI have been resolved. Problem Description: Phase 2 AppleTalk packets that transverse an FDDI transparent bridge are translated into an Ethernet style packet. The incorrect translation prevents nodes on two Ethernet segments joined, through "transparent" bridge, by an FDDI backbone, from communicating with each other using EtherTalk Phase 2. This is a result of our implementation of the OUI 0000 in the 802.2 SNAP header. The bridge vendors have implemented their products based on the IEEE 802.1 standard. However there are questions regarding the interpretation of the standard as it relates to translating "all zeros" in the OUI field of an 802.2 SNAP header. The problem has to do with the way in which we implement SNAP in phase 2, and more specifically, how we implement AARP in SNAP in phase 2. The 802.1 specification calls for all SNAP PDUs have a protocol identifier associated with them which is 40 bits in length. The first 24 bits are used as an organizational unique identifier which is 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 we use the identifier 08007809B, but for AARP we use 00000080F3. This is really where the problem begins, in our use of OUI 00000. Our use of 0000 as the UI is conflicting with a translating FDDI-Ethernet bridge which also is using the UI of 00000 to recognize IP packets which need to be translated from 802 to Ethernet style packets. The question is who's in the right, us, them, or both of us? The all-zeros "organizational unique identifier" (OUI) was not specifically intended to be used for translating Ethernet frames to 802.2/SNAP. Its original intention was (and is) not completely clear; all that was generally 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," as far as I know, was never written down. AppleTalk Phase 2 and TCP/IP both adopted this convention. The unfortunate difference is that, 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 for a TCP/IP Ethernet node to communicate with a TCP/IP 802.2 node (on token ring or FDDI, say), some type of packet translation must be performed, whereas for an AppleTalk Phase 2 Ethernet node to communicate with any other AppleTalk Phase 2 802.2 node (on Ethernet, token ring or FDDI) no such translation need occur (in fact, such translation MUST NOT occur). This makes it somewhat difficult to build a bridge that "transparently" allows both forms of communication. However all that really has to be done is for the bridge to contain a small table of Ethernet protocol types that either should, or shouldnUt be translated in this manner. Obviously the smaller the table, and the less translation done, the better the overall performance. Any bridge between Ethernet and an 802 media which does not translate any OUI zero packets will prevent 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 which translates all OUI zero packets will prevent AppleTalk nodes (and any others with an OUI of zero who donUt expect translation) from communicating between the two media. In both cases, routers can of course be set up to accomplish the communication. A somewhat equivalent problem could exist if two bridges are used to 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 be performed to allow them to be passed across the 802 backbone. There are many ways to do this, one of which seems to be translating 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 which 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) which translates all OUI zero packets, and thus does not work with AppleTalk Phase 2. They are aware of this issue. At the recent 802 meetings in Denver, it became 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 insure it is possible to work with all known protocols. Current Status: At the most recent IEEE 802.1 meeting (during the week of 11/12/90) an agreement was reached regarding 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, in accordance with this proposal. What 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. This should work will define exactly what to do if a bridge encounters SNAP headers with OUI=0. DEC has already started shipping new beta ROMs for the LanBridge 500 to resolve the issues related to OUI 0. During the beta test a problem was discovered with the Shiva Fastpath, it incorrectly computes the length field of 802.3 Ethernet packets, because of this the LanBridge discards all packets from the Fastpaths. Shiva was already aware of the problem and new ROMs for the Fastpaths should be available soon to resolve this issue. If you have any questions concerning this issue please feel free to send them my way. Thank you Kevin Network and A/UX Engineer Apple Computer -- Kevin Brooks A/UX Specialist, Apple Computer UUCP: {mtxinu,sun,nsc,voder}!apple!brooks APPLELINK: AUX.DUDE@applelink.apple.com Internet: brooks@apple.com