robert@cheviot.UUCP (Robert Stroud) (01/24/85)
<239@cheviot.UUCP> cancelled from rn.
robert@cheviot.UUCP (Robert Stroud) (01/24/85)
Thanks to the Type vs Length field mess, the ISO/IEEE and Xerox Ethernet specs are incompatible from the data link level upwards, (and perhaps even the physical level). We have a variety of machines which support one family or the other and we wish to connect them together on our Ethernet using the Newcastle Connection. For various political and technical reasons, we believe we will have to support BOTH worlds - we can't change entirely to one or the other. However, we are prepared to have at least one machine which understands both protocol families. I've been writing a paper about all this and what we're going to do about it, but would like to clear up a few points. If anyone can answer any of the following questions I will be very grateful. I'll summarise any replies to the net. 1) Is "Ethernet 2" the same as IEEE-802.3 or is it an upgraded version of the original Xerox/DEC/Intel Ethernet specs? 2) Are the hardware differences between 802.3 and Xerox likely to be a problem in practice, and how will the discrepancies be resolved? Are transceivers that correspond to the same standard compatible? (we certainly hope they are :-)! 3) What is Xerox's position regarding allocation of Type field values to ISO protocols? Have they reserved the block 0-1500 for use by ISO, (we believe these values correspond to the only valid 802.3 length fields) or have some of these values been allocated to other protocols? We think that PUP in particular has been allocated the value 512, although the 4.2 header files are contradictory on this point. 4) Will the following algorithm suffice to distinguish IEEE packets from Xerox packets at the data link level, and pick an appropriate protocol handler? Examine the Type/Length field. If it is less than 1500 then assume that it's an IEEE packet so switch on LSAP, otherwise assume it's a Xerox packet and switch on the field itself. If an IEEE only station receives a Xerox packet (or vice-versa) then throw it away. [It should only be a broadcast packet]. Also throw away any packets for LSAP's (which we use as type fields) or Type fields that we don't know about. 5) Just what do the ISO people mean by a SAP (Service Access Point)? Is it fair to say that they are using SAP's as sub-addresses AND type fields, confusing two notions in one? If not, how do you reconcile the allocation of particular SAP values to particular protocols, (e.g. IP and ISO internet protocol) with the statement in 802.2 that it should be possible to send packets between any pair of SAP's?? Thank you very much. Robert Stroud, Computing Laboratory, University of Newcastle upon Tyne. ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa UUCP ...!ukc!cheviot!robert
rpw3@redwood.UUCP (Rob Warnock) (01/31/85)
+--------------- | Thanks to the Type vs Length field mess, the ISO/IEEE and Xerox | Ethernet specs are incompatible from the data link level upwards, | (and perhaps even the physical level). +--------------- Yes, it is a mess, but Xerox tried to salvage what they could. Your algorithm (look at the "length") should work, according to private conversations with certain Xerox folk. UNFORTUNATELY, many people are picking types and using them WITHOUT registering them with Xerox! (Boo, hiss!) In particular, I don't think either the 4.2 "trailer protocol" or ARP types are registered with Xerox (thoufh they are with NIC!), but I also don't know if they may cause a conflict or not. It is VERY important that EVERYONE use only registered types. Getting a new type registered is not all that hard, if you can stand a certain amount of telephone tag (and already have an Ethernet patent license). (Remember, 802.3 requires a patent license from Xerox.) +--------------- | 3) What is Xerox's position regarding allocation of Type field values | to ISO protocols? Have they reserved the block 0-1500 for use by ISO, | (we believe these values correspond to the only valid 802.3 length fields) | or have some of these values been allocated to other protocols? We think | that PUP in particular has been allocated the value 512, although the | 4.2 header files are contradictory on this point. +--------------- Yes, 0-1500 are now reserved for IEEE "length". There apparently WAS one such value allocated as a private type to some licensee, which they convinced the licensee to change. Since PUP is "Xerox Private" and "experimental" (obsolete), you shouldn't run into that problem, unless you have a bunch of "non-products" like the Alto lying around. (New products use XNS.) +--------------- | For various political and technical reasons, we believe we will | have to support BOTH worlds - we can't change entirely to one or | the other. However, we are prepared to have at least one machine | which understands both protocol families. +--------------- That SHOULD work, if you can convince the IEEE machines to ignore packets with "bad" lengths. +--------------- | 1) Is "Ethernet 2" the same as IEEE-802.3 or is it an upgraded version | of the original Xerox/DEC/Intel Ethernet specs? +--------------- Both, sort of. Ethernet 2.0 is the same as one particular choice of all the options 802.3 gives you; Xerox "upgraded" the spec to conform. +--------------- | 2) Are the hardware differences between 802.3 and Xerox likely to be a | problem in practice?... +--------------- No. The key words are "in practice". All of the U.S. manufacturers I know of are REALLY making Ethernet 2.0 devices, and CALLING them "802.3 compatible". Since 802.3 includes so many choices, saying "802.3 compatible" by itself is no guarantee of interoperability. Saying (and conforming to) "Ethernet 2.0" should guarantee interoperability. +--------------- | 4) Will the following algorithm suffice to distinguish IEEE packets from | Xerox packets at the data link level, and pick an appropriate protocol | handler? [Look at "length"... >1500 is Xerox.] +--------------- Yes, except for the problem with unregistered types (see above). (Please, corrections without flames, if possible. This is based on memory of conversations of about a year ago.) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404