The impact of technology and networks on our lives, culture, and society continues to increase. The very fact that you can take this course from anywhere in the world requires a technological infrastructure that was designed, engineered, and built over the past sixty years. To function in an information-centric world, we need to understand the workings of network technology. This course will open up the Internet and show you how it was created, who created it and how it works. Along the way we will meet many of the innovators who developed the Internet and Web technologies that we use today. What You Will Learn: After this course you will not take the Internet and Web for granted. You will be better informed about important technological issues currently facing society. You will realize that the Internet and Web are spaces for innovation and you will get a better understanding of how you might fit into that innovation. If you get excited about the material in this course, it is a great lead-in to taking a course in Web design, Web development, programming, or even network administration. At a minimum, you will be a much wiser network citizen.
Bob Metcalfe - The Ethernet Story
Loading...
來自 University of Michigan 的課程
互联网的历史、技术和安全
1522 個評分
從本節課中
Technology: Internets and Packets
The Internet is designed based on a four-layer model. Each layer builds on the layers below it. The Link and Internetwork layers are the lowest layers of that model.
與講師見面
Charles SeveranceAssociate Professor
School of Information
[MUSIC][NOISE]
. I was extraordinarily lucky and happened
to be at the Xerox Research, Xerox Palo Alto Research Center when a, a problem
evolved that had never before occurred, the problem had never occurred.
And that was the problem of having a building full of personal computers.
And I was the networking guy, so they turned to me and said, network these
puppies. And we bad just finished starting the
internet. It was the called the arpanet, which was
packet switching. And it was pretty clear we wanted this
network to connect to the, it wasn't yet called the internet, thing.
So, it would be packet switch, we were pretty sure.
At the same time, we were building, arguably, I don't want to get into that
argument. The first laser printer, which in our
case, the first one, whose name was Ears. That's a whole other story.
it was a page per second, 500 dots per inch, and if you do the math, that's
about 20 megabits per second. So the existing methods of
interconnection had a lot of problems. One is that they were all home run, so
all these wires, one from every desk, are all coming to this one place in the
building and put a big rat's nest. We called it a rat's nest by the way.
Two is they generally ran at 200 bits per second or.
If you really rate them up, they go to 14 4 kilobits per second, and that wasn't
even close to 20 megabits per second. And we wanted to be able to keep the
printer busy by sending documents from all these PCs which hadn't been built
yet. >> Except at park.
>> Well, they hadn't been built even at Park at that point.
>> Okay. >> So we were building the printer.
We were building the PCs all at the same time.
So, I started worked on this, and there was a preceding effort before mine called
Signet at Park. And it was being done by Charles Simony,
my friend, and but he wasn't a networking guy, so they sent me in to pick up Signet
from Charles. And he was going to go off and do
something else. And by the way the other thing he did, is
he wrote a word a text editor, a word processor, called Bravo, which then
became Microsoft Office. So, Charles is a billionarie and he has
been to the space station. Twice, the International Spa.
So maybe I shouldn't have kicked him off Signet, maybe I should have done Bravo.
I don't know. Anyway, so I, immediately decided that
Signet, by the way, SIGNet stands for Simonyi's Infinitely Glorious Network was
in fact infinitely glorious and much had too many moving parts to be a LAN.
By the way, the word LAN wasn't invented until 1990, and this is still 1973, so
the word LAN was still way in the future, so that's an anachronism.
Anyway, the Signet had too many moving parts for a LAN.
And it was in the course of investigating how to organize this LAN that I ran into
a packet, quite by accident, a packet radio network at the University of Hawaii
that was called the Aloha Net. And what was beautiful about the Aloha
Network was it had a solved a distributed problem.
That is, how would we share a radio channel back to the mainframe in, in
Hawaii, at the university? If we're just a bunch of terminals
scattered among the Hawaiian islands and they couldn't really easily talk to each
other to get coordinated? How would they coordinate their sharing
of this inbound radio channel? And Norm Abramson, there at the
University of Hawaii devised this very simple randomized retransmission
procedure, where a person would type. By the way what they would type was a
card image. It was 80 columns wide, back from the
days of card batch processing. So, you would type in your card image and
hit send. And then your terminal would send it in
toward the main frame, and then would wait a short time to see if there was an
acknowledgement that returned on the outbound channel.
And if there was, everything was hunky-dory, but if there wasn't, that
probably meant that two terminals decided to send at the same time.
So, then as many terminals particpated in that collision of transmissions would
then randimoize and then re-transimit at a random time in the future.
That way if they overlapped here they would not overlap again in the future
because thye would choose different random numbers to count down.
So that's randomizory transmission, multiple access.
Since I was trying to avoid this big rat's nest of wires and only wanted to
have one wire, just one wire and not 16 or 32 or whatever the alternatives were,
just one. I wanted a distributed solution to how to
share this cable, and the Aloha Network produced that using randomized
retransmissions. So then, I,
Actually y'know, there's sort of two stories here.
One is a hardware story. >> I was wonderin' about the hardware.
>> There's a hardware story, and there's a software story.
And the hardware story is , not that interesting but it's there.
So one of the first things I did was to buy, a kilometer of cable, or it may have
been a mile I don't know if I'd gone metric yet, but I.
So a spool of coax cable about this big, with the two ends sticking up.
So I got a, pulse generator and I hooked it up to one end and hooked it around
back into the oscilloscope, and started launching square waves down the cable and
watching what came out. I thought that would be good preparation
for building a network. And what came out the other side wasn't a
square wave. It was sort of lazy rise times and lazy
fall times. But if you put a digital gate, you could
recover the square wave. That is just set, use the digital
threshold, so out of this gate came a square wave.
So you could recover, at the end of a mile of cable this square wave.
So I kind of knew. I kind of had some confidence then that
we, that various stations connected to this cable could inject their square
waves and, the other guys could recover them.
So that hardware wasn't that hard that did it was, a, straightforward.
>> This was the first hardware. was it kind of relatively
straightforward? >> Very straightforward.
And the and the square ware , by the way was called Manchester.
What we'd do is we'd take the bit, we'd make a packet of bits, and then we'd send
them one at a time down this cable, and we would encode them.
And the encoding was also simple, it was Manchester coding.
Meaning that for each bit the first half of the bit would be the complement of the
bit. And the second half of the bit would be
the bit. So you would have a transition in the
middle of each bit cell, which is a very simple modulation scheme.
So as you're sending the packet the cables wiggling and you can recover the
signal at the other end then. Clock those bits into a shift register,
and then click the sh, clock the shift register into the memory, and then
collect a packet that way. >> And that all took just some
soldering to make that all happen basically.
>> Well I don't wanna[LAUGH]. It got a little bit complicated when you
wanted to put 255 of them on a mile of cable.
You had to be a little bit careful about the impedance on the taps.
>> Okay. >> because the square wave by a tap
might generate reflections that would then interfere.
But the beauty of Manchester encoding was that while you were sending a packet,
there were constant transitions. So if you listened, you could tell
whether a packet was going by and you didn't have to listen for long.
You only had to listen for about a bit time, which turned out to be 340
nanoseconds. So you could wait that long, and tell
whether there was a packet going by. So one of the first differences between
the Ethernet, and the Aloha net, we got a lot of differences, but one of the first
ones was carrier sense. In the Aloha network.
You couldn't tell if somebody else was transmitting at the same time as you, but
on the Ethernet, you could. And the advantage of that was, you might
as well, if you're sending and somebody else is sending at the same timeyou might
as well give up, because you've destroyed each other's packets, so punt.
Then that recovers that bandwidth that otherwise would be lost just continuing
to transmit a damaged packet. And the the other was this, this
Manchester code meant that the cable was on half the time and of half the time.
That is the, the driver, so the open, what we used to call an open collector
driver would either yank the cable up to three, four, five volts.
I even forget the voltage now. but it was under five, I'm sure of that.
I had a rule. I never went above five volts.
you would yank the cable up. And then during the other half of the bit
when you weren't yanking you let go. So, so for example in each bit cell you
got to look to see if anyone else was transmitting when you had stopped.
And if there was somebody else, then you had a collision.
So that was the second feature. >> So it was really a digital signal.
It was really a digital signal, it wasn't a modulated signal in any way.
>> Right? >> No,well it was,
>> At best you could send additional signal over[UNKNOWN].
>> On/off, with the Manchester encoding.
So Manchester encoding is akin to a modulation scheme.
But it's the simplest one you can think of.
>> It's very base bane. >> Yeah, it's very base bane.
But it's the sort of modulation scheme that a computer scientist would come up
with as apposed to one of those fancy >> Radio people.
>> Radio people. >> Right.
So, and, and by the way, took a lot of gas from those radio people.
Why do you use such a simple scheme? >> Right.
>> You're wasting. >> [CROSSTALK] .
>> You would have wasted all that, you wasted all that bandwidth.
That capable, that cable was capable of carrying hundreds of megabits per seconds
and you only carried 2.9 4. What a waste of the cable.
>> Exactly[/g] . [LAUGH] Well, the --[LAUGH] there was
plenty of cable to waste. So we talk about carrier sense inclusion
detection, and the scheme would be that each packet would carry two addresses.
The address of the destination and the address of the source.
And each of these would be 8 bits. And so on the backplane of these little
personal computers with wire app[SOUND]. You would wire app in a code between zero
and 255 and that would be the serial number of the machine.
And that, and then you'd read that off the back plane and put it in the pack.
So each packet had two addresses. This is different from the Aloha incident
which had one address. Because the channel was only going.
Through two channels. So two addresses, and we added a cyclic
redundancy checksum on the end of the packet, which we implemented in hardware.
So, that you in addition so you could tell if the packet had been damaged.
So if there was a collision and the terminal, the contending stations backed
off. There would be a hunk of garbage on the
cables sitting around. But when it was received, the check sum
wouldn't add up and you'd just throw that chunk of garbage away.
The day that I was launching pulses down this spool of cable, I was doing some
soddering, and I was doing some knife work to get the insulation off the
copper. And across the room was a young grad
student, who was doing something else and he noticed me not being good at this.
And it turns out, he was very good at it, because he had worked in a television
studio and he had worked in cable television.
So he knew all about skinning wires and coaxes.
So he came over to help me, and that was da, his name was David Boggs.
And then we started working together, and invented ethernet together.
So, he was, and he was, he was, slightly more hardware, and I was slight more
software. But there was then a third guy.
Who was even more hardware than David. Who was the picofarad guy.
The guy who would put those last few passive components on the end just to be
sure, that, that connection to the coaxial cable would be clean for
transmissions. Every time you tapped into it you didn't
put a lump of impedance on it. >> Yeah, the tapping seems like a
counter intuitive thing to me. I mean, think the, I mean everyone would
think that a star is the right thing, but you were going to tap into that.
Just tap into[UNKNOWN] . >> One of the problems we decided to
solve was the rat's nest problem. We did not want a rats nest, and every
time we installed a new PC we didn't have to home run a cable back to the rats
nest. So we wanted to put one cable down the
middle of the corridor and then every time you want to put a PC you just run up
and tap into it. And we didn't want the network to go on,
go down while you were tapping into it, because we wanted 24 by seven access to
the network. So there had to be a way to tap into the
network without bringing it down. So that led to a device we found in the
cable TV industry. It was called gerald tap, and it was
basically a, a vampire tap. You'd, you'd drill a little hole in the
outer, casing of the coax, and then you would screw in this tap that would
puncture the insulation and go right to the copper and tap in.
And you notice in that operation you're not breaking the copper, so the network
continues sending, you tap in, and you're now part of the network.
>> So that came from the cable industry.
>> It did. >> Oh, okay.
>> So a guy named David Ladell, who had done cable TV installations when he was
in grad school in Toledo. suggested that we use the gerald tap
since it was already being made in volume and worked just fine, as far as he was
concerned. And it allowed us to solve the rat's
nest, what we perceived to be an important problem, the rat's nest
problem. The Aloha network ran in the
kilobit-per-second range, like 4800 or I don't remember the numbers, but kilobits
per second. The Ethernet then started at 2.94
megabit. And in those days, by the way, T1 was
1.544 megabytes per second. So in 1973, the ethernet was already as
fast as T1. Of course T1 is still around, oddly.
But then we went from 2.94, we briefly went to 20 megabytes per second inside of
Xerox. And then when we bumped into DEC and
Intel for the standardization process in 802, we decided on ten.
We came down from 20 to ten so the chips would work.
And then we went from ten, and later, I helped found a company called Grand
Junction Networks, that introduced the 100-mg Ethernet.
And I remember being at my coffee table in Palo Alto, I think it was.
I forget the year. No, maybe it was in Woodside.
But we were trying to think of how we would make a fast Ethernet, and there's
some math that shows that if, as you go faster.
The efficiency depends on the diameter of the network, and as you go faster and
faster, the efficiency goes down. The diameter of the network in bits.
And when you're trying to up a factor of ten, and it I don't know who it was, one
of us observed, that wait a minute, we've been assuming that Ethernet is a
kilometer in diameter. But we're going, we're all going to hubs
now so that we only need 100 meters, not 1000 meters.
And that was the factor of ten right there, so that by changing the collision
interval. You maintain the same efficiencies,
theoretical efficiencies by just assuming you're going 100 meters instead of a
kilometer. So that got us to 100 megabits per second
and not gigabit, ten gigabit which I guess is the mainstream now, and then 100
gigabit is now beginning to run. 100 gigabits per second.
You can't, you can't be a computer scientist and build that kind of digital
now. You have to actually be an engineer, a
hardware engineer to run at a 100. >> I think at that point, you're pretty
much a radio person. >> [LAUGH] But then after 100 gigabits
comes terrabits, so i've already begun giving talks on terrabit ethernet.
[MUSIC]
