Computer Networks: A Systems Approach PDF

PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 1 #2 Foundation I must Create a System, or be enslav’d by another Man’s; I will not Reason and Compare: my business is to Create....

PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 1 #2 Foundation I must Create a System, or be enslav’d by another Man’s; I will not Reason and Compare: my business is to Create. –William Blake S uppose you want to build a computer network, one that has the potential to grow to global proportions and to support applica- tions as diverse as teleconferencing, video on demand, electronic commerce, distributed computing, and digital libraries. What avail- able technologies would serve as the underlying building blocks, and what kind of software architecture would you design to integrate these building blocks into an effective communica- tion service? Answering this question is the overriding goal of this book—to describe the available building materials and PROBLEM: BUILDING A NETWORK then to show how they can be used to construct a network from the ground up. Before we can understand how to design a computer net- work, we should first agree on exactly what a computer network is. At one time, the term network meant the set of serial lines used to attach dumb terminals to mainframe com- puters. Other important networks include the voice telephone network and the cable TV network used to disseminate video signals. The main things these networks have in common are that they are specialized to handle one particular kind of data Computer Networks: A Systems Approach. DOI: 10.1016/B978-0-12-385059-1.00001-6 Copyright © 2012 Elsevier,Inc. All rights reserved. 1 www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 2 #3 2 CHAPTER 1 Foundation (keystrokes, voice, or video) and they typically connect to special-purpose devices (terminals, hand receivers, and television sets). What distinguishes a computer network from these other types of networks? Probably the most important characteristic of a computer network is its generality. Computer networks are built primarily from general-purpose programmable hard- ware, and they are not optimized for a particular application like making phone calls or delivering television signals. Instead, they are able to carry many different types of data, and they support a wide, and ever growing, range of applications. Today’s com- puter networks are increasingly taking over the functions previously performed by single-use networks. This chapter looks at some typical applications of computer networks and discusses the requirements that a network designer who wishes to support such applications must be aware of. Once we understand the requirements, how do we proceed? Fortunately, we will not be building the first network. Others, most notably the community of researchers responsible for the Internet, have gone before us. We will use the wealth of experience generated from the Internet to guide our design. This experience is embodied in a network architecture that identifies the available hardware and software components and shows how they can be arranged to form a complete network system. In addition to understanding how networks are built, it is increasingly important to understand how they are operated or managed and how network applications are developed. Most of us now have computer networks in our homes, offices, and in some cases in our cars, so operating networks is no longer a matter only for a few specialists. And, with the proliferation of programmable, network-attached devices such as smartphones, many more of this generation will develop networked applications than in the past. So we need to consider networks from these multiple perspectives: builders, operators, application developers. To start us on the road toward understanding how to build, operate, and pro- gram a network, this chapter does four things. First, it explores the requirements that different applications and different communities of people place on the network. Second, it introduces the idea of a network architecture, which lays the foundation for the rest of the book. Third, it introduces some of the key elements in the imple- mentation of computer networks. Finally, it identifies the key metrics that are used to evaluate the performance of computer networks. 1.1 APPLICATIONS Most people know the Internet through its applications: the World Wide Web, email, online social networking, streaming audio and video, instant messaging, file-sharing, to name just a few examples. That is to say, we www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 3 #4 1.1 Applications 3 interact with the Internet as users of the network. Internet users repre- sent the largest class of people who interact with the Internet in some way, but there are several other important constituencies. There is the group of people who create the applications—a group that has greatly expanded in recent years as powerful programming platforms and new devices such as smartphones have created new opportunities to develop applications quickly and to bring them to a large market. Then there are those who oper- ate or manage networks—mostly a behind-the-scenes job, but a critical one and often a very complex one. With the prevalence of home networks, more and more people are also becoming, if only in a small way, network operators. Finally, there are those who design and build the devices and protocols that collectively make up the Internet. That final constituency is the traditional target of networking textbooks such as this one and will continue to be our main focus. However, throughout this book we will also consider the perspectives of application developers and network opera- tors. Considering these perspectives will enable us to better understand the diverse requirements that a network must meet. Application developers will also be able to make applications that work better if they understand how the underlying technology works and interacts with the applica- tions. So, before we start figuring out how to build a network, let’s look more closely at the types of applications that today’s networks support. 1.1.1 Classes of Applications The World Wide Web is the Internet application that catapulted the Inter- net from a somewhat obscure tool used mostly by scientists and engineers to the mainstream phenomenon that it is today. The Web itself has become such a powerful platform that many people confuse it with the Internet (as in “the Interwebs”), and it’s a bit of a stretch to say that the Web is a single application. In its basic form, the Web presents an intuitively simple interface. Users view pages full of textual and graphical objects and click on objects that they want to learn more about, and a corresponding new page appears. Most people are also aware that just under the covers each selectable object on a page is bound to an identifier for the next page or object to be viewed. This identifier, called a Uniform Resource Locator (URL), pro- vides a way of identifying all the possible objects that can be viewed from your web browser. For example, http://www.cs.princeton.edu/˜llp/index.html www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 4 #5 4 CHAPTER 1 Foundation is the URL for a page providing information about one of this book’s authors: the string http indicates that the Hypertext Transfer Protocol (HTTP) should be used to download the page, www.cs.princeton.edu is the name of the machine that serves the page, and /˜llp/index.html uniquely identifies Larry’s home page at this site. What most web users are not aware of, however, is that by clicking on just one such URL over a dozen messages may be exchanged over the Internet, and many more than that if the web page is complicated with lots of embedded objects. This message exchange includes up to six messages to translate the server name (www.cs.princeton.edu) into its Internet Protocol (IP) address (128.112.136.35), three messages to set up a Transmission Control Protocol (TCP) connection between your browser and this server, four messages for your browser to send the HTTP “GET” request and the server to respond with the requested page (and for each side to acknowledge receipt of that message), and four messages to tear down the TCP connection. Of course, this does not include the millions of messages exchanged by Internet nodes throughout the day, just to let each other know that they exist and are ready to serve web pages, trans- late names to addresses, and forward messages toward their ultimate destination. Another widespread application class of the Internet is the delivery of “streaming” audio and video. Services such as video on demand and Internet radio use this technology. While we frequently start at a web- site to initiate a streaming session, the delivery of audio and video has some important differences from fetching a simple web page of text and images. For example, you often don’t want to download an entire video file—a process that might take minutes to hours—before watching the first scene. Streaming audio and video implies a more timely transfer of messages from sender to receiver, and the receiver displays the video or plays the audio pretty much as it arrives. Note that the difference between streaming applications and the more traditional delivery of a page of text or still images is that humans consume audio and video streams in a continuous manner, and discontinuity—in the form of skipped sounds or stalled video—is not acceptable. By contrast, a page of text can be delivered and read in bits and pieces. This difference affects how the network supports these different classes of applications. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 5 #6 1.1 Applications 5 A subtly different application class is real-time audio and video. These applications have considerably tighter timing constraints than streaming applications. When using a voice-over-IP application such as Skype™ or a videoconferencing application, the interactions among the participants must be timely. When a person at one end gestures, then that action must be displayed at the other end as quickly as possible. When one person tries to interrupt another, the interrupted person needs to hear that as soon as possible1 and decide whether to allow the interruption or to keep talking over the interrupter. Too much delay in this sort of environment makes the system unusable. Contrast this with video on demand where, if it takes several seconds from the time the user starts the video until the first image is displayed, the service is still deemed satisfactory. Also, interactive applications usually entail audio and/or video flows in both directions, while a streaming application is most likely sending video or audio in only one direction. Videoconferencing tools that run over the Internet have been around now since the early 1990s but have achieved much more widespread use in the last couple of years, as higher network speeds and more powerful computers have become commonplace. An example of one such system is shown in Figure 1.1. Just as downloading a web page involves a bit more than meets the eye, so too with video applications. Fitting the video content into a relatively low bandwidth network, for example, or mak- ing sure that the video and audio remain in sync and arrive in time for a good user experience are all problems that network and protocol design- ers have to worry about. We’ll look at these and many other issues related to multimedia applications later in the book. Although they are just two examples, downloading pages from the web and participating in a videoconference demonstrate the diversity of applications that can be built on top of the Internet and hint at the complexity of the Internet’s design. Later in the book we will develop a more complete taxonomy of application types to help guide our discus- sion of key design decisions as we seek to build, operate, and use networks that support such a wide range of applications. In Chapter 9, the book concludes by revisiting these two specific applications, as well as several others that illustrate the breadth of what is possible on today’s Internet. 1 Not quite “as soon as possible”—human factors research indicates 300 ms is a reason- able upper bound for how much round-trip delay can be tolerated in a telephone call before humans complain, and a 100-ms delay sounds very good. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 6 #7 6 CHAPTER 1 Foundation n FIGURE 1.1 A multimedia application including videoconferencing. For now, this quick look at a few typical applications will suffice to enable LAB 00: us to start looking at the problems that must be addressed if we are to Introduction build a network that supports such application diversity. 1.2 REQUIREMENTS We have established an ambitious goal for ourselves: to understand how to build a computer network from the ground up. Our approach to accomplishing this goal will be to start from first principles and then ask the kinds of questions we would naturally ask if building an actual network. At each step, we will use today’s protocols to illustrate vari- ous design choices available to us, but we will not accept these existing artifacts as gospel. Instead, we will be asking (and answering) the ques- tion of why networks are designed the way they are. While it is tempting www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 7 #8 1.2 Requirements 7 to settle for just understanding the way it’s done today, it is important to recognize the underlying concepts because networks are constantly changing as the technology evolves and new applications are invented. It is our experience that once you understand the fundamental ideas, any new protocol that you are confronted with will be relatively easy to digest. 1.2.1 Perspectives As we noted above, a student of networks can take several perspectives. When we wrote the first edition of this book, the majority of the popula- tion had no Internet access at all, and those who did obtained it while at work, at a university, or by a dial-up modem at home. The set of popular applications could be counted on one’s fingers. Thus, like most books at the time, ours focused on the perspective of someone who would design networking equipment and protocols. We continue to focus on this per- spective, and our hope is that after reading this book you will know how to design the networking equipment and protocols of the future. However, we also want to cover the perspectives of two additional groups that are of increasing importance: those who develop networked applications and those who manage or operate networks. Let’s consider how these three groups might list their requirements for a network: n An application programmer would list the services that his or her application needs—for example, a guarantee that each message the application sends will be delivered without error within a certain amount of time or the ability to switch gracefully among different connections to the network as the user moves around. n A network operator would list the characteristics of a system that is easy to administer and manage—for example, in which faults can be easily isolated, new devices can be added to the network and configured correctly, and it is easy to account for usage. n A network designer would list the properties of a cost-effective design—for example, that network resources are efficiently utilized and fairly allocated to different users. Issues of performance are also likely to be important. This section attempts to distill these different perspectives into a high- level introduction to the major considerations that drive network design and, in doing so, identifies the challenges addressed throughout the rest of this book. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 8 #9 8 CHAPTER 1 Foundation 1.2.2 Scalable Connectivity Starting with the obvious, a network must provide connectivity among a set of computers. Sometimes it is enough to build a limited network that connects only a few select machines. In fact, for reasons of privacy and security, many private (corporate) networks have the explicit goal of lim- iting the set of machines that are connected. In contrast, other networks (of which the Internet is the prime example) are designed to grow in a way that allows them the potential to connect all the computers in the world. A system that is designed to support growth to an arbitrarily large size is said to scale. Using the Internet as a model, this book addresses the challenge of scalability. Links, Nodes, and Clouds To understand the requirements of connectivity more fully, we need to take a closer look at how computers are connected in a network. Connec- tivity occurs at many different levels. At the lowest level, a network can consist of two or more computers directly connected by some physical medium, such as a coaxial cable or an optical fiber. We call such a phys- ical medium a link, and we often refer to the computers it connects as nodes. (Sometimes a node is a more specialized piece of hardware rather than a computer, but we overlook that distinction for the purposes of this discussion.) As illustrated in Figure 1.2, physical links are sometimes lim- ited to a pair of nodes (such a link is said to be point-to-point), while in other cases more than two nodes may share a single physical link (such a link is said to be multiple-access). Wireless links, such as those provided by cellular networks and Wi-Fi networks, are an increasingly important class of multiple-access links. It is often the case that multiple-access links are limited in size, in terms of both the geographical distance they can cover and the number of nodes they can connect. If computer networks were limited to situations in which all nodes are directly connected to each other over a common physical medium, then either networks would be very limited in the number of comput- ers they could connect, or the number of wires coming out of the back of each node would quickly become both unmanageable and very expen- sive. Fortunately, connectivity between two nodes does not necessarily imply a direct physical connection between them—indirect connectiv- ity may be achieved among a set of cooperating nodes. Consider the www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 9 #10 1.2 Requirements 9 (a) (b) n FIGURE 1.2 Direct links: (a) point-to-point; (b) multiple-access. following two examples of how a collection of computers can be indirectly connected. Figure 1.3 shows a set of nodes, each of which is attached to one or more point-to-point links. Those nodes that are attached to at least two links run software that forwards data received on one link out on another. If organized in a systematic way, these forwarding nodes form a switched network. There are numerous types of switched networks, of which the two most common are circuit switched and packet switched. The former is most notably employed by the telephone system, while the latter is used for the overwhelming majority of computer networks and will be the focus of this book. (Circuit switching is, however, making a bit of a comeback in the optical networking realm, which turns out to be impor- tant as demand for network capacity constantly grows.) The important feature of packet-switched networks is that the nodes in such a network send discrete blocks of data to each other. Think of these blocks of data as corresponding to some piece of application data such as a file, a piece of email, or an image. We call each block of data either a packet or a message, and for now we use these terms interchangeably; we discuss the reason they are not always the same in Section 1.2.3. Packet-switched networks typically use a strategy called store-and- forward. As the name suggests, each node in a store-and-forward network first receives a complete packet over some link, stores the packet in its internal memory, and then forwards the complete packet to the next www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 10 #11 10 CHAPTER 1 Foundation n FIGURE 1.3 Switched network. node. In contrast, a circuit-switched network first establishes a dedicated circuit across a sequence of links and then allows the source node to send a stream of bits across this circuit to a destination node. The major rea- son for using packet switching rather than circuit switching in a computer network is efficiency, discussed in the next subsection. The cloud in Figure 1.3 distinguishes between the nodes on the inside that implement the network (they are commonly called switches, and their primary function is to store and forward packets) and the nodes on the outside of the cloud that use the network (they are commonly called hosts, and they support users and run application programs). Also note that the cloud in Figure 1.3 is one of the most important icons of computer networking. In general, we use a cloud to denote any type of network, whether it is a single point-to-point link, a multiple-access link, or a switched network. Thus, whenever you see a cloud used in a figure, www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 11 #12 1.2 Requirements 11 n FIGURE 1.4 Interconnection of networks. you can think of it as a placeholder for any of the networking technologies covered in this book.2 A second way in which a set of computers can be indirectly connected is shown in Figure 1.4. In this situation, a set of independent networks (clouds) are interconnected to form an internetwork, or internet for short. We adopt the Internet’s convention of referring to a generic internet- work of networks as a lowercase i internet, and the currently operational TCP/IP Internet as the capital I Internet. A node that is connected to two or more networks is commonly called a router or gateway, and it plays much the same role as a switch—it forwards messages from one net- work to another. Note that an internet can itself be viewed as another kind of network, which means that an internet can be built from an interconnection of internets. Thus, we can recursively build arbitrarily large networks by interconnecting clouds to form larger clouds. It can 2 Interestingly, the use of clouds in this way predates the term cloud computing by at least a couple of decades, but there is a connection between these two usages, which we’ll discuss later. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 12 #13 12 CHAPTER 1 Foundation reasonably be argued that this idea of interconnecting widely differing networks was the fundamental innovation of the Internet and that the successful growth of the Internet to global size and billions of nodes was the result of some very good design decisions by the early Internet architects, which we will discuss later. Just because a set of hosts are directly or indirectly connected to each other does not mean that we have succeeded in providing host-to-host connectivity. The final requirement is that each node must be able to say which of the other nodes on the network it wants to communicate with. This is done by assigning an address to each node. An address is a byte string that identifies a node; that is, the network can use a node’s address to distinguish it from the other nodes connected to the network. When a source node wants the network to deliver a message to a certain destination node, it specifies the address of the destination node. If the sending and receiving nodes are not directly connected, then the switches and routers of the network use this address to decide how to forward the message toward the destination. The process of determining systemati- cally how to forward messages toward the destination node based on its address is called routing. This brief introduction to addressing and routing has presumed that the source node wants to send a message to a single destination node (unicast). While this is the most common scenario, it is also possible that the source node might want to broadcast a message to all the nodes on the network. Or, a source node might want to send a message to some subset of the other nodes but not all of them, a situation called multicast. Thus, in addition to node-specific addresses, another requirement of a network is that it support multicast and broadcast addresses. The main idea to take away from this discussion is that we can define a network recursively as consisting of two or more nodes connected by a physical link, or as two or more networks connected by a node. In other words, a network can be constructed from a nesting of networks, where at the bottom level, the network is implemented by some physical medium. Among the key challenges in providing network connectivity are the definition of an address for each node that is reach- able on the network (including support for broadcast and multicast), and the use of such addresses to forward messages toward the appropriate destination node(s). www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 13 #14 1.2 Requirements 13 1.2.3 Cost-Effective Resource Sharing As stated above, this book focuses on packet-switched networks. This section explains the key requirement of computer networks—efficiency— that leads us to packet switching as the strategy of choice. Given a collection of nodes indirectly connected by a nesting of net- works, it is possible for any pair of hosts to send messages to each other across a sequence of links and nodes. Of course, we want to do more than support just one pair of communicating hosts—we want to provide all pairs of hosts with the ability to exchange messages. The question, then, is how do all the hosts that want to communicate share the network, espe- cially if they want to use it at the same time? And, as if that problem isn’t hard enough, how do several hosts share the same link when they all want to use it at the same time? To understand how hosts share a network, we need to introduce a fun- damental concept, multiplexing, which means that a system resource is shared among multiple users. At an intuitive level, multiplexing can be explained by analogy to a timesharing computer system, where a single physical processor is shared (multiplexed) among multiple jobs, each of which believes it has its own private processor. Similarly, data being sent by multiple users can be multiplexed over the physical links that make up a network. To see how this might work, consider the simple network illustrated in Figure 1.5, where the three hosts on the left side of the network (senders S1–S3) are sending data to the three hosts on the right (receivers R1–R3) by sharing a switched network that contains only one physical link. (For simplicity, assume that host S1 is sending data to host R1, and so on.) In this situation, three flows of data—corresponding to the three pairs of hosts—are multiplexed onto a single physical link by switch 1 and then demultiplexed back into separate flows by switch 2. Note that we are being intentionally vague about exactly what a “flow of data” corresponds to. For the purposes of this discussion, assume that each host on the left has a large supply of data that it wants to send to its counterpart on the right. There are several different methods for multiplexing multiple flows onto one physical link. One common method is synchronous time- division multiplexing (STDM). The idea of STDM is to divide time into equal-sized quanta and, in a round-robin fashion, give each flow a chance www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 14 #15 14 CHAPTER 1 Foundation S1 R1 Switch 1 Switch 2 S2 R2 S3 R3 n FIGURE 1.5 Multiplexing multiple logical flows over a single physical link. to send its data over the physical link. In other words, during time quan- tum 1, data from S1 to R1 is transmitted; during time quantum 2, data from S2 to R2 is transmitted; in quantum 3, S3 sends data to R3. At this point, the first flow (S1 to R1) gets to go again, and the process repeats. Another method is frequency-division multiplexing (FDM). The idea of FDM is to transmit each flow over the physical link at a different frequency, much the same way that the signals for different TV stations are transmitted at a different frequency over the airwaves or on a coaxial cable TV link. Although simple to understand, both STDM and FDM are limited in two ways. First, if one of the flows (host pairs) does not have any data to send, its share of the physical link—that is, its time quantum or its frequency—remains idle, even if one of the other flows has data to trans- mit. For example, S3 had to wait its turn behind S1 and S2 in the previous paragraph, even if S1 and S2 had nothing to send. For computer com- munication, the amount of time that a link is idle can be very large—for example, consider the amount of time you spend reading a web page (leaving the link idle) compared to the time you spend fetching the page. Second, both STDM and FDM are limited to situations in which the maxi- mum number of flows is fixed and known ahead of time. It is not practical www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 15 #16 1.2 Requirements 15 to resize the quantum or to add additional quanta in the case of STDM or to add new frequencies in the case of FDM. The form of multiplexing that addresses these shortcomings, and of which we make most use in this book, is called statistical multiplexing. Although the name is not all that helpful for understanding the concept, statistical multiplexing is really quite simple, with two key ideas. First, it is like STDM in that the physical link is shared over time—first data from one flow is transmitted over the physical link, then data from another flow is transmitted, and so on. Unlike STDM, however, data is transmitted from each flow on demand rather than during a predetermined time slot. Thus, if only one flow has data to send, it gets to transmit that data without wait- ing for its quantum to come around and thus without having to watch the quanta assigned to the other flows go by unused. It is this avoidance of idle time that gives packet switching its efficiency. As defined so far, however, statistical multiplexing has no mechanism to ensure that all the flows eventually get their turn to transmit over the physical link. That is, once a flow begins sending data, we need some way to limit the transmission, so that the other flows can have a turn. To account for this need, statistical multiplexing defines an upper bound on the size of the block of data that each flow is permitted to transmit at a given time. This limited-size block of data is typically referred to as a packet, to distinguish it from the arbitrarily large message that an applica- tion program might want to transmit. Because a packet-switched network limits the maximum size of packets, a host may not be able to send a complete message in one packet. The source may need to fragment the message into several packets, with the receiver reassembling the packets back into the original message. In other words, each flow sends a sequence of packets over the physical link, with a decision made on a packet-by-packet basis as to which flow’s packet to send next. Notice that, if only one flow has data to send, then it can send a sequence of packets back-to-back; however, should more than one of the flows have data to send, then their packets are interleaved on the link. Figure 1.6 depicts a switch multiplexing packets from multiple sources onto a single shared link. The decision as to which packet to send next on a shared link can be made in a number of different ways. For example, in a network consisting of switches interconnected by links such as the one in Figure 1.5, the www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 16 #17 16 CHAPTER 1 Foundation n FIGURE 1.6 A switch multiplexing packets from multiple sources onto one shared link. decision would be made by the switch that transmits packets onto the shared link. (As we will see later, not all packet-switched networks actu- ally involve switches, and they may use other mechanisms to determine whose packet goes onto the link next.) Each switch in a packet-switched network makes this decision independently, on a packet-by-packet basis. One of the issues that faces a network designer is how to make this deci- sion in a fair manner. For example, a switch could be designed to service packets on a first-in, first-out (FIFO) basis. Another approach would be to transmit the packets from each of the different flows that are currently sending data through the switch in a round-robin manner. This might be done to ensure that certain flows receive a particular share of the link’s bandwidth or that they never have their packets delayed in the switch for more than a certain length of time. A network that attempts to allo- cate bandwidth to particular flows is sometimes said to support quality of service (QoS), a topic that we return to in Chapter 6. Also, notice in Figure 1.6 that since the switch has to multiplex three incoming packet streams onto one outgoing link, it is possible that the switch will receive packets faster than the shared link can accommodate. In this case, the switch is forced to buffer these packets in its mem- ory. Should a switch receive packets faster than it can send them for an extended period of time, then the switch will eventually run out of www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 17 #18 1.2 Requirements 17 buffer space, and some packets will have to be dropped. When a switch is operating in this state, it is said to be congested. The bottom line is that statistical multiplexing defines a cost-effective way for multiple users (e.g., host-to-host flows of data) to share network resources (links and nodes) in a fine-grained manner. It defines the packet as the granularity with which the links of the network are allocated to different flows, with each switch able to schedule the use of the physical links it is connected to on a per-packet basis. Fairly allocating link capacity to different flows and dealing with congestion when it occurs are the key challenges of statistical multiplexing. SANs, LANs, MANs, and WANs One way to characterize networks is according to their size. Two well-known examples are local area networks (LANs) and wide area networks (WANs); the former typically extend less than 1 km, while the latter can be worldwide. Other networks are classified as metropolitan area networks (MANs), which usually span tens of kilometers. The reason such classifications are interest- ing is that the size of a network often has implications for the underlying technology that can be used, with a key factor being the amount of time it takes for data to propagate from one end of the network to the other; we discuss this issue more in later chapters. An interesting historical note is that the term wide area network was not applied to the first WANs because there was no other sort of network to dif- ferentiate them from. When computers were incredibly rare and expensive, there was no point in thinking about how to connect all the computers in the local area—there was only one computer in that area. Only as comput- ers began to proliferate did LANs become necessary, and the term “WAN” was then introduced to describe the larger networks that interconnected geographically distant computers. Another kind of network that we need to be aware of is SANs (usually now expanded as storage area networks, but formerly also known as sys- tem area networks). SANs are usually confined to a single room and connect the various components of a large computing system. For example, Fibre Channel is a common SAN technology used to connect high-performance computing systems to storage servers and data vaults. Although this book does not describe such networks in detail, they are worth knowing about because they are often at the leading edge in terms of performance, and because it is increasingly common to connect such networks into LANs and WANs. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 18 #19 18 CHAPTER 1 Foundation 1.2.4 Support for Common Services The previous section outlined the challenges involved in providing cost- effective connectivity among a group of hosts, but it is overly simplistic to view a computer network as simply delivering packets among a collection of computers. It is more accurate to think of a network as providing the means for a set of application processes that are distributed over those computers to communicate. In other words, the next requirement of a computer network is that the application programs running on the hosts connected to the network must be able to communicate in a meaningful way. From the application developer’s perspective, the network needs to make his or her life easier. When two application programs need to communicate with each other, a lot of complicated things must happen beyond simply sending a message from one host to another. One option would be for application designers to build all that complicated functionality into each application program. However, since many applications need common services, it is much more logical to implement those common services once and then to let the application designer build the application using those services. The challenge for a network designer is to identify the right set of com- mon services. The goal is to hide the complexity of the network from the application without overly constraining the application designer. Intuitively, we view the network as providing logical channels over which application-level processes can communicate with each other; each channel provides the set of services required by that application. In other words, just as we use a cloud to abstractly represent connectivity among a set of computers, we now think of a channel as connecting one process to another. Figure 1.7 shows a pair of application-level processes communicating over a logical channel that is, in turn, implemented on top of a cloud that connects a set of hosts. We can think of the channel as being like a pipe connecting two applications, so that a sending applica- tion can put data in one end and expect that data to be delivered by the network to the application at the other end of the pipe. The challenge is to recognize what functionality the channels should provide to application programs. For example, does the application require a guarantee that messages sent over the channel are delivered, or is it acceptable if some messages fail to arrive? Is it necessary that mes- sages arrive at the recipient process in the same order in which they are sent, or does the recipient not care about the order in which messages www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 19 #20 1.2 Requirements 19 Host Host Application Host Application Host Host n FIGURE 1.7 Processes communicating over an abstract channel. arrive? Does the network need to ensure that no third parties are able to eavesdrop on the channel, or is privacy not a concern? In general, a network provides a variety of different types of channels, with each appli- cation selecting the type that best meets its needs. The rest of this section illustrates the thinking involved in defining useful channels. Identifying Common Communication Patterns Designing abstract channels involves first understanding the communi- cation needs of a representative collection of applications, then extracting their common communication requirements, and finally incorporating the functionality that meets these requirements in the network. One of the earliest applications supported on any network is a file access program like the File Transfer Protocol (FTP) or Network File Sys- tem (NFS). Although many details vary—for example, whether whole files are transferred across the network or only single blocks of the file are read/ written at a given time—the communication component of remote file access is characterized by a pair of processes, one that requests that a file be read or written and a second process that honors this request. The www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 20 #21 20 CHAPTER 1 Foundation process that requests access to the file is called the client, and the process that supports access to the file is called the server. Reading a file involves the client sending a small request message to a server and the server responding with a large message that contains the data in the file. Writing works in the opposite way—the client sends a large message containing the data to be written to the server, and the server responds with a small message confirming that the write to disk has taken place. A digital library is a more sophisticated application than file transfer, but it requires similar communication services. For example, the Associ- ation for Computing Machinery (ACM) operates a large digital library of computer science literature at http://portal.acm.org/dl.cfm This library has a wide range of searching and browsing features to help users find the articles they want, but ultimately much of what it does is respond to user requests for files, such as electronic copies of journal articles, much like an FTP server. Using file access, a digital library, and the two video applications described in the introduction (videoconferencing and video on demand) as a representative sample, we might decide to provide the following two types of channels: request/reply channels and message stream channels. The request/reply channel would be used by the file transfer and digital library applications. It would guarantee that every message sent by one side is received by the other side and that only one copy of each message is delivered. The request/reply channel might also protect the privacy and integrity of the data that flows over it, so that unauthorized parties cannot read or modify the data being exchanged between the client and server processes. The message stream channel could be used by both the video on demand and videoconferencing applications, provided it is parameter- ized to support both one-way and two-way traffic and to support different delay properties. The message stream channel might not need to guaran- tee that all messages are delivered, since a video application can operate adequately even if some video frames are not received. It would, however, need to ensure that those messages that are delivered arrive in the same order in which they were sent, to avoid displaying frames out of sequence. Like the request/reply channel, the message stream channel might want www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 21 #22 1.2 Requirements 21 to ensure the privacy and integrity of the video data. Finally, the message stream channel might need to support multicast, so that multiple parties can participate in the teleconference or view the video. While it is common for a network designer to strive for the smallest number of abstract channel types that can serve the largest number of applications, there is a danger in trying to get away with too few channel abstractions. Simply stated, if you have a hammer, then everything looks like a nail. For example, if all you have are message stream and request/ reply channels, then it is tempting to use them for the next application that comes along, even if neither type provides exactly the semantics needed by the application. Thus, network designers will probably be inventing new types of channels—and adding options to existing channels—for as long as application programmers are inventing new applications. Also note that independent of exactly what functionality a given chan- nel provides, there is the question of where that functionality is imple- mented. In many cases, it is easiest to view the host-to-host connectivity of the underlying network as simply providing a bit pipe, with any high- level communication semantics provided at the end hosts. The advantage of this approach is that it keeps the switches in the middle of the network as simple as possible—they simply forward packets—but it requires the end hosts to take on much of the burden of supporting semantically rich process-to-process channels. The alternative is to push additional func- tionality onto the switches, thereby allowing the end hosts to be “dumb” devices (e.g., telephone handsets). We will see this question of how vari- ous network services are partitioned between the packet switches and the end hosts (devices) as a recurring issue in network design. Reliability As suggested by the examples just considered, reliable message delivery is one of the most important functions that a network can provide. It is difficult to determine how to provide this reliability, however, without first understanding how networks can fail. The first thing to recognize is that computer networks do not exist in a perfect world. Machines crash and later are rebooted, fibers are cut, electrical interference corrupts bits in the data being transmitted, switches run out of buffer space, and, as if these sorts of physical problems aren’t enough to worry about, the software that manages the hardware may contain bugs and sometimes forwards packets into oblivion. Thus, a major requirement of a network www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 22 #23 22 CHAPTER 1 Foundation is to recover from certain kinds of failures, so that application programs don’t have to deal with them or even be aware of them. There are three general classes of failure that network designers have to worry about. First, as a packet is transmitted over a physical link, bit errors may be introduced into the data; that is, a 1 is turned into a 0 or vice versa. Sometimes single bits are corrupted, but more often than not a burst error occurs—several consecutive bits are corrupted. Bit errors typi- cally occur because outside forces, such as lightning strikes, power surges, and microwave ovens, interfere with the transmission of data. The good news is that such bit errors are fairly rare, affecting on average only one out of every 106 to 107 bits on a typical copper-based cable and one out of every 1012 to 1014 bits on a typical optical fiber. As we will see, there are techniques that detect these bit errors with high probability. Once detected, it is sometimes possible to correct for such errors—if we know which bit or bits are corrupted, we can simply flip them—while in other cases the damage is so bad that it is necessary to discard the entire packet. In such a case, the sender may be expected to retransmit the packet. The second class of failure is at the packet, rather than the bit, level; that is, a complete packet is lost by the network. One reason this can hap- pen is that the packet contains an uncorrectable bit error and therefore has to be discarded. A more likely reason, however, is that one of the nodes that has to handle the packet—for example, a switch that is forwarding it from one link to another—is so overloaded that it has no place to store the packet and therefore is forced to drop it. This is the problem of con- gestion mentioned in Section 1.2.3. Less commonly, the software running on one of the nodes that handles the packet makes a mistake. For exam- ple, it might incorrectly forward a packet out on the wrong link, so that the packet never finds its way to the ultimate destination. As we will see, one of the main difficulties in dealing with lost packets is distinguishing between a packet that is indeed lost and one that is merely late in arriving at the destination. The third class of failure is at the node and link level; that is, a physical link is cut, or the computer it is connected to crashes. This can be caused by software that crashes, a power failure, or a reckless backhoe operator. Failures due to misconfiguration of a network device are also common. While any of these failures can eventually be corrected, they can have a dramatic effect on the network for an extended period of time. However, they need not totally disable the network. In a packet-switched network, www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 23 #24 1.2 Requirements 23 for example, it is sometimes possible to route around a failed node or link. One of the difficulties in dealing with this third class of failure is distin- guishing between a failed computer and one that is merely slow or, in the case of a link, between one that has been cut and one that is very flaky and therefore introducing a high number of bit errors. The key idea to take away from this discussion is that defining useful chan- nels involves both understanding the applications’ requirements and recognizing the limitations of the underlying technology. The challenge is to fill in the gap between what the application expects and what the underlying technology can provide. This is sometimes called the semantic gap. 1.2.5 Manageability A final requirement, which seems to be neglected or left till last all too often,3 is that networks need to be managed. Managing a network includes making changes as the network grows to carry more traffic or reach more users, and troubleshooting the network when things go wrong or performance isn’t as desired. This requirement is partly related to the issue of scalability discussed above—as the Internet has scaled up to support billions of users and at least hundreds of millions of hosts, the challenges of keeping the whole thing running correctly and correctly configuring new devices as they are added have become increasingly problematic. Configuring a single router in a network is often a task for a trained expert; configuring thousands of routers and figuring out why a network of such a size is not behaving as expected can become a task beyond any single human. Furthermore, to make the operation of a network scalable and cost-effective, network operators typically require many management tasks to be automated or at least performed by relatively unskilled personnel. An important development in networking since we wrote the first edi- tion of this book is that networks in the home are now commonplace. This means that network management is no longer the province of experts but needs to be accomplished by consumers with little to no special training. This is sometimes stated as a requirement that networking devices should be “plug-and-play”—a goal that has proven quite elusive. We will discuss 3 As we have done in this section. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 24 #25 24 CHAPTER 1 Foundation some ways that this requirement has been addressed in part later on, but it is worth noting for now that improving the manageability of networks remains an important area of current research. 1.3 NETWORK ARCHITECTURE In case you hadn’t noticed, the previous section established a pretty sub- stantial set of requirements for network design—a computer network must provide general, cost-effective, fair, and robust connectivity among a large number of computers. As if this weren’t enough, networks do not remain fixed at any single point in time but must evolve to accommo- date changes in both the underlying technologies upon which they are based as well as changes in the demands placed on them by applica- tion programs. Furthermore, networks must be manageable by humans of varying levels of skill. Designing a network to meet these requirements is no small task. To help deal with this complexity, network designers have developed general blueprints—usually called network architectures—that guide the design and implementation of networks. This section defines more care- fully what we mean by a network architecture by introducing the central ideas that are common to all network architectures. It also introduces two of the most widely referenced architectures—the OSI (or 7-layer) architecture and the Internet architecture. 1.3.1 Layering and Protocols Abstraction—the hiding of details behind a well-defined interface—is the fundamental tool used by system designers to manage complexity. The idea of an abstraction is to define a model that can capture some important aspect of the system, encapsulate this model in an object that provides an interface that can be manipulated by other components of the system, and hide the details of how the object is implemented from the users of the object. The challenge is to identify abstractions that simultaneously provide a service that proves useful in a large number of situations and that can be efficiently implemented in the underlying sys- tem. This is exactly what we were doing when we introduced the idea of a channel in the previous section: we were providing an abstraction for applications that hides the complexity of the network from application writers. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 25 #26 1.3 Network architecture 25 Abstractions naturally lead to layering, especially in network systems. The general idea is that you start with the services offered by the underly- ing hardware and then add a sequence of layers, each providing a higher (more abstract) level of service. The services provided at the high lay- ers are implemented in terms of the services provided by the low layers. Drawing on the discussion of requirements given in the previous section, for example, we might imagine a simple network as having two lay- ers of abstraction sandwiched between the application program and the underlying hardware, as illustrated in Figure 1.8. The layer immediately above the hardware in this case might provide host-to-host connectivity, abstracting away the fact that there may be an arbitrarily complex net- work topology between any two hosts. The next layer up builds on the available host-to-host communication service and provides support for process-to-process channels, abstracting away the fact that the network occasionally loses messages, for example. Layering provides two nice features. First, it decomposes the problem of building a network into more manageable components. Rather than implementing a monolithic piece of software that does everything you will ever want, you can implement several layers, each of which solves one part of the problem. Second, it provides a more modular design. If you decide that you want to add some new service, you may only need to modify the functionality at one layer, reusing the functions provided at all the other layers. Thinking of a system as a linear sequence of layers is an oversimplifica- tion, however. Many times there are multiple abstractions provided at any given level of the system, each providing a different service to the higher layers but building on the same low-level abstractions. To see this, con- sider the two types of channels discussed in Section 1.2.4: One provides a Application programs Process-to-process channels Host-to-host connectivity Hardware n FIGURE 1.8 Example of a layered network system. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 26 #27 26 CHAPTER 1 Foundation Application programs Request/reply Message stream channel channel Host-to-host connectivity Hardware n FIGURE 1.9 Layered system with alternative abstractions available at a given layer. request/reply service and one supports a message stream service. These two channels might be alternative offerings at some level of a multilevel networking system, as illustrated in Figure 1.9. Using this discussion of layering as a foundation, we are now ready to discuss the architecture of a network more precisely. For starters, the abstract objects that make up the layers of a network system are called protocols. That is, a protocol provides a communication service that higher-level objects (such as application processes, or perhaps higher- level protocols) use to exchange messages. For example, we could imagine a network that supports a request/reply protocol and a message stream protocol, corresponding to the request/reply and message stream chan- nels discussed above. Each protocol defines two different interfaces. First, it defines a ser- vice interface to the other objects on the same computer that want to use its communication services. This service interface defines the operations that local objects can perform on the protocol. For example, a request/ reply protocol would support operations by which an application can send and receive messages. An implementation of the HTTP protocol could support an operation to fetch a page of hypertext from a remote server. An application such as a web browser would invoke such an oper- ation whenever the browser needs to obtain a new page (e.g., when the user clicks on a link in the currently displayed page). Second, a protocol defines a peer interface to its counterpart (peer) on another machine. This second interface defines the form and meaning of messages exchanged between protocol peers to implement the com- munication service. This would determine the way in which a request/ reply protocol on one machine communicates with its peer on another machine. In the case of HTTP, for example, the protocol specification www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 27 #28 1.3 Network architecture 27 Host 1 Host 2 High-level High-level object object Service Service interface interface Protocol Protocol Peer-to-peer interface n FIGURE 1.10 Service interfaces and peer interfaces. defines in detail how a GET command is formatted, what arguments can be used with the command, and how a web server should respond when it receives such a command. (We will look more closely at this particular protocol in To summarize, a protocol defines a communication service that it exports locally (the service interface), along with a set of rules governing the messages that the protocol exchanges with its peer(s) to implement this service (the peer interface). This situation is illustrated in Figure 1.10. Except at the hardware level, where peers directly communicate with each other over a link, peer-to-peer communication is indirect—each protocol communicates with its peer by passing messages to some lower- level protocol, which in turn delivers the message to its peer. In addition, there are potentially multiple protocols at any given level, each provid- ing a different communication service. We therefore represent the suite of protocols that make up a network system with a protocol graph. The nodes of the graph correspond to protocols, and the edges represent a depends on relation. For example, Figure 1.11 illustrates a protocol graph for the hypothetical layered system we have been discussing— protocols RRP (Request/Reply Protocol) and MSP (Message Stream Pro- tocol) implement two different types of process-to-process channels, and both depend on the Host-to-Host Protocol (HHP) which provides a host-to-host connectivity service. In this example, suppose that the file access program on host 1 wants to send a message to its peer on host 2 using the communication service www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 28 #29 28 CHAPTER 1 Foundation Host 1 Host 2 Digital Digital File Video File Video library library application application application application application application RRP MSP RRP MSP HHP HHP n FIGURE 1.11 Example of a protocol graph. offered by RRP. In this case, the file application asks RRP to send the mes- sage on its behalf. To communicate with its peer, RRP invokes the services of HHP, which in turn transmits the message to its peer on the other machine. Once the message has arrived at the instance of HHP on host 2, HHP passes the message up to RRP, which in turn delivers the message to the file application. In this particular case, the application is said to employ the services of the protocol stack RRP/HHP. Note that the term protocol is used in two different ways. Sometimes it refers to the abstract interfaces—that is, the operations defined by the ser- vice interface and the form and meaning of messages exchanged between peers, and sometimes it refers to the module that actually implements these two interfaces. To distinguish between the interfaces and the mod- ule that implements these interfaces, we generally refer to the former as a protocol specification. Specifications are generally expressed using a combination of prose, pseudocode, state transition diagrams, pictures of www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 29 #30 1.3 Network architecture 29 packet formats, and other abstract notations. It should be the case that a given protocol can be implemented in different ways by different pro- grammers, as long as each adheres to the specification. The challenge is ensuring that two different implementations of the same specification can successfully exchange messages. Two or more protocol modules that do accurately implement a protocol specification are said to interoperate with each other. We can imagine many different protocols and protocol graphs that satisfy the communication requirements of a collection of applications. Fortunately, there exist standardization bodies, such as the Internet Engi- neering Task Force (IETF) and the International Standards Organization (ISO), that establish policies for a particular protocol graph. We call the set of rules governing the form and content of a protocol graph a network architecture. Although beyond the scope of this book, standardization bodies have established well-defined procedures for introducing, validat- ing, and finally approving protocols in their respective architectures. We briefly describe the architectures defined by the IETF and ISO shortly, but first there are two additional things we need to explain about the mechanics of protocol layering. Encapsulation Consider what happens in Figure 1.11 when one of the application pro- grams sends a message to its peer by passing the message to RRP. From RRP’s perspective, the message it is given by the application is an unin- terpreted string of bytes. RRP does not care that these bytes represent an array of integers, an email message, a digital image, or whatever; it is simply charged with sending them to its peer. However, RRP must com- municate control information to its peer, instructing it how to handle the message when it is received. RRP does this by attaching a header to the message. Generally speaking, a header is a small data structure—from a few bytes to a few dozen bytes—that is used among peers to communi- cate with each other. As the name suggests, headers are usually attached to the front of a message. In some cases, however, this peer-to-peer con- trol information is sent at the end of the message, in which case it is called a trailer. The exact format for the header attached by RRP is defined by its protocol specification. The rest of the message—that is, the data being transmitted on behalf of the application—is called the message’s body or payload. We say that the application’s data is encapsulated in the new message created by RRP. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 30 #31 30 CHAPTER 1 Foundation This process of encapsulation is then repeated at each level of the pro- tocol graph; for example, HHP encapsulates RRP’s message by attaching a header of its own. If we now assume that HHP sends the message to its peer over some network, then when the message arrives at the des- tination host, it is processed in the opposite order: HHP first interprets the HHP header at the front of the message (i.e., takes whatever action is appropriate given the contents of the header) and passes the body of the message (but not the HHP header) up to RRP, which takes whatever action is indicated by the RRP header that its peer attached and passes the body of the message (but not the RRP header) up to the application program. The message passed up from RRP to the application on host 2 is exactly the same message as the application passed down to RRP on host 1; the application does not see any of the headers that have been attached to it to implement the lower-level communication services. This whole pro- cess is illustrated in Figure 1.12. Note that in this example, nodes in the Host 1 Host 2 Application Application program program Data Data RRP RRP RRP Data RRP Data HHP HHP HHP RRP Data n FIGURE 1.12 High-level messages are encapsulated inside of low-level messages. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 31 #32 1.3 Network architecture 31 network (e.g., switches and routers) may inspect the HHP header at the front of the message. Note that when we say a low-level protocol does not interpret the mes- sage it is given by some high-level protocol, we mean that it does not know how to extract any meaning from the data contained in the mes- sage. It is sometimes the case, however, that the low-level protocol applies some simple transformation to the data it is given, such as to compress or encrypt it. In this case, the protocol is transforming the entire body of the message, including both the original application’s data and all the headers attached to that data by higher-level protocols. Multiplexing and Demultiplexing Recall from Section 1.2.3 that a fundamental idea of packet switching is to multiplex multiple flows of data over a single physical link. This same idea applies up and down the protocol graph, not just to switching nodes. In Figure 1.11, for example, we can think of RRP as implementing a logical communication channel, with messages from two different applications multiplexed over this channel at the source host and then demultiplexed back to the appropriate application at the destination host. Practically speaking, this simply means that the header that RRP attaches to its messages contains an identifier that records the application to which the message belongs. We call this identifier RRP’s demultiplexing key, or demux key for short. At the source host, RRP includes the appro- priate demux key in its header. When the message is delivered to RRP on the destination host, it strips its header, examines the demux key, and demultiplexes the message to the correct application. RRP is not unique in its support for multiplexing; nearly every protocol implements this mechanism. For example, HHP has its own demux key to determine which messages to pass up to RRP and which to pass up to MSP. However, there is no uniform agreement among protocols—even those within a single network architecture—on exactly what constitutes a demux key. Some protocols use an 8-bit field (meaning they can support only 256 high-level protocols), and others use 16- or 32-bit fields. Also, some protocols have a single demultiplexing field in their header, while others have a pair of demultiplexing fields. In the former case, the same demux key is used on both sides of the communication, while in the latter case each side uses a different key to identify the high-level protocol (or application program) to which the message is to be delivered. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 32 #33 32 CHAPTER 1 Foundation The 7-Layer Model The ISO was one of the first organizations to formally define a common way to connect computers. Their architecture, called the Open Systems Interconnection (OSI) architecture and illustrated in Figure 1.13, defines a partitioning of network functionality into seven layers, where one or more protocols implement the functionality assigned to a given layer. In this sense, the schematic given in Figure 1.13 is not a protocol graph, per se, but rather a reference model for a protocol graph. It is often referred to as the 7-layer model. Starting at the bottom and working up, the physical layer handles the transmission of raw bits over a communications link. The data link layer then collects a stream of bits into a larger aggregate called a frame. Net- work adaptors, along with device drivers running in the node’s operating End host End host Application Application Presentation Presentation Session Session Transport Transport Network Network Network Network Data link Data link Data link Data link Physical Physical Physical Physical One or more nodes within the network n FIGURE 1.13 The OSI 7-layer model. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 33 #34 1.3 Network architecture 33 system, typically implement the data link level. This means that frames, not raw bits, are actually delivered to hosts. The network layer handles routing among nodes within a packet-switched network. At this layer, the unit of data exchanged among nodes is typically called a packet rather than a frame, although they are fundamentally the same thing. The lower three layers are implemented on all network nodes, including switches within the network and hosts connected to the exterior of the network. The transport layer then implements what we have up to this point been calling a process-to-process channel. Here, the unit of data exchanged is commonly called a message rather than a packet or a frame. The trans- port layer and higher layers typically run only on the end hosts and not on the intermediate switches or routers. There is less agreement about the definition of the top three layers, in part because they are not always all present, as we will see below. Skipping ahead to the top (seventh) layer, we find the application layer. Application layer protocols include things like the Hypertext Transfer Pro- tocol (HTTP), which is the basis of the World Wide Web and is what enables web browsers to request pages from web servers. Below that, the presentation layer is concerned with the format of data exchanged between peers—for example, whether an integer is 16, 32, or 64 bits long, whether the most significant byte is transmitted first or last, or how a video stream is formatted. Finally, the session layer provides a name space that is used to tie together the potentially different transport streams that are part of a single application. For example, it might manage an audio stream and a video stream that are being combined in a teleconferencing application. 1.3.2 Internet Architecture The Internet architecture, which is also sometimes called the TCP/IP architecture after its two main protocols, is depicted in Figure 1.14. An alternative representation is given in Figure 1.15. The Internet architec- ture evolved out of experiences with an earlier packet-switched network called the ARPANET. Both the Internet and the ARPANET were funded by the Advanced Research Projects Agency (ARPA), one of the research and development funding agencies of the U.S. Department of Defense. The Internet and ARPANET were around before the OSI architecture, and the experience gained from building them was a major influence on the OSI reference model. www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 34 #35 34 CHAPTER 1 Foundation FTP HTTP NV TFTP TCP UDP IP NET1 NET2 NETn n FIGURE 1.14 Internet protocol graph. Application TCP UDP IP Subnetwork n FIGURE 1.15 Alternative view of the Internet architecture. The subnetwork layer was historically referred to as the network layer and is now often referred to as the layer or simply layer 2. While the 7-layer OSI model can, with some imagination, be applied to the Internet, a 4-layer model is often used instead. At the lowest level is a wide variety of network protocols, denoted NET1 , NET2 , and so on. In practice, these protocols are implemented by a combination of hardware (e.g., a network adaptor) and software (e.g., a network device driver). For example, you might find Ethernet or wireless protocols (such as the 802.11 Wi-Fi standards) at this layer. (These protocols in turn may actually involve several sublayers, but the Internet architecture does not presume anything about them.) The second layer consists of a single protocol—the Internet Protocol (IP). This is the protocol that supports the interconnection of multiple networking technologies into a single, logical internetwork. The third layer contains two main protocols—the Trans- mission Control Protocol (TCP) and the User Datagram Protocol (UDP). TCP and UDP provide alternative logical channels to application pro- grams: TCP provides a reliable byte-stream channel, and UDP provides an unreliable datagram delivery channel (datagram may be thought of as a synonym for message). In the language of the Internet, TCP and UDP www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 35 #36 1.3 Network architecture 35 are sometimes called end-to-end protocols, although it is equally correct to refer to them as transport protocols. Running above the transport layer is a range of application protocols, such as HTTP, FTP, Telnet (remote login), and the Simple Mail Transfer Protocol (SMTP), that enable the interoperation of popular applications. To understand the difference between an application layer protocol and an application, think of all the different World Wide Web browsers that are or have been available (e.g., Firefox, Safari, Netscape, Mosaic, Internet Explorer). There is a similarly large number of different implementations of web servers. The reason that you can use any one of these application programs to access a particular site on the Web is that they all conform to the same application layer protocol: HTTP. Confusingly, the same term sometimes applies to both an application and the application layer pro- tocol that it uses (e.g., FTP is often used as the name of an application that implements the FTP protocol). Most people who work actively in the networking field are familiar with both the Internet architecture and the 7-layer OSI architecture, and there is general agreement on how the layers map between architectures. The Internet’s application layer is considered to be at layer 7, its transport layer is layer 4, the IP (internetworking or just network) layer is layer 3, and the link or subnet layer below IP is layer 2. The Internet architecture has three features that are worth highlight- ing. First, as best illustrated by Figure 1.15, the Internet architecture does not imply strict layering. The application is free to bypass the defined transport layers and to directly use IP or one of the underlying net- works. In fact, programmers are free to define new channel abstractions or applications that run on top of any of the existing protocols. Second, if you look closely at the protocol graph in Figure 1.14, you will notice an hourglass shape—wide at the top, narrow in the middle, and wide at the bottom. This shape actually reflects the central philosophy of the architecture. That is, IP serves as the focal point for the architecture— it defines a common method for exchanging packets among a wide collection of networks. Above IP there can be arbitrarily many transport protocols, each offering a different channel abstraction to application programs. Thus, the issue of delivering messages from host to host is com- pletely separated from the issue of providing a useful process-to-process communication service. Below IP, the architecture allows for arbitrarily www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 36 #37 36 CHAPTER 1 Foundation many different network technologies, ranging from Ethernet to wireless to single point-to-point links. A final attribute of the Internet architecture (or more accurately, of the IETF culture) is that in order for a new protocol to be officially included in the architecture, there must be both a protocol specification and at least one (and preferably two) representative implementations of the specifica- tion. The existence of working implementations is required for standards to be adopted by the IETF. This cultural assumption of the design com- munity helps to ensure that the architecture’s protocols can be efficiently implemented. Perhaps the value the Internet culture places on working software is best exemplified by a quote on T-shirts commonly worn at IETF meetings: We reject kings, presidents, and voting. We believe in rough consensus and running code. (David Clark) Of these three attributes of the Internet architecture, the hourglass design phi- losophy is important enough to bear repeating. The hourglass’s narrow waist represents a minimal and carefully chosen set of global capabilities that allows both higher-level applications and lower-level communication technologies to coexist, share capabilities, and evolve rapidly. The narrow-waisted model is criti- cal to the Internet’s ability to adapt rapidly to new user demands and changing technologies. 1.4 IMPLEMENTING NETWORK SOFTWARE Network architectures and protocol specifications are essential things, but a good blueprint is not enough to explain the phenomenal success of the Internet: The number of computers connected to the Internet has grown exponentially for almost 3 decades (although precise numbers are now hard to come by). The number of users of the Internet was estimated to be around 1.8 billion in 2009—an impressive percentage of the world’s population. What explains the success of the Internet? There are certainly many contributing factors (including a good architecture), but one thing that has made the Internet such a runaway success is the fact that so much of its functionality is provided by software running in general-purpose com- puters. The significance of this is that new functionality can be added readily with “just a small matter of programming.” As a result, new www.EBooksWorld.ir  PETERSON-AND-DAVIE 07-ch01-000-069-9780123850591 2011/11/1 9:29 Page 37 #38 1.4 Implementing network software 37 applications and services—electronic commerce, videoconferencing, and IP telephony, to name a few—have been showing up at an incredible pace. A related fact