E D I T I O N 4

COMPUTERNETWORKS

A S Y S T E M S A P P R O A C H

The Morgan Kaufmann Series in NetworkingSeries Editor, David Clark, M.I.T.

Computer Networks: A Systems Approach, 4eLarry L. Peterson and Bruce S. Davie

Network Routing: Algorithms, Protocols, andArchitectures

Deepankar Medhi and Karthikeyan RamaswamiDeploying IP and MPLS QoS for Multiservice Networks:Theory and Practice

John Evans and Clarence FilsfilsTraffic Engineering and QoS Optimization of IntegratedVoice & Data Networks

Gerald R. AshIPv6 Core Protocols Implementation

Qing Li, Tatuya Jinmei, and Keiichi ShimaSmart Phone and Next-Generation Mobile Computing

Pei Zheng and Lionel NiGMPLS: Architecture and Applications

Adrian Farrel and Igor BryskinNetwork Security: A Practical Approach

Jan L. HarringtonContent Networking: Architecture, Protocols, and Practice

Markus Hofmann and Leland R. BeaumontNetwork Algorithmics: An Interdisciplinary Approach toDesigning Fast Networked Devices

George VargheseNetwork Recovery: Protection and Restoration of Optical,SONET-SDH, IP, and MPLS

Jean Philippe Vasseur, Mario Pickavet, and PietDemeesterRouting, Flow, and Capacity Design in Communicationand Computer Networks

Michał Pióro and Deepankar MedhiWireless Sensor Networks: An Information ProcessingApproach

Feng Zhao and Leonidas GuibasCommunication Networking: An Analytical Approach

Anurag Kumar, D. Manjunath, and Joy KuriThe Internet and Its Protocols: A Comparative Approach

Adrian FarrelModern Cable Television Technology: Video, Voice, andData Communications, 2e

Walter Ciciora, James Farmer, David Large, andMichael AdamsBluetooth Application Programming with the Java APIs

C Bala Kumar, Paul J. Kline, and Timothy J.Thompson

Policy-Based Network Management: Solutions for theNext Generation

John StrassnerNetwork Architecture, Analysis, and Design, 2e

James D. McCabeMPLS Network Management: MIBs, Tools, andTechniques

Thomas D. NadeauDeveloping IP-Based Services: Solutions for ServiceProviders and Vendors

Monique Morrow and Kateel VijayanandaTelecommunications Law in the Internet Age

Sharon K. BlackOptical Networks: A Practical Perspective, 2e

Rajiv Ramaswami and Kumar N. SivarajanInternet QoS: Architectures and Mechanisms

Zheng WangTCP/IP Sockets in Java: Practical Guide for Programmers

Michael J. Donahoo and Kenneth L. CalvertTCP/IP Sockets in C: Practical Guide for Programmers

Kenneth L. Calvert and Michael J. DonahooMulticast Communication: Protocols, Programming, andApplications

Ralph Wittmann and Martina ZitterbartMPLS: Technology and Applications

Bruce Davie and Yakov RekhterHigh-Performance Communication Networks, 2e

Jean Walrand and Pravin VaraiyaInternetworking Multimedia

Jon Crowcroft, Mark Handley, and Ian WakemanUnderstanding Networked Applications: A First Course

David G. MesserschmittIntegrated Management of Networked Systems: Concepts,Architectures, and Their OperationalApplication

Heinz-Gerd Hegering, Sebastian Abeck, andBernhard NeumairVirtual Private Networks: Making the Right Connection

Dennis FowlerNetworked Applications: A Guide to the New ComputingInfrastructure

David G. MesserschmittWide Area Network Design: Concepts and Tools forOptimization

Robert S. Cahn

For further information on these books and for a list of forthcoming titles, please visit our Web site athttp://www.mkp.com.

E D I T I O N 4

COMPUTERNETWORKS

A S Y S T E M S A P P R O A C H

Larry L. Peterson & Bruce S. Davie

AMSTERDAM • BOSTON • HEIDELBERG • LONDONNEW YORK • OXFORD • PARIS • SAN DIEGO

SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYOMorgan Kaufmann Publishers is an imprint of Elsevier

Acquisitions Editor Rick AdamsPublishing Services Manager George MorrisonProduction Editor Dawnmarie SimpsonAssociate Acquisitions Editor Rachel RoumeliotisDesign Direction Louis ForgioneComposition VTEXCopyeditor Multiscience Press, Inc.Proofreader Jodie AllenIndexer Multiscience Press, Inc.Interior printer Courier WestfordCover printer Phoenix Color, Inc.

Morgan Kaufmann Publishers is an imprint of Elsevier.500 Sansome Street, Suite 400, San Francisco, CA 94111

This book is printed on acid-free paper.

© 2007, Elsevier, Inc. All rights reserved.

Designations used by companies to distinguish their products are often claimed as trademarks or registered trademarks. In allinstances in which Morgan Kaufmann Publishers is aware of a claim, the product names appear in initial capital or all capitalletters. Readers, however, should contact the appropriate companies for more complete information regarding trademarks andregistration.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, mechanical, photocopying, scanning, or otherwise—without prior written permission of the publisher.

