INTRODUCTION
1.5 EXAMPLE NETWORKS
The subject of computer networking covers many different kinds of networks, large and small, well known and less well known. They have different goals, scales, and technologies. In the following sections, we will look at some ex- amples, to get an idea of the variety one finds in the area of computer networking.
We will start with the Internet, probably the best known network, and look at its history, evolution, and technology. Then we will consider the mobile phone network. Technically, it is quite different from the Internet, contrasting nicely with it. Next we will introduce IEEE 802.11, the dominant standard for wireless LANs. Finally, we will look at RFID and sensor networks, technologies that ex- tend the reach of the network to include the physical world and everyday objects.
1.5.1 The Internet
The Internet is not really a network at all, but a vast collection of different networks that use certain common protocols and provide certain common ser- vices. It is an unusual system in that it was not planned by anyone and is not con- trolled by anyone. To better understand it, let us start from the beginning and see how it has developed and why. For a wonderful history of the Internet, John Naughton’s (2000) book is highly recommended. It is one of those rare books that is not only fun to read, but also has 20 pages ofibid.’s andop. cit.’s for the serious historian. Some of the material in this section is based on this book.
SEC. 1.5 EXAMPLE NETWORKS 55 Of course, countless technical books have been written about the Internet and its protocols as well. For more information, see, for example, Maufer (1999).
The ARPANET
The story begins in the late 1950s. At the height of the Cold War, the U.S.
DoD wanted a command-and-control network that could survive a nuclear war.
At that time, all military communications used the public telephone network, which was considered vulnerable. The reason for this belief can be gleaned from Fig. 1-25(a). Here the black dots represent telephone switching offices, each of which was connected to thousands of telephones. These switching offices were, in turn, connected to higher-level switching offices (toll offices), to form a national hierarchy with only a small amount of redundancy. The vulnerability of the system was that the destruction of a few key toll offices could fragment it into many isolated islands.
(a) Toll
office Switching
office
(b)
Figure 1-25. (a) Structure of the telephone system. (b) Baran’s proposed dis- tributed switching system.
Around 1960, the DoD awarded a contract to the RAND Corporation to find a solution. One of its employees, Paul Baran, came up with the highly distributed and fault-tolerant design of Fig. 1-25(b). Since the paths between any two switch- ing offices were now much longer than analog signals could travel without distor- tion, Baran proposed using digital packet-switching technology. Baran wrote sev- eral reports for the DoD describing his ideas in detail (Baran, 1964). Officials at the Pentagon liked the concept and asked AT&T, then the U.S.’ national tele- phone monopoly, to build a prototype. AT&T dismissed Baran’s ideas out of hand. The biggest and richest corporation in the world was not about to allow
some young whippersnapper tell it how to build a telephone system. They said Baran’s network could not be built and the idea was killed.
Several years went by and still the DoD did not have a better command-and- control system. To understand what happened next, we have to go back all the way to October 1957, when the Soviet Union beat the U.S. into space with the launch of the first artificial satellite, Sputnik. When President Eisenhower tried to find out who was asleep at the switch, he was appalled to find the Army, Navy, and Air Force squabbling over the Pentagon’s research budget. His immediate response was to create a single defense research organization, ARPA, the Advanced Research Projects Agency. ARPA had no scientists or laboratories;
in fact, it had nothing more than an office and a small (by Pentagon standards) budget. It did its work by issuing grants and contracts to universities and com- panies whose ideas looked promising to it.
For the first few years, ARPA tried to figure out what its mission should be.
In 1967, the attention of Larry Roberts, a program manager at ARPA who was trying to figure out how to provide remote access to computers, turned to net- working. He contacted various experts to decide what to do. One of them, Wes- ley Clark, suggested building a packet-switched subnet, connecting each host to its own router.
After some initial skepticism, Roberts bought the idea and presented a some- what vague paper about it at the ACM SIGOPS Symposium on Operating System Principles held in Gatlinburg, Tennessee in late 1967 (Roberts, 1967). Much to Roberts’ surprise, another paper at the conference described a similar system that had not only been designed but actually fully implemented under the direction of Donald Davies at the National Physical Laboratory in England. The NPL system was not a national system (it just connected several computers on the NPL campus), but it demonstrated that packet switching could be made to work. Fur- thermore, it cited Baran’s now discarded earlier work. Roberts came away from Gatlinburg determined to build what later became known as theARPANET.
The subnet would consist of minicomputers called IMPs(Interface Message Processors) connected by 56-kbps transmission lines. For high reliability, each IMP would be connected to at least two other IMPs. The subnet was to be a datagram subnet, so if some lines and IMPs were destroyed, messages could be automatically rerouted along alternative paths.
Each node of the network was to consist of an IMP and a host, in the same room, connected by a short wire. A host could send messages of up to 8063 bits to its IMP, which would then break these up into packets of at most 1008 bits and forward them independently toward the destination. Each packet was received in its entirety before being forwarded, so the subnet was the first electronic store- and-forward packet-switching network.
ARPA then put out a tender for building the subnet. Twelve companies bid for it. After evaluating all the proposals, ARPA selected BBN, a consulting firm based in Cambridge, Massachusetts, and in December 1968 awarded it a contract
SEC. 1.5 EXAMPLE NETWORKS 57 to build the subnet and write the subnet software. BBN chose to use specially modified Honeywell DDP-316 minicomputers with 12K 16-bit words of core memory as the IMPs. The IMPs did not have disks, since moving parts were con- sidered unreliable. The IMPs were interconnected by 56-kbps lines leased from telephone companies. Although 56 kbps is now the choice of teenagers who can- not afford DSL or cable, it was then the best money could buy.
The software was split into two parts: subnet and host. The subnet software consisted of the IMP end of the host-IMP connection, the IMP-IMP protocol, and a source IMP to destination IMP protocol designed to improve reliability. The original ARPANET design is shown in Fig. 1-26.
Host-IMP protocol
Host-host protocol
Source IMPto destinationIMP protocol IMP-IMP protocol IMP-IMP
protocol
Host
IMP Subnet
Figure 1-26. The original ARPANET design.
Outside the subnet, software was also needed, namely, the host end of the host-IMP connection, the host-host protocol, and the application software. It soon became clear that BBN was of the opinion that when it had accepted a message on a host-IMP wire and placed it on the host-IMP wire at the destination, its job was done.
Roberts had a problem, though: the hosts needed software too. To deal with it, he convened a meeting of network researchers, mostly graduate students, at Snowbird, Utah, in the summer of 1969. The graduate students expected some network expert to explain the grand design of the network and its software to them and then assign each of them the job of writing part of it. They were astounded when there was no network expert and no grand design. They had to figure out what to do on their own.
Nevertheless, somehow an experimental network went online in December 1969 with four nodes: at UCLA, UCSB, SRI, and the University of Utah. These four were chosen because all had a large number of ARPA contracts, and all had different and completely incompatible host computers (just to make it more fun).
The first host-to-host message had been sent two months earlier from the UCLA
node by a team led by Len Kleinrock (a pioneer of the theory of packet switching) to the SRI node. The network grew quickly as more IMPs were delivered and installed; it soon spanned the United States. Figure 1-27 shows how rapidly the ARPANET grew in the first 3 years.
MIT
BBN RAND UCLA UCLA
SRI UTAH ILLINOIS MIT LINCOLN CASE
CARN
HARVARD BURROUGHS RAND BBN
SDC STAN
UCLA SRI UTAH
UCSB SDC UCSB
SRI UTAH
UCSB
NCAR GWC LINCOLN CASE
MITRE ETAC
HARVARD NBS BBN
TINKER RAND
SDC USC AMES
STAN
UCLA
CARN SRI UTAH
MCCLELLAN
UCSB
ILLINOIS LINC RADC
MIT
ILLINOIS MIT
LINC
RADC UTAH
TINKER RAND
MCCLELLAN LBL
SRI
AMES TIP AMES IMP X-PARC
FNWC
UCSB UCSD STANFORD
CCA BBN HARVARD ABERDEEN
NBS ETAC
ARPA MITRE
SAAC BELVOIR
CMU
GWC CASE
NOAA USC
SDC UCLA
(a)
(d)
(b) (c)
(e)
Figure 1-27. Growth of the ARPANET. (a) December 1969. (b) July 1970.
(c) March 1971. (d) April 1972. (e) September 1972.
In addition to helping the fledgling ARPANET grow, ARPA also funded re- search on the use of satellite networks and mobile packet radio networks. In one now famous demonstration, a truck driving around in California used the packet radio network to send messages to SRI, which were then forwarded over the ARPANET to the East Coast, where they were shipped to University College in London over the satellite network. This allowed a researcher in the truck to use a computer in London while driving around in California.
This experiment also demonstrated that the existing ARPANET protocols were not suitable for running over different networks. This observation led to more research on protocols, culminating with the invention of the TCP/IP model and protocols (Cerf and Kahn, 1974). TCP/IP was specifically designed to handle communication over internetworks, something becoming increasingly important as more and more networks were hooked up to the ARPANET.
SEC. 1.5 EXAMPLE NETWORKS 59 To encourage adoption of these new protocols, ARPA awarded several con- tracts to implement TCP/IP on different computer platforms, including IBM, DEC, and HP systems, as well as for Berkeley UNIX. Researchers at the Univer- sity of California at Berkeley rewrote TCP/IP with a new programming interface called sockets for the upcoming 4.2BSD release of Berkeley UNIX. They also wrote many application, utility, and management programs to show how con- venient it was to use the network with sockets.
The timing was perfect. Many universities had just acquired a second or third VAX computer and a LAN to connect them, but they had no networking software.
When 4.2BSD came along, with TCP/IP, sockets, and many network utilities, the complete package was adopted immediately. Furthermore, with TCP/IP, it was easy for the LANs to connect to the ARPANET, and many did.
During the 1980s, additional networks, especially LANs, were connected to the ARPANET. As the scale increased, finding hosts became increasingly expen- sive, soDNS(Domain Name System) was created to organize machines into do- mains and map host names onto IP addresses. Since then, DNS has become a generalized, distributed database system for storing a variety of information relat- ed to naming. We will study it in detail in Chap. 7.
NSFNET
By the late 1970s, NSF (the U.S. National Science Foundation) saw the enor- mous impact the ARPANET was having on university research, allowing scien- tists across the country to share data and collaborate on research projects. How- ever, to get on the ARPANET a university had to have a research contract with the DoD. Many did not have a contract. NSF’s initial response was to fund the Computer Science Network (CSNET) in 1981. It connected computer science de- partments and industrial research labs to the ARPANET via dial-up and leased lines. In the late 1980s, the NSF went further and decided to design a successor to the ARPANET that would be open to all university research groups.
To have something concrete to start with, NSF decided to build a backbone network to connect its six supercomputer centers, in San Diego, Boulder, Cham- paign, Pittsburgh, Ithaca, and Princeton. Each supercomputer was given a little brother, consisting of an LSI-11 microcomputer called a fuzzball. The fuzzballs were connected with 56-kbps leased lines and formed the subnet, the same hard- ware technology the ARPANET used. The software technology was different however: the fuzzballs spoke TCP/IP right from the start, making it the first TCP/IP WAN.
NSF also funded some (eventually about 20) regional networks that connected to the backbone to allow users at thousands of universities, research labs, libraries, and museums to access any of the supercomputers and to communicate with one another. The complete network, including backbone and the regional networks, was called NSFNET. It connected to the ARPANET through a link between an
IMP and a fuzzball in the Carnegie-Mellon machine room. The first NSFNET backbone is illustrated in Fig. 1-28 superimposed on a map of the U.S.
NSF Supercomputer center NSF Midlevel network Both
Figure 1-28. The NSFNET backbone in 1988.
NSFNET was an instantaneous success and was overloaded from the word go.
NSF immediately began planning its successor and awarded a contract to the Michigan-based MERIT consortium to run it. Fiber optic channels at 448 kbps were leased from MCI (since merged with WorldCom) to provide the version 2 backbone. IBM PC-RTs were used as routers. This, too, was soon overwhelmed, and by 1990, the second backbone was upgraded to 1.5 Mbps.
As growth continued, NSF realized that the government could not continue financing networking forever. Furthermore, commercial organizations wanted to join but were forbidden by NSF’s charter from using networks NSF paid for.
Consequently, NSF encouraged MERIT, MCI, and IBM to form a nonprofit cor- poration, ANS (Advanced Networks and Services), as the first step along the road to commercialization. In 1990, ANS took over NSFNET and upgraded the 1.5-Mbps links to 45 Mbps to formANSNET. This network operated for 5 years and was then sold to America Online. But by then, various companies were offer- ing commercial IP service and it was clear the government should now get out of the networking business.
To ease the transition and make sure every regional network could communi- cate with every other regional network, NSF awarded contracts to four different network operators to establish a NAP(Network Access Point). These operators were PacBell (San Francisco), Ameritech (Chicago), MFS (Washington, D.C.), and Sprint (New York City, where for NAP purposes, Pennsauken, New Jersey counts as New York City). Every network operator that wanted to provide back- bone service to the NSF regional networks had to connect to all the NAPs.
SEC. 1.5 EXAMPLE NETWORKS 61 This arrangement meant that a packet originating on any regional network had a choice of backbone carriers to get from its NAP to the destination’s NAP. Con- sequently, the backbone carriers were forced to compete for the regional net- works’ business on the basis of service and price, which was the idea, of course.
As a result, the concept of a single default backbone was replaced by a commer- cially driven competitive infrastructure. Many people like to criticize the Federal Government for not being innovative, but in the area of networking, it was DoD and NSF that created the infrastructure that formed the basis for the Internet and then handed it over to industry to operate.
During the 1990s, many other countries and regions also built national re- search networks, often patterned on the ARPANET and NSFNET. These in- cluded EuropaNET and EBONE in Europe, which started out with 2-Mbps lines and then upgraded to 34-Mbps lines. Eventually, the network infrastructure in Europe was handed over to industry as well.
The Internet has changed a great deal since those early days. It exploded in size with the emergence of the World Wide Web (WWW) in the early 1990s.
Recent data from the Internet Systems Consortium puts the number of visible In- ternet hosts at over 600 million. This guess is only a low-ball estimate, but it far exceeds the few million hosts that were around when the first conference on the WWW was held at CERN in 1994.
The way we use the Internet has also changed radically. Initially, applications such as email-for-academics, newsgroups, remote login, and file transfer dom- inated. Later it switched to email-for-everyman, then the Web and peer-to-peer content distribution, such as the now-shuttered Napster. Now real-time media dis- tribution, social networks (e.g., Facebook), and microblogging (e.g., Twitter) are taking off. These switches brought richer kinds of media to the Internet and hence much more traffic. In fact, the dominant traffic on the Internet seems to change with some regularity as, for example, new and better ways to work with music or movies can become very popular very quickly.
Architecture of the Internet
The architecture of the Internet has also changed a great deal as it has grown explosively. In this section, we will attempt to give a brief overview of what it looks like today. The picture is complicated by continuous upheavals in the businesses of telephone companies (telcos), cable companies and ISPs that often make it hard to tell who is doing what. One driver of these upheavals is telecom- munications convergence, in which one network is used for previously different uses. For example, in a ‘‘triple play’’ one company sells you telephony, TV, and Internet service over the same network connection on the assumption that this will save you money. Consequently, the description given here will be of necessity somewhat simpler than reality. And what is true today may not be true tomorrow.
The big picture is shown in Fig. 1-29. Let us examine this figure piece by piece, starting with a computer at home (at the edges of the figure). To join the Internet, the computer is connected to an Internet Service Provider, or simply ISP, from who the user purchases Internet accessorconnectivity. This lets the computer exchange packets with all of the other accessible hosts on the Internet.
The user might send packets to surf the Web or for any of a thousand other uses, it does not matter. There are many kinds of Internet access, and they are usually distinguished by how much bandwidth they provide and how much they cost, but the most important attribute is connectivity.
Data center
Fiber (FTTH)
DSL Dialup
Cable 3G mobile
phone Tier 1 ISP
Other ISPs Peering
at IXP
POP Data
path
Router
Cable modem CMTS Backbone
DSLAM DSL modem
Figure 1-29. Overview of the Internet architecture.
A common way to connect to an ISP is to use the phone line to your house, in which case your phone company is your ISP. DSL, short for Digital Subscriber Line, reuses the telephone line that connects to your house for digital data transmission. The computer is connected to a device called a DSL modem that converts between digital packets and analog signals that can pass unhindered over the telephone line. At the other end, a device called a DSLAM (Digital Sub- scriber Line Access Multiplexer) converts between signals and packets.
Several other popular ways to connect to an ISP are shown in Fig. 1-29. DSL is a higher-bandwidth way to use the local telephone line than to send bits over a traditional telephone call instead of a voice conversation. That is called dial-up and done with a different kind of modem at both ends. The wordmodemis short for ‘‘modulatordemodulator’’ and refers to any device that converts between digi- tal bits and analog signals.
Another method is to send signals over the cable TV system. Like DSL, this is a way to reuse existing infrastructure, in this case otherwise unused cable TV