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