morgan@jessica.stanford.edu (RL "Bob" Morgan) (07/17/90)
Here's a question about SNAP that might be answered if I could ever actually see the spec for it. Then again, maybe not. The 40-bit SNAP extension to IEEE 802.2 specifies a 24-bit "organizationally unique identifier" that is apparently supposed to be the same 24 bits that a manufacturer uses to form the upper part of a 48-bit unique IEEE 802 MAC address. The other 16 bits are assigned by the organization in any way it sees fit. Now, IP on 802.2, as specified in RFC 1042, uses 24 bits of zeros to fill this field. The remaining 16 bits are filled with the same 16 bits used for the Ethernet type field (for IP and ARP frames). The question is, has the all-zeros SNAP id been assigned by IEEE to DoD, or the IAB, or some IP authority, to be administered by that authority? Or is the all-zeros id just a general purpose format for translating Ethernet frames to 802.2/SNAP, to be used by anyone? Those of you familiar with AppleTalk Phase II may get a glimmer of why I'm asking. Thanks, - RL "Bob" Morgan Networking Systems Stanford
rpw3@rigden.wpd.sgi.com (Rob Warnock) (07/18/90)
morgan@jessica.stanford.edu (RL "Bob" Morgan) writes: +--------------- | The question is, has the all-zeros SNAP id been assigned by IEEE to DoD, | or the IAB, or some IP authority, to be administered by that authority? +--------------- My understanding, which has no more authority in this case than "urban legend" (and should probably be taken with the same degree of confidence), is that the 24-bit "organization" identifier was not originally intended to be identical with the upper 24 (well, 23) bits of some assigned MAC address, but was to be a separate space assigned/managed by IEEE. (The obvious hack of making it be the same as a manufacturer's 23-bit unique MAC-address prefix came later, if at all. [*Is* that the way the IEEE assigns them?] After all, it *is* possible that a manufacturer could make more than 2^24 network interfaces and need some more addresses, so why mix SNAP IDs with MAC addresses?) So organizations had to request/register SNAP "organization IDs", and Xerox Corporation [who at Xerox?] asked for(?) / was assigned(?) [by whom?] the zero code. Xerox then said to the world, "We hereby state that we're going to use the Xerox-registered Ethernet types..." [remember that Xerox still has the registry for *Ethernet* type codes] "...in the 16-bit reserved-for-org- anization field of SNAP organization code #0 (== Xerox), and we invite any and all to do likewise". And so at an after-dinner session at the Monterey TCP/IP Conference [the First, or maybe Zero-th, Interop Conference], the "TCP/IP community" [the people in that room, at least] agreed to cease using the LSAP code that had been assigned by IEEE for IP, and agreed to use SNAP Org. Code 0 + EtherType on 802.2 links and FDDI, in order to have not only IP but ARP and BOOTP and RARP, etc. [The term "SNAPpy Xerox" was sometimes used as an irreverant handle for this encoding, until RFC-1042 came out.] Anyway, that's the way I heard it. I invite correction/historical_revision by any who have more authoritative sources/memories. [Won't take much to be more authoritative than the above... ;-} ] -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
veizades@apple.com (John Veizades) (07/20/90)
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.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/20/90)
It should be noted in passing that following is in the Host Requirements standard, RFC-1122: ] 2.3.3 Ethernet and IEEE 802 Encapsulation ] ] The IP encapsulation for Ethernets is described in RFC-894 ] [LINK:3], while RFC-1042 [LINK:4] describes the IP ] encapsulation for IEEE 802 networks. RFC-1042 elaborates and ] replaces the discussion in Section 3.4 of [INTRO:2]. ] ] Every Internet host connected to a 10Mbps Ethernet cable: ] ] o MUST be able to send and receive packets using RFC-894 ] encapsulation; ] ] o SHOULD be able to receive RFC-1042 packets, intermixed ] with RFC-894 packets; and ] ] o MAY be able to send packets using RFC-1042 encapsulation. ] ] ] An Internet host that implements sending both the RFC-894 and ] the RFC-1042 encapsulations MUST provide a configuration switch ] to select which is sent, and this switch MUST default to RFC- ] 894. Consider the implications. Every vendor must offer ethernet TCP/IP encapsulation, and that must be the default. Adding support for 802.3 (RFC-1042) is not required, and does not increase the number of compliant machines with which an implementation can interoperate. Historically, there were very few machines that used only RFC-1042. (I think HP used SAP, but that BICC (?) in the U.K. used RFC-1042.) Supporting both RFC-894 and RFC-1042 does not make an implementation faster, but code is not bad. The reduction of the MTU in RFC-1042 is about 1%, which should translate into around 10KBytes/second of lost through-put for machines that are currenting get 1MByte/sec with user-process-to-user-process TCP/IP/Ethernet. Thus, there are no (or very few and exceptional) business reasons for a vendor to offer RFC-1042 support, or even to continue existing RFC-1042 support. RFC-1103 and its pending successor are a different story. Vernon Schryver Silicon Graphics vjs@sgi.com
morgan@jessica.stanford.edu (RL "Bob" Morgan) (07/21/90)
Ah, well, now we're getting somewhere. John and Alan write: > 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. Well, not exactly. Normal AppleTalk Phase 2 (AT2) DDP datagrams are encapsulated using an OUI of 080007, which I assume has been assigned to Apple. Only AT2 ARP frames use an OUI of zero. (Both use the Ethertype for the last two bytes.) I'm sure there's a good explanation for this, but I'll admit it puzzles me. So, as we've observed, AT2 DDP frames travel across a pair of Ethernet-to-FDDI bridges just fine, and are received properly by AT2 devices on the second Ethernet. This works because the bridge sees the non-zero OUI and simply leaves the frame untouched. AT2 AARP frames fail, however. Because the bridge assumes that any zero-OUI frame on the FDDI was originally an Ethernet-format frame that was translated to 802.2/SNAP, it retranslates such a frame back to Ethernet format when it forwards it onto the Ethernet. An AT2 station ignores an Ethernet-encapsulated AARP, since it's only looking for 802.2/SNAP. Now, as Vernon points out: > It should be noted in passing that following is in the Host Requirements > standard, RFC-1122: > > ] 2.3.3 Ethernet and IEEE 802 Encapsulation > ] ... > ] Every Internet host connected to a 10Mbps Ethernet cable: > ] > ] o MUST be able to send and receive packets using RFC-894 > ] encapsulation; > ] > ] o SHOULD be able to receive RFC-1042 packets, intermixed > ] with RFC-894 packets; and > ] > ] o MAY be able to send packets using RFC-1042 encapsulation. This ensures that IP stations, even if they prefer RFC-1042 (SNAP with zero OUI) format, will properly receive Ethernet format. Of course, as Vernon notes, it effectively prevents RFC-1042 from ever being the preferred format. John and Alan continue: > 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. The combination of AppleTalks Phase 1 and 2, however, presents a sticky situation for a such a bridge, where even the translation-table method won't work. After translation into 802.2/SNAP, an AT1 AARP frame is identical to an AT2 AARP frame (except for destination MAC address). If the bridge, while forwarding from the 802 medium to Ethernet/802.3, translates a zero-OUI, Ethertype 80F3 frame to Ethernet encapsulation, AT2 breaks. If it leaves it unchanged, AT1 breaks. The bridge could dig even further, of course, to determine whether the destination MAC address is broadcast (AT1) or multicast (AT2). Apple could solve the problem by fiddling with AT2 to either: 1) make AT2 stations receive Ethernet-encapsulated AARPs, or 2) use the Apple OUI for AARPs as well as DDPs. Or we could all resign ourselves to using routers to connect between heterogeneous LANs, which is probably the moral of this whole story. - RL "Bob" Morgan Networking Systems Stanford
koning@koning.enet.dec.com (Paul Koning) (07/24/90)
::... :: :: My understanding, which has no more authority in this case than "urban legend" :: (and should probably be taken with the same degree of confidence), is that the :: 24-bit "organization" identifier was not originally intended to be identical :: with the upper 24 (well, 23) bits of some assigned MAC address, but was to be :: a separate space assigned/managed by IEEE. :: :: (The obvious hack of making it be the same as a manufacturer's 23-bit unique :: MAC-address prefix came later, if at all. [*Is* that the way the IEEE assigns :: them?] After all, it *is* possible that a manufacturer could make more than :: 2^24 network interfaces and need some more addresses, so why mix SNAP IDs with :: MAC addresses?) I don't know about the "original intent". However, the final result, as described in IEEE standard 802.1A, is that the OUI (the SAME one) is used to create individual MAC addresses, multicast addresses, and Protocol IDs. There is only a single registry, and it is used for all of these purposes. paul koning