Permissions may be sought directly from Elsevier’s Science & Technology Rights Department in Oxford, UK: phone: (+44)1865 843830, fax: (+44) 1865 853333, E-mail: permissions@elsevier.com. You may also complete your request online via theElsevier homepage (http://elsevier.com), by selecting “Support & Contact” then “Copyright and Permission” and then “ObtainingPermissions.”

ISBN 13: 978-0-12-370548-8 (Case bound)ISBN 10: 0-12-370548-7 (Case bound)

ISBN 13: 978-0-12-374013-7 (Paperback)ISBN 10: 0-12-374013-4 (Paperback)

Library of Congress Cataloging-in-Publication DataPeterson, Larry L.

Computer networks : a systems approach / Larry L. Peterson & Bruce S.Davi – 4th ed.

p. cm.Includes bibliographical references and index.ISBN-13: 978-0-12-370548-8 (hardcover : alk. paper)ISBN-10: 0-12-370548-7 (hardcover : alk. paper)ISBN-13: 978-0-12-374013-7 (pbk. : alk. paper)ISBN-10: 0-12-374013-4 (pbk. : alk. paper) 1. Computer networks. I.

Davie, Bruce S. II. Title.TK5105.5.P479 2007004.6’5–dc22

2006102454

For information on all Morgan Kaufmann publications, visit ourWeb site at www.mkp.com or www.books.elsevier.com

Printed in the United States of America.06 07 08 09 10 5 4 3 2 1

To Lee Peterson and Robert Davie

F O R E W O R D

David D. ClarkMassachusetts Institute of Technology

t is now ten years since this classic book first appeared. Looking back, it is amazingIwhat has happened in that time. We have seen the transformation of the Web froma small experiment to a World Wide phenomenon. We have seen the emergenceof voice over IP and peer-to-peer content sharing. We have seen technology speed upa hundred-fold, the emergence of broadband to the home, and the rise of botnets andother horrid security problems. Many things have changed, technology has come andgone, and (perhaps equally amazing) much of the basics of the Internet are still there.

This book, too, has changed much in ten years, with four editions to keep up. Butthe basic value of the book remains the same as the first edition. This book gives you thefacts you need, and puts those facts into the larger context so that the knowledge yougain will be of value even as the details change. Reading this book informs you abouttoday and prepares you for tomorrow. One new feature is a set of sidebars that illustratethe context of ideas being presented in the text—the why of the ideas. Why did an ideafail? Why did it succeed?

What has changed in the book? Some technologies have faded from sight, and getless attention in this edition. We bid a fond farewell to FDDI and ATM LANs. Sometechnologies have mutated and emerged in new forms. Remote Procedure Call is nolonger a LAN-based low-level invocation mechanism, but the foundation of Internet-wide Web Services. We welcome gigabit Ethernet, an updated and expanded section onwireless, and more on router implementation. The material on TCP is up to date, withdiscussion of new acknowledgment schemes and extensions for high speed.

With the increasing concern with security, there is a completely revised chapterwith a new emphasis on a systems approach to security, and a discussion of threats andhow to counter them. And at the end, there is a chapter that helps you “put it all to-gether,” using case studies at the application layer (VOIP, multimedia, and peer to peer)to show how all the concepts from the previous chapters combine to provide the systemthat supports these applications.

viii Foreword

The evolution of networks is not going to slow down. Soon we will be talkingabout the impact of television over IP, the collision of the Internet and sensor networks,and lots of other very new and exciting ideas. But relax—if you read this book today youwill have the insights you need for tomorrow.

F O R E W O R D T O T H E F I R S T E D I T I O N

David ClarkMassachusetts Institute of Technology

he term spaghetti code is universally understood as an insult. All good computerTscientists worship the god of modularity, since modularity brings many benefits,including the all-powerful benefit of not having to understand all parts of aproblem at the same time in order to solve it. Modularity thus plays a role in presentingideas in a book, as well as in writing code. If a book’s material is organized effectively—modularly—the reader can start at the beginning and actually make it to the end.

The field of network protocols is perhaps unique in that the “proper” modularityhas been handed down to us in the form of an international standard: the seven-layerreference model of network protocols from the ISO. This model, which reflects a layeredapproach to modularity, is almost universally used as a starting point for discussions ofprotocol organization, whether the design in question conforms to the model or deviatesfrom it.

It seems obvious to organize a networking book around this layered model. How-ever, there is a peril to doing so, because the OSI model is not really successful at organiz-ing the core concepts of networking. Such basic requirements as reliability, flow control,or security can be addressed at most, if not all, of the OSI layers. This fact has led togreat confusion in trying to understand the reference model. At times it even requires asuspension of disbelief. Indeed, a book organized strictly according to a layered modelhas some of the attributes of spaghetti code.

Which brings us to this book. Peterson and Davie follow the traditional layeredmodel, but they do not pretend that this model actually helps in the understandingof the big issues in networking. Instead, the authors organize discussion of fundamen-tal concepts in a way that is independent of layering. Thus, after reading the book,readers will understand flow control, congestion control, reliability enhancement, datarepresentation, and synchronization, and will separately understand the implications ofaddressing these issues in one or another of the traditional layers.

This is a timely book. It looks at the important protocols in use today—especiallythe Internet protocols. Peterson and Davie have a long involvement in and much ex-

x Foreword to the First Edition

perience with the Internet. Thus their book reflects not just the theoretical issues inprotocol design, but the real factors that matter in practice. The book looks at some ofthe protocols that are just emerging now, so the reader can be assured of an up-to-dateperspective. But most importantly, the discussion of basic issues is presented in a waythat derives from the fundamental nature of the problem, not the constraints of the lay-ered reference model or the details of today’s protocols. In this regard, what this bookpresents is both timely and timeless. The combination of real-world relevance, currentexamples, and careful explanation of fundamentals makes this book unique.

P R E F A C E

hen the first edition of this book was published in 1996, it was a novelty toWbe able to order merchandise on the Internet, and a company that advertisedits domain name was considered cutting edge. Today, Internet commerceis a fact of life, and “.com” stocks have gone through an entire boom and bust cycle.A host of new technologies ranging from optical switches to wireless networks are nowbecoming mainstream. It seems the only predictable thing about the Internet is constantchange.

Despite these changes the question we asked in the first edition is just as validtoday: What are the underlying concepts and technologies that make the Internet work?The answer is that much of the TCP/IP architecture continues to function just as wasenvisioned by its creators more than 30 years ago. This isn’t to say that the Internetarchitecture is uninteresting; quite the contrary. Understanding the design principles thatunderly an architecture that has not only survived but fostered the kind of growth andchange that the Internet has seen over the past three decades is precisely the right placeto start. Like the previous editions, the third edition makes the “why” of the Internetarchitecture its cornerstone.

AudienceOur intent is that the book should serve as the text for a comprehensive networkingclass, at either the graduate or upper-division undergraduate level. We also believe thatthe book’s focus on core concepts should be appealing to industry professionals who areretraining for network-related assignments, as well as current network practitioners whowant to understand the “whys” behind the protocols they work with every day and to seethe big picture of networking.

It is our experience that both students and professionals learning about networksfor the first time often have the impression that network protocols are some sort of edicthanded down from on high, and that their job is to learn as many TLAs (three-letteracronyms) as possible. In fact, protocols are the building blocks of a complex systemdeveloped through the application of engineering design principles. Moreover, they areconstantly being refined, extended, and replaced based on real-world experience. With

xii Preface

this in mind, our goal with this book is to do more than survey the protocols in usetoday. Instead, we explain the underlying principles of sound network design. We feelthat this grasp of underlying principles is the best tool for handling the rate of change inthe networking field.

Changes in the Fourth Edition

Even though our focus is on the underlying principles of networking, we illustrate theseprinciples using examples from today’s working Internet. Therefore, we added a signifi-cant amount of new material to track many of the important recent advances in network-ing. We also deleted, reorganized, and changed the focus of existing material to reflectchanges that have taken place over the past decade.

Perhaps the most significant change we have noticed since writing the first editionis that almost every reader now has some familiarity with networked applications such asthe World Wide Web and email. For this reason, we have increased the focus on applica-tions, starting in the first chapter. We use applications as the motivation for the study ofnetworking, and to derive a set of requirements that a useful network must meet if it isto support both current and future applications on a global scale. However, we retain theproblem-solving approach of previous editions that starts with the problem of intercon-necting hosts and works its way up the layers to conclude with a detailed examinationof application layer issues. We believe it is important to make the topics covered in thebook relevant by starting with applications and their needs. At the same time, we feelthat higher-layer issues, such as application layer and transport layer protocols, are bestunderstood after the basic problems of connecting hosts and switching packets have beenexplained.

As we did in the second and third editions, we have added or increased coverage ofimportant new topics, and brought other topics up to date. Major new or substantiallyupdated topics in this edition are:

■ Comprehensively revised and updated coverage of security, with a focus onbuilding secure systems, not just on cryptographic algorithms;

■ Expanded and updated coverage of XML (extensible markup language);

■ An updated section on overlay networks, including “peer-to-peer” networkingand “content distribution networks”;

■ A new section on web services, including the SOAP and REST (Representa-tional State Transfer) architectures;

Preface xiii

■ Updated material on wireless technology, including the 802.11 (WiFi) and802.16 (WiMAX) standards as well as cellular wireless technologies includingthe 3G (third generation) standards;

■ Expanded coverage of interdomain routing;

■ Expanded coverage on protocols and quality of service for multimedia applica-tions such as voiceover IP (VOIP) and video streaming;

■ Updated coverage of congestion control mechanisms, particularly for highbandwidth-delay product networks.

In addition, we have added a new feature to this edition: “Where are they now?”sidebars. These short discussions focus on the success and failure of protocols in the realworld. Sometimes they describe a protocol that most people have written off but whichis actually enjoying unheralded success; other times they trace the fate of a protocolthat failed to thrive over the long run. The goal of these sidebars is to make the materialrelevant by showing how technologies have fared in the competitive world of networking.

ApproachFor an area that’s as dynamic and changing as computer networks, the most importantthing a textbook can offer is perspective—to distinguish between what’s important andwhat’s not, and between what’s lasting and what’s superficial. Based on our experienceover the past 20-plus years doing research that has led to new networking technology,teaching undergraduate and graduate students about the latest trends in networking, anddelivering advanced networking products to market, we have developed a perspective—which we call the systems approach—that forms the soul of this book. The systems ap-proach has several implications:

■ Rather than accept existing artifacts as gospel, we start first with principles andwalk you through the thought process that led to today’s networks. This allowsus to explain why networks look like they do. It is our experience that once youunderstand the underlying concepts, any new protocol that you are confrontedwith will be relatively easy to digest.

■ Although the material is loosely organized around the traditional network lay-ers, starting at the bottom and moving up the protocol stack, we do not adopta rigidly layerist approach. Many topics—congestion control and security aregood examples—have implications up and down the hierarchy, and so we dis-cuss them outside the traditional layered model. In short, we believe layeringmakes a good servant but a poor master; it’s more often useful to take an end-to-end perspective.

xiv Preface

■ Rather than explain how protocols work in the abstract, we use the most im-portant protocols in use today—many of them from the TCP/IP Internet—toillustrate how networks work in practice. This allows us to include real-worldexperiences in the discussion.

■ Although at the lowest levels networks are constructed from commodity hard-ware that can be bought from computer vendors and communication servicesthat can be leased from the phone company, it is the software that allows net-works to provide new services and adapt quickly to changing circumstances. It isfor this reason that we emphasize how network software is implemented, ratherthan stopping with a description of the abstract algorithms involved. We alsoinclude code segments taken from a working protocol stack to illustrate howyou might implement certain protocols and algorithms.

■ Networks are constructed from many building-block pieces, and while it is nec-essary to be able to abstract away uninteresting elements when solving a particu-lar problem, it is essential to understand how all the pieces fit together to form afunctioning network. We therefore spend considerable time explaining the over-all end-to-end behavior of networks, not just the individual components, so thatit is possible to understand how a complete network operates, all the way fromthe application to the hardware.

■ The systems approach implies doing experimental performance studies, andthen using the data you gather both to quantitatively analyze various designoptions and to guide you in optimizing the implementation. This emphasis onempirical analysis pervades the book.

■ Networks are like other computer systems—for example, operating systems,processor architectures, distributed and parallel systems, and so on. They are alllarge and complex. To help manage this complexity, system builders often drawon a collection of design principles. We highlight these design principles as theyare introduced throughout the book, illustrated, of course, with examples fromcomputer networks.

Pedagogy and Features

The fourth edition retains several features from prior editions, and adds one more, thatwe encourage you to take advantage of:

■ Problem statements. At the start of each chapter, we describe a problem thatidentifies the next set of issues that must be addressed in the design of a network.This statement introduces and motivates the issues to be explored in the chapter.

Preface xv

■ Shaded sidebars. Throughout the text, shaded sidebars elaborate on the topic be-ing discussed or introduce a related advanced topic. In many cases, these sidebarsrelate real-world anecdotes about networking.

■ “Where are they now?” sidebars. These new elements trace the success and failureof protocols in real-world deployment.

■ Highlighted paragraphs. These paragraphs summarize an important nugget ofinformation that we want you to take away from the discussion, such as a widelyapplicable system design principle.

■ Real protocols. Even though the book’s focus is on core concepts rather than ex-isting protocol specifications, real protocols are used to illustrate most of theimportant ideas. As a result, the book can be used as a source of reference formany protocols. To help you find the descriptions of the protocols, each ap-plicable section heading parenthetically identifies the protocols described in thatsection. For example, Section 5.2, which describes the principles of reliable end-to-end protocols, provides a detailed description of TCP, the canonical exampleof such a protocol.

■ Open issues. We conclude the main body of each chapter with an importantissue that is currently being debated in the research community, the commercialworld, or society as a whole. We have found that discussing these issues helps tomake the subject of networking more relevant and exciting.

■ Recommended reading. These highly selective lists appear at the end of each chap-ter. Each list generally contains the seminal papers on the topics just discussed.We strongly recommend that advanced readers (e.g., graduate students) studythe papers in this reading list to supplement the material covered in the chapter.

Road Map and Course UseThe book is organized as follows:

■ Chapter 1 introduces the set of core ideas that are used throughout the rest of thetext. Motivated by widespread applications, it discusses what goes into a networkarchitecture, provides an introduction to protocol implementation issues, anddefines the quantitative performance metrics that often drive network design.

■ Chapter 2 surveys a wide range of low-level network technologies, ranging fromEthernet to token ring to wireless. It also describes many of the issues thatall data link protocols must address, including encoding, framing, and errordetection.

xvi Preface

■ Chapter 3 introduces the basic models of switched networks (datagrams versusvirtual circuits) and describes two prevalent switching technologies—switchedEthernet and ATM—in some detail. It also discusses the design of hardware-based switches.

■ Chapter 4 introduces internetworking and describes the key elements of theInternet Protocol (IP). A central question addressed in this chapter is how net-works that scale to the size of the Internet are able to route packets. Unicast,multicast, and interdomain routing are covered.

■ Chapter 5 moves up to the transport level, describing both the Internet’s Trans-mission Control Protocol (TCP) and Remote Procedure Call (RPC) used tobuild client-server applications in detail. The Real-time Transport Protocol(RTP), which supports multimedia applications, is also described.

■ Chapter 6 discusses congestion control and resource allocation. The issues inthis chapter cut across both the network level (Chapters 3 and 4) and the trans-port level (Chapter 5). Of particular note, this chapter describes how congestioncontrol works in TCP, and it introduces the mechanisms used to provide qualityof service in IP.

■ Chapter 7 considers the data sent through a network. This includes both theproblems of presentation formatting and data compression. XML is coveredhere, and the compression section includes explanations of how MPEG videocompression and MP3 audio compression work.

■ Chapter 8 discusses network security, beginning with an overview of crypto-graphic tools, the problems of key distribution, and a discussion of severalauthentication techniques using both public and private keys. The main fo-cus of this chapter is the building of secure systems, using examples includingPretty Good Privacy (PGP), Secure Shell (SSH), and the IP Security architecture(IPSEC). Firewalls are also covered here.

■ Chapter 9 describes a representative sample of network applications and theprotocols they use, including traditional applications like email and the Web,multimedia applications such as IP telephony and video streaming, and overlaynetworks like peer-to-peer file sharing and content distribution networks. TheWeb Services architectures for developing new application protocols are alsopresented here.

For an undergraduate course, extra class time will most likely be needed to helpstudents digest the introductory material in the first chapter, probably at the expense

Preface xvii

of the more advanced topics covered in Chapters 6 through 8. Chapter 9 then returnsto the popular topic of network applications. In contrast, the instructor for a graduatecourse should be able to cover the first chapter in only a lecture or two—with studentsstudying the material more carefully on their own—thereby freeing up additional classtime to cover the last four chapters in depth. Both graduate and undergraduate classeswill want to cover the core material contained in the middle four chapters (Chapters2–5), although an undergraduate class might choose to skim the more advanced sections(e.g., Sections 2.2, 4.4, and 4.5).

For those of you using the book in self-study, we believe that the topics we haveselected cover the core of computer networking, and so we recommend that the bookbe read sequentially, from front to back. In addition, we have included a liberal supplyof references to help you locate supplementary material that is relevant to your specificareas of interest, and we have included solutions to select exercises.

The book takes a unique approach to the topic of congestion control by pulling alltopics related to congestion control and resource allocation together in a single place—Chapter 6. We do this because the problem of congestion control cannot be solved atany one level, and we want you to consider the various design options at the same time.(This is consistent with our view that strict layering often obscures important designtrade-offs.) A more traditional treatment of congestion control is possible, however, bystudying Section 6.2 in the context of Chapter 3 and Section 6.4 in the context ofChapter 5.

Exercises

Significant effort has gone into improving the exercises with each new edition. In thesecond edition we greatly increased the number of problems and, based on class testing,dramatically improved their quality. In the third edition we made two other importantchanges, which we retained here:

■ For those exercises that we felt are particularly challenging or require specialknowledge not provided in the book (e.g., probability expertise), we have addedan icon ★ to indicate the extra level of difficulty.

■ In each chapter we added some extra representative exercises for which workedsolutions are provided at the back of the book. These exercises, marked ✓, areintended to provide some help in tackling the other exercises in the book.

In this edition we have added new exercises to reflect the updated content. Thecurrent set of exercises are of several different styles:

xviii Preface

■ Analytical exercises that ask the student to do simple algebraic calculations thatdemonstrate their understanding of fundamental relationships.

■ Design questions that ask the student to propose and evaluate protocols forvarious circumstances.

■ Hands-on questions that ask the student to write a few lines of code to test anidea or to experiment with an existing network utility.

■ Library research questions that ask the student to learn more about a particulartopic.

Also, as described in more detail below, socket-based programming assignments, aswell as simulation labs, are available online.

Supplemental Materials and Online Resources

To assist instructors, we have prepared an instructor’s manual that contains solutions toselected exercises. The manual is available from the publisher.

Additional support materials, including lecture slides, figures from the text, socket-based programming assignments, and sample exams and programming assignments areavailable through the Morgan Kaufmann website at http://www.mkp.com/pd4e.We suggest that you visit the page for this book every few weeks, as we will be addingsupport materials and establishing links to networking-related sites on a regular basis.

And finally, as with the third edition, a set of laboratory experiments supplementthe book. These labs, developed by Professor Emad Aboelela from the University ofMassachusetts Dartmouth, use simulation to explore the behavior, scalability, and per-formance of protocols covered in the book. Sections that discuss material covered by thelaboratory exercises are marked with the icon shown in the margin. The simulations usethe OPNET simulation toolset, which is available for free to any one using ComputerNetworks in their course.

Acknowledgments

This book would not have been possible without the help of many people. We wouldlike to thank them for their efforts in improving the end result. Before we do so, however,we should mention that we have done our best to correct the mistakes that the reviewershave pointed out and to accurately describe the protocols and mechanisms that ourcolleagues have explained to us. We alone are responsible for any remaining errors. Ifyou should find any of these, please send email to our publisher, Morgan Kaufmann,at netbugsPD4e@elsevier.com, and we will endeavor to correct them in futureprintings of this book.

Preface xix

First, we would like to thank the many people who reviewed drafts of all or partsof the manuscript. In addition to those who reviewed prior editions, we wish to thankDavid Maltz, Bobby Bhattacharjee, and Sarvesh Kaulkarni for their thorough reviews.Thanks also to Ric Pruss and Mike Takefman for their reviews of various sections. Wealso wish to thank all those who provided feedback and input to help us decide what todo in this edition: Tim Batten, Julio Pontes, and Kevin Mills.

Several members of the Network Systems Group at Princeton contributed ideas,examples, corrections, data, and code to earlier editions of this book. In particular, wewould like to thank Andy Bavier, Tammo Spalink, Mike Wawrzoniak, Zuki Gottlieb,George Tzanetakis, and Chad Mynhier. KyoungSoo Park provided valuable help on theexercise solutions, instructor’s manual, and lecture slides. As before, we want to thankthe Defense Advanced Research Projects Agency, the National Science Foundation, IntelCorporation, and Cisco Systems, Inc. for supporting our networking research over thepast several years. Thanks also to Cisco for providing the time for one of us to work onthe book.

This edition could not have been produced without the substantial contributionsof Mark Abbott, who crafted a great deal of new material for this book in return for notmuch more than these few lines of thanks.

Finally, we would like to thank our series editor, David Clark, as well as all thepeople at Morgan Kaufmann who helped shepherd us through the book-writing process.A special thanks is due to our original sponsoring editor, Jennifer Young; our editor forthis edition, Rick Adams; our developmental editor, Rachel Roumeliotis; and to KarynJohnson, assistant editor on prior editions. The whole crew at MKP has been a delightto work with over the lifetime of this book.

C O N T E N T S

Foreword vii

Foreword to the First Edition ix

Preface xi

1 FoundationProblem: Building a Network 2

1.1 Applications 4

1.2 Requirements 6

1.2.1 Connectivity 7

1.2.2 Cost-Effective Resource Sharing 11

1.2.3 Support for Common Services 14

1.3 Network Architecture 19

1.3.1 Layering and Protocols 20

1.3.2 OSI Architecture 26

1.3.3 Internet Architecture 28

1.4 Implementing Network Software 30

1.4.1 Application Programming Interface (Sockets) 31

1.4.2 Example Application 33

1.4.3 Protocol Implementation Issues 37

1.5 Performance 40

1.5.1 Bandwidth and Latency 40

1.5.2 Delay × Bandwidth Product 441.5.3 High-Speed Networks 46

1.5.4 Application Performance Needs 48

1.6 Summary 50

Open Issue: Ubiquitous Networking 51

Further Reading 52

Exercises 55

xxii Contents

2 Direct Link NetworksProblem: Physically Connecting Hosts 64

2.1 Hardware Building Blocks 66

2.1.1 Nodes 66

2.1.2 Links 71

2.2 Encoding (NRZ, NRZI, Manchester, 4B/5B) 79

2.3 Framing 84

2.3.1 Byte-Oriented Protocols (PPP) 84

2.3.2 Bit-Oriented Protocols (HDLC) 87

2.3.3 Clock-Based Framing (SONET) 89

2.4 Error Detection 92

2.4.1 Two-Dimensional Parity 93

2.4.2 Internet Checksum Algorithm 94

2.4.3 Cyclic Redundancy Check 96

2.5 Reliable Transmission 101

2.5.1 Stop-and-Wait 102

2.5.2 Sliding Window 105

2.5.3 Concurrent Logical Channels 115

2.6 Ethernet (802.3) 116

2.6.1 Physical Properties 116

2.6.2 Access Protocol 119

2.6.3 Experience with Ethernet 123

2.7 Rings (802.5, FDDI, RPR) 124

2.7.1 Token Ring Media Access Control 127

2.7.2 Token Ring Maintenance 129

2.7.3 FDDI 130

2.7.4 Resilient Packet Ring (802.17) 131

2.8 Wireless 133

2.8.1 Bluetooth (802.15.1) 136

2.8.2 Wi-Fi (802.11) 137

2.8.3 WiMAX (802.16) 143

2.8.4 Cell Phone Technologies 145

2.9 Summary 147

Open Issue: Sensor Networks 148

Further Reading 149

Exercises 151

3 Packet SwitchingProblem: Not All Networks Are Directly Connected 166

3.1 Switching and Forwarding 168

Contents xxiii

3.1.1 Datagrams 170

3.1.2 Virtual Circuit Switching 172

3.1.3 Source Routing 179

3.2 Bridges and LAN Switches 183

3.2.1 Learning Bridges 184

3.2.2 Spanning Tree Algorithm 187

3.2.3 Broadcast and Multicast 192

3.2.4 Limitations of Bridges 193

3.3 Cell Switching (ATM) 195

3.3.1 Cells 195

3.3.2 Segmentation and Reassembly 200

3.3.3 Virtual Paths 205

3.3.4 Physical Layers for ATM 206

3.4 Implementation and Performance 208

3.4.1 Ports 210

3.4.2 Fabrics 214

3.5 Summary 218

Open Issue: The Future of Switching 219

Further Reading 219

Exercises 221

4 InternetworkingProblem: There Is More Than One Network 232

4.1 Simple Internetworking (IP) 234

4.1.1 What Is an Internetwork? 234

4.1.2 Service Model 236

4.1.3 Global Addresses 248

4.1.4 Datagram Forwarding in IP 250

4.1.5 Address Translation (ARP) 254

4.1.6 Host Configuration (DHCP) 259

4.1.7 Error Reporting (ICMP) 262

4.1.8 Virtual Networks and Tunnels 262

4.2 Routing 266

4.2.1 Network as a Graph 268

4.2.2 Distance Vector (RIP) 269

4.2.3 Link State (OSPF) 277

4.2.4 Metrics 286

4.2.5 Routing for Mobile Hosts 289

4.2.6 Router Implementation 294

4.3 Global Internet 297

xxiv Contents

4.3.1 Subnetting 299

4.3.2 Classless Routing (CIDR) 303

4.3.3 Interdomain Routing (BGP) 306

4.3.4 Routing Areas 316

4.3.5 IP Version 6 (IPv6) 318

4.4 Multicast 329

4.4.1 Multicast Addresses 331

4.4.2 Multicast Routing (DVMRP, PIM, MSDP) 332

4.5 Multiprotocol Label Switching 343

4.5.1 Destination-Based Forwarding 344

4.5.2 Explicit Routing 350

4.5.3 Virtual Private Networks and Tunnels 352

4.6 Summary 356

Open Issue: Deployment of IPv6 358

Further Reading 359

Exercises 360

5 End-to-End ProtocolsProblem: Getting Processes to Communicate 380

5.1 Simple Demultiplexer (UDP) 382

5.2 Reliable Byte Stream (TCP) 384

5.2.1 End-to-End Issues 385

5.2.2 Segment Format 387

5.2.3 Connection Establishment and Termination 390

5.2.4 Sliding Window Revisited 394

5.2.5 Triggering Transmission 400

5.2.6 Adaptive Retransmission 403

5.2.7 Record Boundaries 407

5.2.8 TCP Extensions 408

5.2.9 Alternative Design Choices 410

5.3 Remote Procedure Call 411

5.3.1 RPC Fundamentals 412

5.3.2 RPC Implementations (SunRPC, DCE) 419

5.4 Transport for Real-Time Applications (RTP) 426

5.4.1 Requirements 428

5.4.2 RTP Details 429

5.4.3 Control Protocol 433

5.5 Performance 437

5.6 Summary 440

Open Issue: Application-Specific Protocols 441

Contents xxv

Further Reading 442

Exercises 443

6 Congestion Control and Resource AllocationProblem: Allocating Resources 456

6.1 Issues in Resource Allocation 458

6.1.1 Network Model 458

6.1.2 Taxonomy 462

6.1.3 Evaluation Criteria 464

6.2 Queuing Disciplines 467

6.2.1 FIFO 468

6.2.2 Fair Queuing 469

6.3 TCP Congestion Control 474

6.3.1 Additive Increase/Multiplicative Decrease 474

6.3.2 Slow Start 477

6.3.3 Fast Retransmit and Fast Recovery 483

6.4 Congestion-Avoidance Mechanisms 486

6.4.1 DECbit 486

6.4.2 Random Early Detection (RED) 487

6.4.3 Source-Based Congestion Avoidance 493

6.5 Quality of Service 499

6.5.1 Application Requirements 500

6.5.2 Integrated Services (RSVP) 506

6.5.3 Differentiated Services (EF, AF) 516

6.5.4 Equation-Based Congestion Control 522

6.6 Summary 524

Open Issue: Inside versus Outside the Network 525

Further Reading 526

Exercises 527

7 End-to-End DataProblem: What Do We Do with the Data? 542

7.1 Presentation Formatting 544

7.1.1 Taxonomy 545

7.1.2 Examples (XDR, ASN.1, NDR) 549

7.1.3 Markup Languages (XML) 553

7.2 Data Compression 557

7.2.1 Lossless Compression Algorithms 559

7.2.2 Image Compression (JPEG) 561

7.2.3 Video Compression (MPEG) 566

7.2.4 Transmitting MPEG over a Network 571

xxvi Contents

7.2.5 Audio Compression (MP3) 575

7.3 Summary 576

Open Issue: Computer Networks Meet Consumer Electronics 577

Further Reading 578

Exercises 579

8 Network SecurityProblem: Security Attacks 586

8.1 Cryptographic Tools 589

8.1.1 Principles of Ciphers 589

8.1.2 Symmetric-Key Ciphers 591

8.1.3 Public-Key Ciphers 593

8.1.4 Authenticators 595

8.2 Key Predistribution 599

8.2.1 Predistribution of Public Keys 599

8.2.2 Predistribution of Symmetric Keys 604

8.3 Authentication Protocols 604

8.3.1 Originality and Timeliness Techniques 605

8.3.2 Public-Key Authentication Protocols 606

8.3.3 Symmetric-Key Authentication Protocols 607

8.3.4 Diffie-Hellman Key Agreement 611

8.4 Secure Systems 613

8.4.1 Pretty Good Privacy (PGP) 613

8.4.2 Secure Shell (SSH) 615

8.4.3 Transport Layer Security (TLS, SSL, HTTPS) 618

8.4.4 IP Security (IPsec) 622

8.4.5 Wireless Security (802.11i) 625

8.5 Firewalls 626

8.5.1 Strengths and Weaknesses of Firewalls 629

8.6 Summary 631

Open Issue: Denial-of-Service Attacks 632

Further Reading 633

Exercises 634

9 ApplicationsProblem: Applications Need Their Own Protocols 640

9.1 Traditional Applications 642

9.1.1 Electronic Mail (SMTP, MIME, IMAP) 643

9.1.2 World Wide Web (HTTP) 650

9.1.3 Name Service (DNS) 657

9.1.4 Network Management (SNMP) 666

Contents xxvii

9.2 Web Services 668

9.2.1 Custom Application Protocols (WSDL, SOAP) 670

9.2.2 A Generic Application Protocol (REST) 676

9.3 Multimedia Applications 678

9.3.1 Session Control and Call Control (SDP, SIP, H.323) 679

9.3.2 Resource Allocation for Multimedia Applications 688

9.4 Overlay Networks 693

9.4.1 Routing Overlays 695

9.4.2 Peer-to-Peer Networks (Gnutella, BitTorrent) 702

9.4.3 Content Distribution Networks 714

9.5 Summary 719

Open Issue: New Network Architecture 720

Further Reading 721

Exercises 722

Solutions to Select Exercises 729

Glossary 743

Bibliography 769

Index 785

E D I T I O N 4

COMPUTERNETWORKS

A S Y S T E M S A P P R O A C H

Foundation

I must Create a System, or be enslav’d by another Man’s; I will notReason and Compare: my business is to Create.

—William Blake

uppose you want to build a computer network, one that has the potential toSgrow to global proportions and to support applications as diverse as telecon-ferencing, video-on-demand, electronic commerce, distributed computing, anddigital libraries. What available technologies would serve as the underlying buildingblocks, and what kind of software architecture would you design to integrate these

P R O B L E M

Building a Network

building blocks into an effective com-munication service? Answering thisquestion is the overriding goal ofthis book—to describe the availablebuilding materials and then to showhow they can be used to constructa network from the ground up.

Before we can understand how to design a computer network, we shouldfirst agree on exactly what a computer network is. At one time, the term networkmeant the set of serial lines used to attach dumb terminals to mainframe com-puters. To some, the term implies the voice telephone network. To others, theonly interesting network is the cable network used to disseminate video signals.The main thing these networks have in common is that they are specialized tohandle one particular kind of data (keystrokes, voice, or video) and they typicallyconnect to special-purpose devices (terminals, hand receivers, and television sets).

What distinguishes a computer network from these other types of networks? Prob-ably the most important characteristic of a computer network is its generality. Com-puter networks are built primarily from general-purpose programmable hardware, andthey are not optimized for a particular application like making phone calls or deliv-ering television signals. Instead, they are able to carry many different types of data,and they support a wide, and ever-growing, range of applications. This chapter looks

2

1at some typical applications of computer networks and discussesthe requirements that a network designer who wishes to supportsuch applications must be aware of.Once we understand the requirements, how do we pro-ceed? Fortunately, we will not be building the first network.Others, most notably the community of researchers responsiblefor the Internet, have gone before us. We will use the wealthof experience generated from the Internet to guide our design.This experience is embodied in a network architecture that iden-tifies the available hardware and software components and showshow they can be arranged to form a complete network system.

To start us on the road toward understanding how to builda network, this chapter does four things. First, it explores the re-quirements that different applications and different communitiesof people (such as network users and network operators) placeon the network. Second, it introduces the idea of a network ar-chitecture, which lays the foundation for the rest of the book.Third, it introduces some of the key elements in the implemen-tation of computer networks. Finally, it identifies the key metricsthat are used to evaluate the performance of computer networks.

4 1 Foundation

1.1 ApplicationsMost people know the Internet through its applications: the World Wide Web, email,streaming audio and video, chat rooms, and music (file) sharing. The Web, for example,presents an intuitively simple interface. Users view pages full of textual and graphicalobjects, click on objects that they want to learn more about, and a corresponding newpage appears. Most people are also aware that just under the covers, each selectable objecton a page is bound to an identifier for the next page to be viewed. This identifier, called aUniform Resource Locator (URL), is used to provide a way of identifying all the possiblepages that can be viewed from your web browser. For example,

http://www.cs.princeton.edu/~llp/index.html

is the URL for a page providing information about one of this book’s authors: the stringhttp indicates that the HyperText Transfer Protocol (HTTP) should be used to down-load the page, www.cs.princeton.edu is the name of the machine that serves thepage, 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, as many as 17 messages may be exchanged over the Internet, and this assumesthe page itself is small enough to fit in a single message. This number includes up tosix messages to translate the server name (www.cs.princeton.edu) into its Internetaddress (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 browserto send the HTTP “get” request and the server to respond with the requested page (andfor each side to acknowledge receipt of that message), and four messages to tear down theTCP connection. Of course, this does not include the millions of messages exchangedby Internet nodes throughout the day, just to let each other know that they exist andare ready to serve web pages, translate names to addresses, and forward messages towardtheir ultimate destination.

Another widespread application of the Internet is the delivery of “streaming” audioand video. While an entire video file could first be fetched from a remote machine andthen played on the local machine, similar to the process of downloading and displayinga web page, this would entail waiting for the last second of the video file to be deliveredbefore starting to look at it. Streaming video implies that the sender and the receiverare, respectively, the source and the sink for the video stream. That is, the source gener-ates a video stream (perhaps using a video capture card), sends it across the Internet inmessages, and the sink displays the stream as it arrives.

1.1 Applications 5

There are a variety of different classes of video applications. One class of video ap-plication is video-on-demand, which reads a preexisting movie from disk and transmitsit over the network. Another kind of application is videoconferencing, which is in someways the more challenging (and, for networking people, interesting) case because it hasvery tight timing constraints. Just as when using the telephone, the interactions amongthe participants must be timely. When a person at one end gestures, then that actionmust be displayed at the other end as quickly as possible. Too much delay makes thesystem unusable. Contrast this with video-on-demand where, if it takes several secondsfrom the time the user starts the video until the first image is displayed, the service is stilldeemed satisfactory. Also, interactive video usually implies that video is flowing in bothdirections, while a video-on-demand application is most likely sending video in only onedirection.

One pioneering example of a videoconferencing tool, developed in the early andmid-1990s, is vic. Figure 1.1 shows the control panel for a vic session. vic is actually

Figure 1.1 The vic video application. This shot is from a 1995 release of the tool.

6 1 Foundation

one of a suite of conferencing tools designed at Lawrence Berkeley Laboratory and UCBerkeley. The others include a whiteboard application (wb) that allows users to sendsketches and slides to each other, a visual audio tool called vat, and a session directory(sdr) that is used to create and advertise videoconferences. All these tools run on Unix—hence their lowercase names—and are freely available on the Internet. Many similar toolsare available for other operating systems. It is interesting to note that while video over theInternet is still considered to be in its relative infancy at the time of this writing (2006),that the tools to support video over IP have existed for well over a decade.

Although they are just two examples, downloading pages from the Web and partic-ipating in a videoconference demonstrate the diversity of applications that can be builton top of the Internet, and hint at the complexity of the Internet’s design. Starting fromthe beginning, and addressing one problem at time, the rest of this book explains howto build a network that supports such a wide range of applications. Chapter 9 concludesthe book by revisiting these two specific applications, as well as several others that havebecome popular on today’s Internet.

1.2 RequirementsWe have just established an ambitious goal for ourselves: to understand how to build acomputer network from the ground up. Our approach to accomplishing this goal willbe to start from first principles, and then ask the kinds of questions we would naturallyask if building an actual network. At each step, we will use today’s protocols to illustratevarious design choices available to us, but we will not accept these existing artifacts asgospel. Instead, we will be asking (and answering) the question of why networks aredesigned the way they are. While it is tempting to settle for just understanding the wayit’s done today, it is important to recognize the underlying concepts because networks areconstantly changing as the technology evolves and new applications are invented. It isour experience that once you understand the fundamental ideas, any new protocol thatyou are confronted with will be relatively easy to digest.

The first step is to identify the set of constraints and requirements that influencenetwork design. Before getting started, however, it is important to understand that theexpectations you have of a network depend on your perspective:

■ An application programmer would list the services that his application needs, forexample, a guarantee that each message the application sends will be deliveredwithout error within a certain amount of time.

■ A network designer would list the properties of a cost-effective design, for exam-ple, that network resources are efficiently utilized and fairly allocated to differentusers.

1.2 Requirements 7

■ A network provider would list the characteristics of a system that is easy to ad-minister and manage, for example, in which faults can be easily isolated andwhere it is easy to account for usage.

This section attempts to distill these different perspectives into a high-level intro-duction to the major considerations that drive network design, and in doing so, identifiesthe challenges addressed throughout the rest of this book.

1.2.1 ConnectivityStarting with the obvious, a network must provide connectivity among a set of comput-ers. Sometimes it is enough to build a limited network that connects only a few selectmachines. In fact, for reasons of privacy and security, many private (corporate) networkshave the explicit goal of limiting the set of machines that are connected. In contrast,other networks (of which the Internet is the prime example) are designed to grow in away that allows them the potential to connect all the computers in the world. A systemthat is designed to support growth to an arbitrarily large size is said to scale. Using theInternet as a model, this book addresses the challenge of scalability.

Links, Nodes, and Clouds

Network connectivity occurs at many different levels. At the lowest level, a network canconsist of two or more computers directly connected by some physical medium, such asa coaxial cable or an optical fiber. We call such a physical medium a link, and we oftenrefer to the computers it connects as nodes. (Sometimes a node is a more specialized pieceof hardware rather than a computer, but we overlook that distinction for the purposesof this discussion.) As illustrated in Figure 1.2, physical links are sometimes limited to apair of nodes (such a link is said to be point-to-point), while in other cases, more than twonodes may share a single physical link (such a link is said to be multiple-access). Whether

Figure 1.2 Direct links: (a) point-to-point; (b) multiple-access.

8 1 Foundation

a given link supports point-to-point or multiple-access connectivity depends on how thenode is attached to the link. It is also the case that multiple-access links are often limitedin size, in terms of both the geographical distance they can cover and the number ofnodes they can connect.

If computer networks were limited to situations in which all nodes are directlyconnected to each other over a common physical medium, then networks would eitherbe very limited in the number of computers they could connect, or the number of wirescoming out of the back of each node would quickly become both unmanageable andvery expensive. Fortunately, connectivity between two nodes does not necessarily imply adirect physical connection between them—indirect connectivity may be achieved amonga set of cooperating nodes. Consider the following two examples of how a collection ofcomputers 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 thatforwards 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 switchednetworks, of which the two most common are circuit-switched and packet-switched. Theformer is most notably employed by the telephone system, while the latter is used for theoverwhelming majority of computer networks and will be the focus of this book. Theimportant feature of packet-switched networks is that the nodes in such a network send

Figure 1.3 Switched network.

1.2 Requirements 9

discrete blocks of data to each other. Think of these blocks of data as corresponding tosome piece of application data such as a file, a piece of email, or an image. We call eachblock 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.2.

Packet-switched networks typically use a strategy called store-and-forward. As thename suggests, each node in a store-and-forward network first receives a complete packetover some link, stores the packet in its internal memory, and then forwards the com-plete packet to the next node. In contrast, a circuit-switched network first establishes adedicated circuit across a sequence of links and then allows the source node to send astream of bits across this circuit to a destination node. The major reason for using packetswitching rather than circuit switching in a computer network is efficiency, discussed inthe next subsection.

The cloud in Figure 1.3 distinguishes between the nodes on the inside that imple-ment the network (they are commonly called switches, and their primary function is tostore 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 computernetworking. In general, we use a cloud to denote any type of network, whether it is asingle point-to-point link, a multiple-access link, or a switched network. Thus, when-ever you see a cloud used in a figure, you can think of it as a placeholder for any of thenetworking technologies covered in this book.

A second way in which a set of computers can be indirectly connected is shown inFigure 1.4. In this situation, a set of independent networks (clouds) are interconnectedto form an internetwork, or internet for short. We adopt the Internet’s convention ofreferring to a generic internetwork of networks as a lowercase i internet, and the currentlyoperational TCP/IP Internet as the capital I Internet. A node that is connected to two ormore networks is commonly called a router or gateway, and it plays much the same roleas a switch—it forwards messages from one network to another. Note that an internetcan itself be viewed as another kind of network, which means that an internet can bebuilt from an interconnection of internets. Thus, we can recursively build arbitrarilylarge networks by interconnecting clouds to form larger clouds.

Just because a set of hosts are directly or indirectly connected to each other does notmean that we have succeeded in providing host-to-host connectivity. The final require-ment is that each node must be able to state which of the other nodes on the networkit wants to communicate with. This is done by assigning an address to each node. Anaddress is a byte string that identifies a node; that is, the network can use a node’s ad-dress to distinguish it from the other nodes connected to the network. When a sourcenode wants the network to deliver a message to a certain destination node, it specifiesthe address of the destination node. If the sending and receiving nodes are not directly

10 1 Foundation

Figure 1.4 Interconnection of networks.

connected, then the switches and routers of the network use this address to decide howto 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 calledrouting.

This brief introduction to addressing and routing has presumed that the sourcenode wants to send a message to a single destination node (unicast). While this is themost common scenario, it is also possible that the source node might want to broadcast amessage to all the nodes on the network. Or a source node might want to send a messageto 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 itsupports multicast and broadcast addresses.▲

The main idea to take away from this discussion is that we can define a networkrecursively as consisting of two or more nodes connected by a physical link, or as twoor more networks connected by a node. In other words, a network can be constructedfrom a nesting of networks, where at the bottom level, the network is implemented bysome physical medium. One of the key challenges in providing network connectivity isto define an address for each node that is reachable on the network (including supportfor broadcast and multicast connectivity), and to be able to use this address to routemessages toward the appropriate destination node(s).

1.2 Requirements 11

1.2.2 Cost-Effective Resource SharingAs stated above, this book focuses on packet-switched networks. This section explains thekey requirement of computer networks—efficiency—that leads us to packet switching asthe strategy of choice.

Given a collection of nodes indirectly connected by a nesting of networks, it ispossible for any pair of hosts to send messages to each other across a sequence of linksand nodes. Of course, we want to do more than support just one pair of communicatinghosts—we want to provide all pairs of hosts with the ability to exchange messages. Thequestion, then, is how do all the hosts that want to communicate share the network,especially if they want to use it at the same time? And, as if that problem isn’t hardenough, how do several hosts share the same link when they all want to use it at the sametime?

To understand how hosts share a network, we need to introduce a fundamentalconcept, multiplexing, which means that a system resource is shared among multipleusers. At an intuitive level, multiplexing can be explained by analogy to a timesharingcomputer system, where a single physical CPU is shared (multiplexed) among multiplejobs, each of which believes it has its own private processor. Similarly, data being sent bymultiple 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 tothe three hosts on the right (receivers R1–R3) by sharing a switched network that con-tains only one physical link. (For simplicity, assume that host S1 is sending data to hostR1, and so on.) In this situation, three flows of data—corresponding to the three pairsof hosts—are multiplexed onto a single physical link by switch 1 and then demultiplexedback into separate flows by switch 2. Note that we are being intentionally vague about

Figure 1.5 Multiplexing multiple logical flows over a single physical link.

12 1 Foundation

exactly what a “flow of data” corresponds to. For the purposes of this discussion, assumethat each host on the left has a large supply of data that it wants to send to its counterparton the right.

There are several different methods for multiplexing multiple flows onto one phys-ical link. One common method is synchronous time-division multiplexing (STDM). Theidea of STDM is to divide time into equal-sized quanta and, in a round-robin fashion,give each flow a chance to send its data over the physical link. In other words, duringtime quantum 1, data from S1 to R1 is transmitted; during time quantum 2, data fromS2 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-divisionmultiplexing (FDM). The idea of FDM is to transmit each flow over the physical link ata different frequency, much the same way that the signals for different TV stations aretransmitted at a different frequency on a physical 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 phys-ical link—that is, its time quantum or its frequency—remains idle, even if one of theother flows has data to transmit. For example, S3 had to wait its turn behind S1 and S2in the previous paragraph, even if S1 and S2 had nothing to send. For computer commu-nication, the amount of time that a link is idle can be very large—for example, considerthe amount of time you spend reading a web page (leaving the link idle) compared tothe time you spend fetching the page. Second, both STDM and FDM are limited tosituations in which the maximum number of flows is fixed and known ahead of time. Itis not practical to resize the quantum or to add additional quanta in the case of STDMor to add new frequencies in the case of FDM.

The form of multiplexing that we make most use of in this book is called statisticalmultiplexing. 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 STDMin that the physical link is shared over time—first data from one flow is transmittedover the physical link, then data from another flow is transmitted, and so on. UnlikeSTDM, however, data is transmitted from each flow on demand rather than during apredetermined time slot. Thus, if only one flow has data to send, it gets to transmit thatdata without waiting for its quantum to come around and thus without having to watchthe quanta assigned to the other flows go by unused. It is this avoidance of idle time thatgives packet switching its efficiency.

As defined so far, however, statistical multiplexing has no mechanism to ensure thatall the flows eventually get their turn to transmit over the physical link. That is, once aflow begins sending data, we need some way to limit the transmission, so that the otherflows can have a turn. To account for this need, statistical multiplexing defines an upperbound on the size of the block of data that each flow is permitted to transmit at a given

1.2 Requirements 13

time. This limited-size block of data is typically referred to as a packet, to distinguish itfrom the arbitrarily large message that an application program might want to transmit.Because a packet-switched network limits the maximum size of packets, a host may notbe able to send a complete message in one packet. The source may need to fragmentthe message into several packets, with the receiver reassembling the packets back into theoriginal message.

In other words, each flow sends a sequence of packets over the physical link, witha 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 packetsback-to-back. However, should more than one of the flows have data to send, then theirpackets are interleaved on the link. Figure 1.6 depicts a switch multiplexing packets frommultiple sources onto a single shared link.

The decision as to which packet to send next on a shared link can be made in anumber of different ways. For example, in a network consisting of switches intercon-nected by links such as the one in Figure 1.5, the decision would be made by the switchthat transmits packets onto the shared link. (As we will see later, not all packet-switchednetworks actually involve switches, and they may use other mechanisms to determinewhose packet goes onto the link next.) Each switch in a packet-switched network makesthis decision independently, on a packet-by-packet basis. One of the issues that faces anetwork designer is how to make this decision in a fair manner. For example, a switchcould be designed to service packets on a first-in-first-out (FIFO) basis. Another ap-proach would be to transmit the packets from each of the different flows that are cur-rently sending data through the switch in a round-robin manner. This might be done to

Figure 1.6 A switch multiplexing packets from multiple sources onto one shared link.

14 1 Foundation

ensure that certain flows receive a particular share of the link’s bandwidth, or that theynever have their packets delayed in the switch for more than a certain length of time.A network that attempts to allocate bandwidth to particular flows is sometimes said tosupport 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 incomingpacket streams onto one outgoing link, it is possible that the switch will receive packetsfaster than the shared link can accommodate. In this case, the switch is forced to bufferthese packets in its memory. Should a switch receive packets faster than it can send themfor an extended period of time, then the switch will eventually run out of buffer space,and some packets will have to be dropped. When a switch is operating in this state, it issaid to be congested.▲

The bottom line is that statistical multiplexing defines a cost-effective way for mul-tiple 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 ofthe network are allocated to different flows, with each switch able to schedule the use ofthe physical links it is connected to on a per-packet basis. Fairly allocating link capacityto different flows and dealing with congestion when it occurs are the key challenges ofstatistical multiplexing.

1.2.3 Support for Common Services

While the previous section outlined thechallenges involved in providing cost-effective connectivity among a group ofhosts, it is overly simplistic to view a com-puter network as simply delivering pack-ets among a collection of computers. Itis more accurate to think of a networkas providing the means for a set of appli-cation processes that are distributed overthose computers to communicate. In otherwords, the next requirement of a computernetwork is that the application programsrunning on the hosts connected to the net-work must be able to communicate in ameaningful way.

When two application programsneed to communicate with each other,

SANs, LANs, MANs, and WANsOne way to characterize networksis according to their size. Two well-known examples are local area net-works (LANs) and wide area networks(WANs); the former typically extendless than 1 km, while the latter can beworldwide. Other networks are clas-sified as metropolitan area networks(MANs), which usually span tens ofkilometers. The reason such classifi-cations are interesting is that the sizeof a network often has implicationsfor the underlying technology that canbe used, with a key factor being theamount of time it takes for data to

1.2 Requirements 15

propagate from one end of the net-work to the other; we discuss this is-sue more in later chapters.

An interesting historical noteis that the term “wide area network”was not applied to the first WANsbecause there was no other sort ofnetwork to differentiate them from.When computers were incredibly rareand expensive, there was no point inthinking about how to connect allthe computers in the local area—therewas only one computer in that area.Only as computers began to prolifer-ate did LANs become necessary, andthe term “WAN” was then introducedto describe the larger networks thatinterconnected geographically distantcomputers.

Another kind of network thatwe need to be aware of is a storagearea network (SAN). SANs are usuallyconfined to a single room and con-nect the various components of a largecomputing system, such as disk arraysand servers. For example, High Per-formance Parallel Interface (HiPPI)and Fiber Channel are two commonSAN technologies used to connectmassively parallel processors to scal-able storage servers and data vaults.Although this book does not describesuch networks in detail, they areworth knowing about because theyare often at the leading edge in termsof performance, and because it is in-creasingly common to connect suchnetworks into LANs and WANs.

there are a lot of complicated things thatneed to happen beyond simply sending amessage from one host to another. Oneoption would be for application design-ers to build all that complicated func-tionality into each application program.However, since many applications needcommon services, it is much more logicalto implement those common services onceand then to let the application designerbuild the application using those services.The challenge for a network designer is toidentify the right set of common services.The goal is to hide the complexity ofthe network from the application with-out overly constraining the applicationdesigner.

Intuitively, we view the networkas providing logical channels over whichapplication-level processes can communi-cate with each other; each channel pro-vides the set of services required by thatapplication. In other words, just as we usea cloud to abstractly represent connectivityamong a set of computers, we now thinkof a channel as connecting one processto another. Figure 1.7 shows a pair ofapplication-level processes communicatingover a logical channel that is, in turn, im-plemented on top of a cloud that connectsa set of hosts. We can think of the channelas being like a pipe connecting two appli-cations, so that a sending application canput data in one end and expect that datato be delivered by the network to the ap-plication at the other end of the pipe.

The challenge is to recognize whatfunctionality the channels should pro-vide to application programs. For example,

16 1 Foundation

Figure 1.7 Processes communicating over an abstract channel.

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 messages arrive at therecipient process in the same order in which they are sent, or does the recipient not careabout the order in which messages arrive? Does the network need to ensure that no thirdparties are able to eavesdrop on the channel, or is privacy not a concern? In general, anetwork provides a variety of different types of channels, with each application selectingthe type that best meets its needs. The rest of this section illustrates the thinking involvedin defining useful channels.

Identifying Common Communication Patterns

Designing abstract channels involves first understanding the communication needs of arepresentative collection of applications, then extracting their common communicationrequirements, and finally incorporating the functionality that meets these requirementsin the network.

One of the earliest applications supported on any network is a file access programlike FTP (File Transfer Protocol) or NFS (Network File System). Although many detailsvary—for example, whether whole files are transferred across the network or only singleblocks of the file are read/written at a given time—the communication component ofremote file access is characterized by a pair of processes, one that requests that a file be

1.2 Requirements 17

read or written and a second process that honors this request. The process that requestsaccess to the file is called the client, and the process that supports access to the file iscalled the server.

Reading a file involves the client sending a small request message to a server and theserver responding with a large message that contains the data in the file. Writing worksin the opposite way—the client sends a large message containing the data to be writtento the server, and the server responds with a small message confirming that the write todisk has taken place. A digital library, as exemplified by the World Wide Web, is anotherapplication that behaves in a similar way: a client process makes a request, and a serverprocess responds by returning the requested data.

Using file access, a digital library, and the two video applications described in thePreface (videoconferencing and video-on-demand) as a representative sample, we mightdecide to provide the following two types of channels: request/reply channels and messagestream channels. The request/reply channel would be used by the file transfer and digitallibrary applications. It would guarantee that every message sent by one side is receivedby the other side and that only one copy of each message is delivered. The request/replychannel might also protect the privacy and integrity of the data that flows over it, so thatunauthorized parties cannot read or modify the data being exchanged between the clientand server processes.

The message stream channel could be used by both the video-on-demand andvideoconferencing applications, provided it is parameterized to support both one-wayand two-way traffic and to support different delay properties. The message stream chan-nel might not need to guarantee that all messages are delivered, since a video applicationcan 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 whichthey were sent, to avoid displaying frames out of sequence. Like the request/reply chan-nel, the message stream channel might want to ensure the privacy and integrity of thevideo data. Finally, the message stream channel might need to support multicast, so thatmultiple parties can participate in the teleconference or view the video.

While it is common for a network designer to strive for the smallest number ofabstract channel types that can serve the largest number of applications, there is a dangerin trying to get away with too few channel abstractions. Simply stated, if you have ahammer, then everything looks like a nail. For example, if all you have are message streamand request/reply channels, then it is tempting to use them for the next applicationthat comes along, even if neither type provides exactly the semantics needed by theapplication. Thus, network designers will probably be inventing new types of channels—and adding options to existing channels—for as long as application programmers areinventing new applications.

18 1 Foundation

Also note that independent of exactly what functionality a given channel provides,there is the question of where that functionality is implemented. In many cases, it is eas-iest to view the host-to-host connectivity of the underlying network as simply providinga bit pipe, with any high-level communication semantics provided at the end hosts. Theadvantage of this approach is it keeps the switches in the middle of the network as simpleas possible—they simply forward packets—but it requires the end hosts to take on muchof the burden of supporting semantically rich process-to-process channels. The alterna-tive is to push additional functionality onto the switches, thereby allowing the end hoststo be “dumb” devices (e.g., telephone handsets). We will see this question of how variousnetwork 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 themost important functions that a network can provide. It is difficult to determine howto 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 bitsin the data being transmitted, switches run out of buffer space, and if these sorts ofphysical problems aren’t enough to worry about, the software that manages the hardwaresometimes forwards packets into oblivion. Thus, a major requirement of a network isto recover from certain kinds of failures, so that application programs don’t have to dealwith them, or even be aware of them.

There are three general classes of failure that network designers have to worryabout. First, as a packet is transmitted over a physical link, bit errors may be introducedinto the data; that is, a 1 is turned into a 0 or vice versa. Sometimes single bits arecorrupted, but more often than not, a burst error occurs—several consecutive bits arecorrupted. Bit errors typically occur because outside forces, such as lightning strikes,power surges, and microwave ovens, interfere with the transmission of data. The goodnews 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 atypical optical fiber. As we will see, there are techniques that detect these bit errors withhigh probability. Once detected, it is sometimes possible to correct for such errors—ifwe know which bit or bits are corrupted, we can simply flip them—while in other casesthe damage is so bad that it is necessary to discard the entire packet. In such a case, thesender may be expected to retransmit the packet.

The second class of failure is at the packet, rather than the bit, level; that is, acomplete packet is lost by the network. One reason this can happen is that the packetcontains an uncorrectable bit error and therefore has to be discarded. A more likely

1.3 Network Architecture 19

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 hasno place to store the packet, and therefore is forced to drop it. This is the problem ofcongestion mentioned in Section 1.2.2. Less commonly, the software running on oneof the nodes that handles the packet makes a mistake. For example, it might incorrectlyforward a packet out on the wrong link, so that the packet never finds its way to theultimate destination. As we will see, one of the main difficulties in dealing with lostpackets is distinguishing between a packet that is indeed lost and one that is merely latein 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 anetwork 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, for example,it is sometimes possible to route around a failed node or link. One of the difficulties indealing with this third class of failure is distinguishing between a failed computer andone that is merely slow, or in the case of a link, between one that has been cut and onethat 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 channelsinvolves both understanding the applications’ requirements and recognizing the limita-tions of the underlying technology. The challenge is to fill in the gap between what theapplication expects and what the underlying technology can provide. This is sometimescalled the semantic gap.

1.3 Network ArchitectureIn case you hadn’t noticed, the previous section established a pretty substantial set ofrequirements for network design—a computer network must provide general, cost-effective, fair, and robust connectivity among a large number of computers. As if thisweren’t enough, networks do not remain fixed at any single point in time, but mustevolve to accommodate changes in both the underlying technologies upon which theyare based as well as changes in the demands placed on them by application programs.Designing a network to meet these requirements is no small task.

To help deal with this complexity, network designers have developed generalblueprints—usually called network architectures—that guide the design and implemen-tation of networks. This section defines more carefully what we mean by a network ar-chitecture by introducing the central ideas that are common to all network architectures.

20 1 Foundation

It also introduces two of the most widely referenced architectures—the OSI architectureand the Internet architecture.

1.3.1 Layering and ProtocolsWhen a system gets complex, the system designer introduces another level of abstraction.The idea of an abstraction is to define a unifying model that can capture some importantaspect of the system, encapsulate this model in an object that provides an interface thatcan be manipulated by other components of the system, and hide the details of howthe object is implemented from the users of the object. The challenge is to identifyabstractions that simultaneously provide a service that proves useful in a large numberof situations and that can be efficiently implemented in the underlying system. This isexactly what we were doing when we introduced the idea of a channel in the previoussection: We were providing an abstraction for applications that hides the complexity ofthe network from application writers.

Abstractions naturally lead to layering, especially in network systems. The generalidea is that you start with the services offered by the underlying hardware, and thenadd a sequence of layers, each providing a higher (more abstract) level of service. Theservices provided at the high layers are implemented in terms of the services provided bythe low layers. Drawing on the discussion of requirements given in the previous section,for example, we might imagine a simple network as having two layers of abstractionsandwiched between the application program and the underlying hardware, as illustratedin 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 complexnetwork 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 buildinga network into more manageable components. Rather than implementing a monolithicpiece of software that does everything you will ever want, you can implement several

Figure 1.8 Example of a layered network system.

1.3 Network Architecture 21

Figure 1.9 Layered system with alternative abstractions available at a given layer.

layers, each of which solves one part of the problem. Second, it provides a more modulardesign. If you decide that you want to add some new service, you may only need tomodify the functionality at one layer, reusing the functions provided at all the otherlayers.

Thinking of a system as a linear sequence of layers is an oversimplification, 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-levelabstractions. To see this, consider the two types of channels discussed in Section 1.2.3:One provides a request/reply service and one supports a message stream service. Thesetwo channels might be alternative offerings at some level of a multilevel networkingsystem, as illustrated in Figure 1.9.

Using this discussion of layering as a foundation, we are now ready to discuss thearchitecture of a network more precisely. For starters, the abstract objects that make upthe layers of a network system are called protocols. That is, a protocol provides a com-munication service that higher-level objects (such as application processes, or perhapshigher-level protocols) use to exchange messages. For example, we could imagine a net-work that supports a request/reply protocol and a message stream protocol, correspond-ing to the request/reply and message stream channels discussed above.

Each protocol defines two different interfaces. First, it defines a service interface tothe other objects on the same computer that want to use its communication services. Thisservice interface defines the operatio