Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!CDCCENTR.BITNET!dino From: dino@CDCCENTR.BITNET (Dino Farinacci - Control Data - CDCNET TCP/IP Development) Newsgroups: comp.protocols.tcp-ip Subject: Re: 802 (.2).3 TCP/IP Message-ID: <880624191754.0000773F.AFGF.01@CDCCentr> Date: 25 Jun 88 00:17:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 47 This is in response to ssc-vax!bruce@beaver.cs.washington.edu's memo <1919@ssc-vax.UUCP>: When we (CDC) initially started support of TCP/IP in CDCNET we made the decision to support all three of the Ethernet header formats. We were informed with the direction of OSI standards that 802.2/802.3 was the way to go. Our CDCNET systems already supported this header format but we needed to include Ethernet 2 and SNAP headers. We felt the effort was trivial for incoming frames. Just check the ether type field in the 802.3 (or version 2 header). If the value was greater than 1518 (maximum length Ethernet frame), then the header format was Ethernet 2. Otherwise it was 802.2/802.3. If 802.2 was present than another check is done to determine if a SNAP header follows. If so, use the ether type field in the SNAP as one would in the Ethernet 2 case. If no SNAP, use the 8-bit SAP value in the 802.2 to multiplex to the correct user. For outgoing frames, one does not know what header format the destination system supports. If it was our own system, it didn't matter (we supported all of them). There are two ways we allowed this information to be provided. One, staticly configure the header format with the IP address/ Ethernet address. Or two, let ARP find out. Obviously it was less of a burden to the Network Administrator if ARP did it. The disadvantage was that ARP broadcasts two ARP requests, each with a differnet header format (Ethernet 2 and SNAP - there is not an 8-bit 802.2 SAP value assigned for ARP). When the reply is received, the IP address/Ethernet address and header format is cached. We did this over a year and a half ago anticipating that workstation vendors would go to the SNAP. However, everything I've heard from the TCP/IP interoperability conferences indicates no one cares about it and everything works fine as it is today. Dino Farinacci Control Data Corp. CDCNET TCP/IP Design and Development Sunnyvale, CA. 408-744-5375 ------------------------------------------------------------------703