From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: FDDI and ethernet address spaces
Keywords: Swap those little tiny bits ....
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 9 Apr 1992 16:52:20 GMT

In article <1992Apr9.045949.28653@berlioz.nsc.com>, my@laverde.nsc.com (Mike Yip) writes:
> In article 20306@amd.com, shah@brahms.amd.com (Amit Shah) writes:
> >In article <991@xlnt.COM> rasp@xlnt.com (Ron Perloff) writes:
> >>Per letter from the IEEE Standards Office to the X3T9.5 committee, IEEE has agreed
> >>to administer FDDI 48 bit addresses as they have for 802.3, 802.4 and 802.5, taking
> >>them from the same address space so there should be no duplication.
>>I believe that the IEEE addresses can be assigned by the company as they wish.
> >However, the group addresses are controlled by IEEE.  Thus the IEEE controls
> >the assignment of group addresses, not individual station addresses, which
> >can be allocated by a company to any network they choose.

Are you guys talking about groups of addresses or addresses with the group
bit set?
The IEEE does not administer the 268,435,456 group addresses used by TCP.
Those are handed out by Jon Postel &co.
Wasn't it true that you once could get a block of 16,777,216 group
addresses?  Aren't the DECnet multicast addresses in such a block owned by
DEC?

> IEEE administer the {FDDI,TokenRing,Ethernet,802.3} 48 bit address to ensure
> all 48 bit addresses used on the network, any network, are unique.  They
> allocate a block of addresses (let's say 4K addresses) to a company and
> the company itself needs make sure that the MAC address on the networking 
> card is unique within its allocated block.  A company can obtain multiple
> blocks if necessary.  Hopefully, the company didn't put random addresses
> on the card.   ;-)

You get 16,777,216 addresses in each block of individual station addresses
from Xerox or now the IEEE.

I suspect the SMT duplicate-MAC-address obsession comes from the original
ANSI FDDI MAC standard which said 16-bit addresses were required and
48-bit addresses optional.  It appears the early FDDI ideas were based on
the wonderful IBM gee-look-how-much-fun-it-is-to-locally-administer-
hardware-addresses philosophy.  That has been reversed, making 48-bit
addresses required, and 16-bit optional and so unsupported by (as far as I
know) all current FDDI products.

Large manufacturing organizations occassionally make mistakes and sometimes
decide to "conserve" MAC addresses.  I know this has happened many times to
ethernet vendors, but have not (yet) heard about it happening to an FDDI
vendors.  It is very painful for the manufacturing people; they tend to get
sensitive afterwards.


>  ...[bit swapping discussion]....

> Agree, and this is one reason why FDDI SMT provides mechanism to detect dup
> addresses
> and possibly do something.  ;-)

I doubt this justifies the SMT dup. addr. detection machines.  Failing to
bit-swap is not likely to produce duplicate addresses.  Instead, it tends
to produce bogus multicast addresses or source-route addresses by setting
the "group" bit.  It's likely to break upper layers, as protocols like ARP
go down the toilet.  The failures should be apparent silence accross the
bridge.

The place where this bit swapping madness hurts is not in bridges.
Everyone knows and understands that problem, and some MACs have hardware
support for it (e.g. DEC/Motorola).  The pain comes from the fact that some
frames must have both bit orders in the same frame.  Consider an ARP packet
on FDDI.  To let bridges work, you must have the MAC addresses in the FDDI
MAC header in FDDI order, but in the body of the ARP packet the same
addresses must be in the opposite, ethernet bit order.  Similar
confusioning situations in SMT frames and errors in earlier SMT documents
caused, I think, the most common problems in the Interop FDDI hot stagings
over the years.


Vernon Schryver,  vjs@sgi.com