desimone@tom.columbia.edu.UUCP (02/05/87)
Hi...We've been successfully running an ethernet LAN here for the past couple of years. Recently, however, we've received a number of products that conform to the IEEE 802.3 standard. Since our network is a few years old, some of our hardware was designed according to the original ethernet standard (Version 1) and some according to Version 2. I haven't really been able to get solid information about compatibility problems between these standards. I'd like to know what the main differences are between the three standards and what the compatibility picture looks like. Thanks... ... Salvatore
authorplaceholder@tiger.UUCP.UUCP (02/08/87)
/* Written 2:41 pm Feb 5, 1987 by desimone@tom.columbia.edu.UUCP in tiger.UUCP:comp.dcom.lans */ /* ---------- "Ethernet Compatibility..." ---------- */ Hi...We've been successfully running an ethernet LAN here for the past couple of years. Recently, however, we've received a number of products that conform to the IEEE 802.3 standard. Since our network is a few years old, some of our hardware was designed according to the original ethernet standard (Version 1) and some according to Version 2. I haven't really been able to get solid information about compatibility problems between these standards. I'd like to know what the main differences are between the three standards and what the compatibility picture looks like. Thanks... ... Salvatore /* End of text from tiger.UUCP:comp.dcom.lans */ I'd like to give you a couple of hearsay incompatibilities. I read in DATA COMMUNICATIONS magazine that ethernet 1.0's voltage level at "idle" on the baseband cable is 0.7 Volts DC, whereas IEEE 802.3's idle voltage leve is 0.0. I had an Entre salesman (take this with a grain of salt) tell that some ethernet boards incorrectly interpret an IEEE 802.3 "length" field as a "type" field. I have not been able to determine the accuracy of the latter statement. Ray Kellogg
ted@blia.UUCP (02/10/87)
In article <144000002@tiger.UUCP>, rvk@tiger.UUCP writes: > .... I had an Entre salesman (take this with a > grain of salt) tell that some ethernet boards incorrectly interpret > an IEEE 802.3 "length" field as a "type" field. I have not been able to > determine the accuracy of the latter statement. You can thank the IEE 802 committee for this one (or perhaps the Xerox-Intel- DEC tramatic trio)! The IEEE 802.3 length field is in the same place as the Ethernet protocol type field. DEC's newer generation of Ethernet interfaces handle both protocols by looking at the 802.3 length field and if that is larger than a legal packet size (1548 or whatever that magic number is), it assumes that the packet is in the Ethernet format. It looks like most of the protocol types assigned by Xerox are large enough to make that work. But if anyone decides to use a small value there, a lot of sites will be in trouble. =============================================================================== Ted Marshall Britton Lee, Inc. p-mail: 14600 Winchester Blvd, Los Gatos, Ca 95030 voice: (408)378-7000 uucp: ...!ucbvax!mtxinu!blia!ted ARPA: mtxinu!blia!ted@Berkeley.EDU disclaimer: These opinions are my own and may not reflect those of my employer; I leave them alone and they leave me alone. fortune for today: Worst Month of 1981 for Downhill Skiing: August. The lines are the shortest, though. -- Steve Rubenstein
melohn@sluggo.UUCP (02/10/87)
In article <144000002@tiger.UUCP> rvk@tiger.UUCP writes: >... I had an Entre salesman (take this with a >grain of salt) tell that some ethernet boards incorrectly interpret >an IEEE 802.3 "length" field as a "type" field. This is perfectly acceptable for an Ethernet board that is unaware of 802.3 to do, since the packets look like Ethernet packets to an Ethernet driver. Common practice in many 802.3 drivers is that if a packet arrives with a length/type field of greater than 1500 (which is illegal in 802.3) it must be an ethernet packet and the field should be interpreted as the ethernet type. As long as no one tries to use ethernet types less than 1500, 802.3 and Ethernet can coexist happily on the same wire using this scheme.
normt@ihlpa.UUCP (02/11/87)
> > /* Written 2:41 pm Feb 5, 1987 by desimone@tom.columbia.edu.UUCP in tiger.UUCP:comp.dcom.lans */ > /* ---------- "Ethernet Compatibility..." ---------- */ > > Hi...We've been successfully running an ethernet LAN here for the past > couple of years. Recently, however, we've received a number > of products that conform to the IEEE 802.3 standard. Since > our network is a few years old, some of our hardware was > designed according to the original ethernet standard (Version 1) > and some according to Version 2. I haven't really been able to > I'd like to give you a couple of hearsay incompatibilities. I read in > DATA COMMUNICATIONS magazine that ethernet 1.0's voltage level at > "idle" on the baseband cable is 0.7 Volts DC, whereas IEEE 802.3's > idle voltage leve is 0.0. I had an Entre salesman (take this with a > grain of salt) tell that some ethernet boards incorrectly interpret > an IEEE 802.3 "length" field as a "type" field. I have not been able to > determine the accuracy of the latter statement. Both of these statements are true. The "Ethernet" network idles "with the transmit+ positive with respect to transmit-". The ethernet versionII and IEEE802.3 idles at a zero differential voltage. This is the only hardware incompatibility and depending on the interface you are using there may be a switch to select which format you want to run. I don't know if or how well these will talk to each other, but my intuition says "not well." With regard to the type field, this is a two byte field that comes after the destination and source address and before the data field. In IEEE802.3 it is defined as the length of the valid data in the data field. This normally will not include any padding bytes that are added to the data to get the 46 minimum byte data field. This number is only used by higher level protocols. The actual transmitter and receiver should not (and will not in any compatible product) use this field for length. It is simply passed to the higher level protocols as data. In The original ethernet, this was a type field that informed higher levels what the message protocol was. For example if the data field is formatted with TCP/IP format the type field is 0800 if the formatting is the defense department's XNS this field is 0600. Both of these if taken as hex numbers would be illegal length fields. i.e. no confusion. Historically this comes from the indended purposes and users of the network, this I won't go into since it does not add to the discussion. Basically the hardware problem exists and the two have problems talking to each other. The type/length field is something that is ignored from the hardware point of view and so if updated software is running on both ends, you don't really care what is in this field as long as both ends assume the same. As far as address assignment, this has passed onto the IEEE standard board, however if you want to register a type field for your higher level protocol, this is still done through Xerox corp. If anyone is interested I have the address and contact name for both of these places. Norm Tiedemann AT&T Bell Labs Naperville, IL 60566 (312) 979-3535 ...!ihnp4!ihlpa!normt
mouse@mcgill-vision.UUCP (02/13/87)
In article <4312@columbia.UUCP>, desimone@tom.columbia.edu (Sal Desimone) writes: > Hi...We've been successfully running an ethernet LAN here for the > past couple of years. [...] Since our network is a few years old, > some of our hardware was designed according to the original ethernet > standard (Version 1) and some according to Version 2. We have an Ethernet here linking a two VAXen and a bunch of Suns. Initially, the Suns had version 1 transcievers and the VAXen had version 2 transcievers. The results were a great slowdown when speaking between incompatible transcievers. Initially we just thought it was a slow net, but when rdumps would lose the connection halfway through we had to do some investigation. The effect was that only one packet in N (N unknown) would get through. Eventually enough packets in a row would be dropped and the connection would time out. It is a tribute to the robustness of TCP that the only visible effects were occaisonal timeouts and (always) slow transfers. We got version 2 transcievers for the Suns and the problem went away, apparently for good. So....don't expect good results when trying to make version 1 and version 2 talk to one another. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu