Xref: utzoo comp.dcom.lans:5453 comp.protocols.tcp-ip:12212
Path: utzoo!attcan!uunet!crdgw1!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!apple!apple.com!veizades
From: veizades@apple.com (John Veizades)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: Zero manufacturer code in SNAP?
Message-ID: <9272@goofy.Apple.COM>
Date: 19 Jul 90 23:02:12 GMT
References: <1990Jul17.010234.12077@portia.Stanford.EDU>
Sender: usenet@Apple.COM
Distribution: na
Organization: Apple Computer, Inc.
Lines: 61

The all-zeros Rorganizational unique identifierS (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 Rgeneral agreement,S 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 RtransparentlyS 
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 forwared entirely without translation.

In terms of actual product implementations, unfortunately DEC is already 
beta-siting an Ethernet-to-FDDI bridge 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 th 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.


John Veizades and Alan Oppenheimer
Apple Computer, Inc.