Larry Kluger Sun Europe (sunuk!roundhouse!kluger@Sun.COM)
Tue, 11 Aug 87 14:51:33 BST
I've been watching this discussion go for a couple days now and have
found the mis-communications between people of this distribution list
(who are all communications 'experts') quite interesting.
Let me take a whack at a few points.
First, brief personal background: I was in charge of the internetwork
routing software for XNS at Xerox Palo Alto from mid '81 through '86.
I didn't design the stuff, Yogen Dalal, Hal Murray, Dave Boggs, Larry Garlick,
Alan Freier, and others did that. But I had lots of discussions with
those folks over the years on the subject of "why it was done that way."
First, addressing uniqueness. Alto's used the 3 MBit Ethernet which had
8 bit addressing at the link level. Everytime you installed an Alto, the
tech had to open the machine and futz with the 8 jumpers which set the
binary address to be 0-255. Except that it couldn't be either 0 or 255
for various reasons.
It was decided that this was a real pain. And so in the Dec/Intel/Xerox
Ethernet spec, 48 bits are used for the link level addressing.
Let's be clear about the functionality that is desired: the idea is that
people would be able to purchase a computer, plug it into the "Information
Outlet" and be all set. No jumpers, no configuration, no nothing. Any magic
bits can be taken care of by administrators at a central location.
Through the power of broadcasting and multicasting, I claim that you NEVER
need to type in special numbers at the keyboard of your new computer. All
of that can and should be done over the network.
What is now known as ARP and RARP play a big part in that of course.
Unfortunately, DEC decided to do it their way--you have to tell
the DecNet machines their node and area, then they change their Ethernet
address as was discussed, etc. Put me down as someone who doesn't like or
understand Dec's methodology in this regard. But remember that I work
for a competitor of Dec's, namely Sun Microsystems. I'm encouraged by the
messages which indicate that Dec may change this in the next release
Phase of DecNet.
"Having globally unique addresses can really mess up MAC level bridges."
I found that mail message interesting because a) the writer raised a very valid
point that I hadn't thought of before and b) the writer then went on to
suggest the WRONG (I feel) solution to the problem. I feel that the correct
answer is to not use Mac-level bridges. I don't really want to bring back
the bridge vs anti-bridge discussions, but I will make the comment that
I'm sure that no one in the late 70's and early 80's who was working
on the Ethernet spec ever thought that people would actually build boxes
that tried to see every packet, do the 'right' thing with it, and then
try to make the whole affair invisible to the source and destination
machines. Why don't people use internetworking for their internetworks?
Assigning Ethernet addresses. When I left Xerox in March of 1986,
all 'magic number' assignments were still be handled by Xerox. This
included type numbers at the Ethernet level, 48 bit Ethernet
source/destination, XNS network numbers, etc.
You can reach those people at "Network Administration Office, Xerox Corp,
3333 Coyote Hill Road, Palo Alto CA 94304, USA"
AA-00-04 was assigned to Digital.
So were some other blocks. Digital uses the other blocks when burning
proms for their machines.
Xerox gave itself several blocks also. One interesting block they gave
themselves is the 00-00-00 block. This is used with old Dolphins.
There's an interesting story there, ask me about it (in person) some time.
Someone asked if 48 bits is enough. The short answer is yes. For more
information, see the paper by Bob Printis. My copy is at home so I can't
give you the full citation. Bob presented it at a conference in Mexico City
in the early 80's. The paper explains why 48 bits is enough.
With respect to the question about manufacturers 'using up' the numbers
through various bad practices, two comments:
a) Manufacturers are asked to use the 48 bit numbers that they are assigned
'densely.' They are NOT to use them as serial numbers, etc. Most manufacturers
are pretty good about this. If a manufacturer wants, Xerox will even sell
them a batch of id proms with the ids burned in the proms in sequential
order. (At least that's the idea...)
b) It is in manufacturers' interest to swap the id prom with the new and
old FRU (Field Replaceable Unit) (usually circuit board) when fixing their
computers. Because 1) it's the 'right' thing to do and 2) if the manufacturer
has their computer system set up so that *everything* depends on the 48-bit
number (remember that this is the 'right' thing to do) then the manufacturer
wants to save their customers the pain of changing anything merely because
some hardware failed. Somewhere there's even a recommendation that
manufacturers put the id prom in a socket rather than soldering it to the
board for EXACTLY this reason.
By the way, Sun Microsystems instructs its service engineers to swap
the ID proms when replacing FRU's that contain ID proms. If Dec doesn't
do this than that's their problem (and their customers...). But my guess
is that the Dec people really are swapping the proms, it might not have
been noticed since it doesn't take much time to do.
Version of the Ethernet spec. The current version is Version 2.0. Dated
November, 1982. Copies of version 1 should be treasured, but not referred
"Local addresses" This is not part of the Ethernet spec, neither version 1
or 2. I believe that it was added by the IEEE 802.2/802.3 committees in
their infinite wisdom. I don't know what the rationale is, but in any
case I don't agree with it. People who want to have to tamper
with every single workstation that is added to a site (rather than
changing one or two mapping tables somewhere) should not be allowed
out of their computer rooms.
Think about a common electric typewriter--the vendor supplies it, it is
placed on the user's desk, plugged in, and away you go. The idea
of Ethernet was to extend that simple 'plug and play' model to
European Data Communications Consultant
Sun Microsystems Europe
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:49 GMT