Cisco press end to end qos network design quality of service in LANs WANs and VPNs nov 2004 ISBN 1587051761

Publisher : Cisco Press Pub Date : November 09, 2004 ISBN : 1-58705-176-1 Pages : 768 Best-practice QoS designs for protecting voice, video, and critical data while mitigating network de

Publisher : Cisco Press Pub Date : November 09, 2004 ISBN : 1-58705-176-1 Pages : 768

Best-practice QoS designs for protecting voice, video, and critical data while mitigating network denial-of-service attacks

Understand the service-level requirements of voice, video, and data applications

class QoS tactics for DoS/worm mitigation

Examine strategic QoS best practices, including Scavenger-Learn about QoS tools and the various interdependencies and caveats of these tools that can impact design

considerations Learn how to protect voice, video, and data traffic using various QoS mechanisms

Evaluate design recommendations for protecting voice, video, and multiple classes of data while mitigating DoS/worm attacks for the following network infrastructure architectures: campus LAN, private WAN, MPLS VPN, and IPSec VPN

Quality of Service (QoS) has already proven itself as the enabling technology for the convergence of voice, video, and data

networks As business needs evolve, so do the demands for QoS The need to protect critical applications via QoS mechanisms in business networks has escalated over the past few years, primarily due to the increased frequency and sophistication of denial-of-service (DoS) and worm attacks.

End-to-End QoS Network Design is a detailed handbook for planning and deploying QoS solutions to address current business needs This book goes beyond discussing available QoS

technologies and considers detailed design examples that illustrate where, when, and how to deploy various QoS features to provide validated and tested solutions for voice, video, and critical data over the LAN, WAN, and VPN.

The book starts with a brief background of network infrastructure evolution and the subsequent need for QoS It then goes on to cover the various QoS features and tools currently available and comments on their evolution and direction The QoS requirements

of voice, interactive and streaming video, and multiple classes of data applications are presented, along with an overview of the nature and effects of various types of DoS and worm attacks QoS best-practice design principles are introduced to show how QoS mechanisms can be strategically deployed end-to-end to address application requirements while mitigating network attacks The next section focuses on how these strategic design principles are applied to campus LAN QoS design Considerations and detailed design recommendations specific to the access, distribution, and core layers of an enterprise campus network are presented Private WAN QoS design is discussed in the following section, where WAN-specific considerations and detailed QoS designs are presented for leased-lines, Frame Relay, ATM, ATM-to-FR Service Interworking, and ISDN networks Branch-specific designs include Cisco(r) SAFE recommendations for using Network-Based

Application Recognition (NBAR) for known-worm identification and policing The final section covers Layer 3 VPN QoS design-for both MPLS and IPSec VPNs As businesses are migrating to VPNs to meet their wide-area networking needs at lower costs,

considerations specific to these topologies are required to be reflected in their customer-edge QoS designs MPLS VPN QoS design is examined from both the enterprise and service

provider's perspectives Additionally, IPSec VPN QoS designs cover site-to-site and teleworker contexts.

Whether you are looking for an introduction to QoS principles and practices or a QoS planning and deployment guide, this book provides you with the expert advice you need to design and implement comprehensive QoS solutions.

This book is part of the Networking Technology Series from Cisco Press, which offers networking professionals valuable information for constructing efficient networks, understanding new

technologies, and building successful careers.

Publisher : Cisco Press Pub Date : November 09, 2004 ISBN : 1-58705-176-1 Pages : 768

QoS Requirements of Data

QoS Requirements of the Control Plane

Scavenger Class

DoS and Worm Mitigation Strategy Through Scavenger Class QoS Principles of QoS Design

WAN Aggregator/Branch Router Handoff Considerations Case Study: Campus QoS Design

Further Reading

Chapter 16 IPSec VPN QoS Design

Site-to-Site V3PN QoS Considerations

Site-to-Site V3PN QoS Designs

Headend VPN Edge QoS Options for Site-to-Site V3PNs Teleworker V3PN QoS Considerations

information storage and retrieval system, without written

permission from the publisher, except for the inclusion of briefquotations in a review

trademark or service mark

Service network design best-practice recommendations Everyeffort has been made to make this book as complete and asaccurate as possible, but no warranty or fitness is implied

This book is designed to provide information about Quality-of-The information is provided on an "as is" basis The authors,Cisco Press, and Cisco Systems, Inc., shall have neither liabilitynor responsibility to any person or entity with respect to anyloss or damages arising from the information contained in thisbook or from the use of the discs or programs that may

accompany it

The opinions expressed in this book belong to the author andare not necessarily those of Cisco Systems, Inc

technical community

Readers' feedback is a natural continuation of this process Ifyou have any comments regarding how we could improve the

feedback@ciscopress.com Please make sure to include thebook title and ISBN in your message

Luxembourg • Malaysia • Mexico • The Netherlands • New

Zealand • Norway • Peru • Philippines • Poland • Portugal •Puerto Rico • Romania • Russia • Saudi Arabia • Scotland •Singapore • Slovakia • Slovenia • South Africa • Spain •

Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine •United Kingdom • United States • Venezuela • Vietnam •

Study are service marks of Cisco Systems, Inc.; and Aironet,ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco,the Cisco Certified Internetwork Expert logo, Cisco IOS, the

Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems

Capital, the Cisco Systems logo, Empowering the Internet

Generation, Enterprise/Solver, EtherChannel, EtherSwitch, FastStep, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise,the iQ logo, LightStream, MGX, MICA, the Networkers logo,

Printed in the USA

Dedications

Tim: This book is obviously dedicated to my wife; otherwise, of

course, she'd kill me It amuses me to think that if others areactually reading this, they probably think I'm only jokingbut,alas, the Greek capacity for vengeance is no laughing matter Icancelled far too many dates, stayed in my office and labs fartoo many weekends, and stared blankly into space (thinkingabout these designs) far too many times (while she was talking

to me) to ever allow the thought of not dedicating this work to

her to even cross my tiny xeno-brain

I know, I know, it's not a work of literature or a collection ofpoetry: It's just a technical bookboring to tears for any not

interested in the subject (and probably just boring to yawns for

Christina: To Robert Verkroost and Ria and Willie Hattingh,

who unfailingly support my various forays into the publishingworld

Tim Szigeti, CCIE No 9794, attended the University of British

Columbia, where he majored in management information

systems After graduating, Tim joined Cisco Systems and soonafter began to specialize in Quality-of-Service technologies,

supporting technical marketing initiatives for the Cisco ClassData acquisition, which led to the Cisco QoS Policy Manager(QPM) product After supporting QPM through several

generations and serving as product manager for the Cisco

Quality of Service Device Manager (QDM) product, Tim joinedthe Enterprise Solutions Engineering team and led large-scaletesting initiatives of campus, WAN, and VPN QoS designs Timnow belongs to the newly formed Technology Solutions

Engineering team within the Cisco Central Technical Marketingorganization There, he continues to define and drive strategicQoS solutions across Cisco technology groups and business

units while working with many Fortune 500 companiesboth

enterprise and service providersproviding QoS design expertise

Christina Hattingh is a member of the technical staff in the

Multiservice Customer Edge Business Unit of Cisco Systems.These products, including the Cisco 2600, 3600, and 3700

series access router platforms, were some of the first Cisco

platforms to converge voice and data traffic onto an IP network

by offering TDM voice interfaces, WAN interfaces, and criticalQoS features, while later integrating call control elements intothe router-based platform itself In this role, she trains Ciscosales staff and advises customers on voice network deploymentand design

Frank Knox has more than 37 years of telecommunications

experience During his career at IBM, Frank held positions infield service, field support, service planning, and education; hisfinal position before retirement was curriculum manager for

IBM's Network Education in North America After leaving IBM,Frank held the position of network engineering manager for GTEDirectories, where he was responsible for the company's voiceand data network design and support Concurrent with his work

at IBM and GTE, Frank taught as an adjunct professor for theUniversity of Dallas MBA program For the past six years, Frankhas worked for Skyline Computer as a senior instructor and

consultant; he is currently Skyline's chief technical officer

(CTO) Frank holds two CCIE certifications (R&S and SNA/IP);

he also has a master's degree in telecommunications from PaceUniversity

Anna To has worked with Cisco for more than three years as a

software/deployment engineer on the ITD QoS team One ofAnna's key tasks is to promote QoS deployment and increasethe understanding of QoS technology in the field Anna works

experience with the Cisco Customer Proof of Concept Labs

Connie specializes in QoS designs that meet the needs of

converged data, voice and video networks, and designs thatinvolve IPSec VPNs

Off the top, I'd like to thank my friend and co-worker Dave

Barton, whoalthough he was extremely busy downing beers atChicago's Navy Piergallantly managed to sic Brett Bartow onto

me, which got the ball rolling on this whole project (Dave, didyou make it back okay to the hotel that night?)

thorough work so that I did not to have to reinvent the wheel

on these designs

Thank you, Mike Herbert, for your brilliant flash of using QoS forDoS/worm mitigation via the Scavenger class Though you

derailed and postponed many whitepapers and publications

(including this one), you opened up a whole new scope of

application for QoS technologiesand we're all better off for it

Thank you, too, Alex Dolan, for building out multiple large-scaleMPLS VPN testbeds for me and continually tweaking them tosuit my mood-of-the-day I don't know where your patience oryour good nature comes from, but they're most appreciated.Thanks, too, for nudging me back into playing ice hockey Nexttime I break a leg or chip a tooth, I'll think of you and grimace

Muchos gracias, Arlindo Callejas, for being much more than my

awesome lab administrator You always went out of your way for

me and got me everything I ever neededinstantly Sometimes

A round of applause is merited by the technical reviewers

Having done this before myself, I can genuinely appreciate thetime, effort, and painstaking attention to detail that goes intothis process Frank, your comments were right on and helpedmake this a better book Anna, is there anything you don't

know about Cisco QoS? I'm very thankful you took time out ofyour extremely busy schedule, developing code while helpinganyone and everyone on planet Earth (and some nearby

systems) that are having QoS problems And Connie, if youhadn't reviewed this work, I would not have submitted it forpublication You're simply the best technical reviewerand one ofthe sharpest engineersI've ever had the pleasure of workingwith

Thank you Howard Jones for your excellent editing and

coordinating the complex content review and copy review

processes And thank you, too, Patrick Kanouse for managingthe production of this publication and allowing me to make

hundreds of last-minute edits in the galley-review phase (whenedits are to be kept at a minimum) How you put up with me I'llnever know, but I truly appreciate your patience and desire tohelp make this book as correct and as current as possible Alsothank you Chris Cleveland for your fine recommendations andguidance during the course of production

I need to extend thanks also to Debbie Morrison, who is, in myopinion, the best technical writerperiod Debbie, as I've saidover and over again, you polish my ugly little chunks of coalinto beautiful diamonds I love how I can barely recognize myown work once you've done your magic I'll truly miss workingwith you now that you've gone on to bigger and better things.(I'm so terrified of the futurewho's going to make me look goodnow?)

wayside, but your persistence, perseverance, and patience kept

it all going Thank you You didn't back off, and I'm glad for it.Your guidance has been uncanny, and your vision has paid off.Thanks also to your production team

And lastly, thank you, Christina You made it fun Right when Iread your first draft of your first chapter, I knew you were thebest person to embark on this project with (even though youwrite like an engineer!) Thank you for sacrificing so many

weekends on this (thank Robert for me too) I know this is onlyone of many publishing projects you're pursuing; all I ask isthat you save me an autograph before you move to Hawaii andstart on your best-seller!

Icons Used in This Book

The conventions used to present command syntax in this bookare the same conventions used in the Cisco IOS Command

Reference The Command Reference describes these

conventions as follows:

Boldface indicates commands and keywords that are

entered literally as shown In actual configuration examplesand output (not general command syntax), boldface

Square brackets [ ] indicate optional elements

Braces { } indicate a required choice

Braces within brackets [{ }] indicate a required choice

within an optional element

QoS is a maturing technology, one that many networking

professionals, to a greater or lesser extent, are already familiarwith This is both a blessing and a curse It is a blessing

because more administrators are enabling QoS on their

networks, which allows for the convergence of voice, video, anddata onto a single IP network, among other business

advantages It is a curse because almost every individual withwhom I've ever discussed QoS designs has a slightly differentopinion on how QoS should be enabled

The result often has led to confusing babble from the

customer's perspective, especially for customers seeking QoSdesign guidance for non-VoIP applications For example, a

customer might ask the local Cisco Systems engineer how best

to enable QoS for networks and receive one answer Later, thecustomer might attend an Executive Briefing session in SanJose and receive a different answer (even receiving multipledifferent answers within the same day from different

presenters) Later, while attending a Networkers conference,the customer might be told something else entirely Finally,

when the customer gets home and picks up a Cisco Press book,

he or she might get still another story Confused and frustrated,many customers decide to enable minimal QoS, if any, despitethe touted benefits that they were sold on Therefore, in myopinion, presenting such inconsistent recommendations is amajor disservice to our customers and a considerable barrier tothe widespread deployment of QoS

The Cisco Technology Baseline committees were created to

remedy the situation and help unify various technologies acrossCisco products and platforms To this end, a series of

Technology Baselines were developed internally by our leadingexperts (many of whom likewise developed the related IETF

features must conform Additionally, these documents provideuniform, strategic recommendations (that can be shared withcustomers) to help ensure that QoS recommendations are

unified and consistent, for both enterprises and service

providers Specific to QoS, the QoS Baseline strictly defines theCisco strategic direction in QoS technologies from now into theforeseeable future

Thus, a unique feature of this book is that it is the first CiscoPress publication to present design recommendations that arecompliant with the QoS Baseline

Another huge advantage of this publication is that it is one ofthe first documents to present a detailed, cohesive strategy thatshows how QoS can extend beyond its traditional role (of

prioritizing important applications) and be used to provide

deferential services to DoS/worm-generated traffic, thus

mitigating and containing the collateral damage caused by suchattacks This is a fresh perspective and context for a technologythat many considered baked and done Yet in such a role, thecritical interdependency of Quality of Service, High-Availability,and Security technologies becomes manifest and holisticallypromotes the "Self-Defending Networks" business objective

However, having a strategic direction and tactical approachesfor QoS designs is only half the solution An important mottothat I like to emphasize is: "In theory, theory and practice arethe same." It's one thing to make a design recommendationbased on an assumption that something "should work." It's

something completely different to make a design

recommendation that has been verified in large-scale, complexlab scenarios, such as provided by one of the largest Cisco labs:the Enterprise Solutions Engineering testbeds in Research

Triangle Park, North Carolina

Notwithstanding, it should be noted that designs presented inthis book are not infallible While all due diligence has been

rigorous technical reviewing process by some of the sharpestCisco QoS engineershardware/software/platform-specific issuesthat didn't surface during our tests may nonetheless exist, asmay issues introduced in newer releases of hardware/softwaredating from our time of testing

Furthermore, the recommendations presented in this book arenot to be taken as commandments or dictates ("Thou shalt

configure this or that"), but are simply best-practice designrecommendations that are the result of extensive lab testingand customer deployments They should be viewed as

templates that can be modified and tweaked to customer-specific requirements Following the 80/20 Pareto Rule, thesedesign recommendations should be viewed as 80 percent of thesolution, to which the remaining 20 percent is up to each

customer to complete and tailor to their individual needs andconstraints

Here's an analogy of how to view these design

recommendations: Given a business objective (for example, tohammer a nail into a wall), you will have certain tools at yourdisposaltools that may or may not be optimally suited to thetask (let's say, a hammer and a banana) Our lab testing

presents the optimal tool to use for the given objective

(normally, a hammer tests better than a banana, but you neverknowI've seen some pretty funky frozen bananas that might dothe trick) It's still up to the customer to pick the tool that bestsuits their objectives, situations, and comfort levels These

recommendations are not mandates; they are simply

suggestions based on extensive lab testing and customer

deployments

However, it's important to remember where AutoQoS came

from AutoQoS tools are the result of QoS design guides thatCisco Technical Marketing Engineers (including myself) put

together based on large-scale lab testing AutoQoS-VoIP is theproduct of our first "AVVID QoS Design Guide," one of the mostpopular and most downloaded technical whitepapers ever

produced within Cisco AutoQoS-Enterprise is the result of theQoS Baseline coupled with our second-generation QoS DesignGuide This book represents our third-generation QoS DesignGuide And it is the goal of the authors to drive these designs(including DoS/worm-mitigation strategies) into future releases

of AutoQoS So, basically, what you are reading is the proposedblueprint for the next version of AutoQoS

When it comes to any given technology, there are really onlytwo types of people: those who are interested in the technologyand seek a thorough understanding of the relation of the parts

to the whole, and those who just want to "turn it on" and walkaway The former are the ones who will confidently unleash thetrue power of the technology and push it to its limits; the latterare the ones who are usually hesitant, timid, and conservative

in their use of the technology, typically accompanied with

mediocre results

of a Ferrari and want to know all the details about how the

engine generates its beautiful purring and power, and there areothers who want only to turn it on, drive away, and look sexy.The former group will drive more confidently, boldly unleashingthe engine's tremendous power and, thus, pushing the car to itslimits

This book is intended for the former type of QoS networkingprofessionalthose looking for a thorough understanding of what

makes them move so fast, sound so good, and look so sexy as

they confidently harness their technology

The main goal of this book is to present templates that address

80 percent or more of a customer's requirement of QoS in aparticular context and architecture (LAN, WAN, VPN)

Additionally, the rationales and considerations behind the

recommendations are explained in detail so that as tweaking isrequired, network administrators are well informed of the trade-offs involved

rich book is to incorporate inline explanations of configurations

A key approach that we've used throughout this configuration-In this way, the QoS-relevant commands are highlighted anddetailed line-by-line to illustrate the function of each elementand how these parts make up the whole solution

To complement these line-by-line design recommendations,

related verification commands are detailed These verificationcommands are presented in context with the design examples,and specific details of what to look for in the resulting outputare highlighted These verification examples are, therefore,

significantly richer in relevance than most such examples

presented in Cisco documentation, and they allow network

administrators to confirm quickly whether the recommendeddesigns have been deployed correctly

Finally, each design chapter has a case-study example at theend that ties together many of the design elements presented

in the chapter and presents a bigger-picture detailed examplefor the infrastructure architecture being discussed

(LAN/WAN/VPN) These examples are indicative of what can beexpected in production environments Often these case-studyexamples span several devices and, thus, highlight critical

interrelationships

This book is divided into three main parts: an introduction andoverview section, a QoS toolset review section, and (the heart

of the book) a QoS design section

Chapter 1 , "Introduction to QoS," is an introduction and

brief history of the development of QoS technologies,

showing where these came from and the direction they'reheaded in

Chapter 2 , "QoS Design Overview," is an overview of

QoS design It begins by detailing the service-level

requirements of voice, video, and data applications, and itpresents the Scavenger-class DoS/worm-mitigation strategyand high-level QoS best practices that will be detailed in thedesign chapters to follow

To set proper context for the design chapters, various QoS toolsare reviewed This review is not indented to serve as featuredocumentation, but it supplements Cisco documentation to

highlight various interdependancies or caveats for these toolsthat at times impact the recommended QoS designs that follow.The QoS toolset review section, Chapters 3 through 11, coversthe following topics:

Chapter 3 , "Classification and Marking Tools"This

chapter reviews Layer 2 marking mechanisms (such as

802.1Q/p, Frame Relay Discard Eligibility, ATM Cell LossPriority, and MPLS Experimental Values) and Layer 3

marking mechanisms (such as IP Precedence and

Differentiated Services Code Points)

Chapter 4 , "Policing and Shaping Tools"This chapter

Chapter 5 , "Congestion-Management Tools"This

chapter reviews the evolution of queuing mechanisms andfocuses on Low-Latency Queuing and Class-Based WeightedFair Queuing This chapter highlights the interoperation andinterdependencies of these mechanisms with other QoSmechanisms, such as link-fragmentation and shaping tools

Chapter 6 , "Congestion-Avoidance Tools"This chapter

reviews the Weighted Random Early Detection mechanismand shows how this can be used to provide DifferentiatedServices within an (RFC 2597) Assured Forwarding trafficclass This chapter also shows how this mechanism can beused to set (RFC 3168) IP Explicit Congestion Notificationbits

Chapter 8 , "Bandwidth Reservation"This chapter

reviews the Resource Reservation Protocol (RSVP) and

shows how it can be applied to admission control and MPLSTraffic Engineering

Chapter 9 , "Call Admission Control (CAC)"This chapter

reviews local, resource-based, and measurement-based calladmission control (CAC) mechanisms, including the use ofRSVP for CAC The tools reviewed in previous chapters can

voice from voice

Chapter 10 , "Catalyst QoS Tools"This chapter reviews

the main classification, marking, mapping, policing, andqueuing tools available on the current Cisco Catalyst

When the QoS toolset is reviewed, the context is set for thedetailed design recommendations that follow The next

chapterswhich comprise the heart of this bookcover the QoSdesign recommendations for protecting voice, video, and

multiple classes of data while mitigating DoS/worm attacks forthe following network infrastructure architectures:

Chapter 12 , "Campus QoS Design"This design chapter

details access, distribution, and core layer considerationsand designs for Cisco Catalyst 2950, 2970, 3550, 3560,

3570, 4500-Supervisors III-V, and Catalyst 6500 Supervisor

edge models are presented, along with detailed

2 and Supervisor 720 series switches Five separate access-queuing/dropping recommendations on a per-platform

basis Platform-unique features, such as the Catalyst 3550per-Port/per-VLAN policing feature, the Catalyst 6500 PFC2Dual-Rate Policing feature, and the PFC3 Per-User MicroflowPolicing feature, are highlighted in context

Chapter 13 , "WAN Aggregator QoS Design"This design

chapter details considerations and designs for low-speed (

768 kbps), medium-speed (> 768 kbps and T1/E1), andhigh-speed (> T1/E1) private WAN topologies, such as

leased lines, Frame Relay, ATM, ATM-to-Frame Relay serviceinterworking, and ISDN

Chapter 14 , "Branch Router QoS Design"This design

chapter details branch-specific considerations and designs,such as unidirectional applications, and branch-to-campustraffic classification through access lists and Network-BasedApplication Recognition (NBAR) Branch-specific designsinclude Cisco SAFE recommendations for using NBAR forknown worm identification and policing

Chapter 15 , "MPLS VPN QoS Design"This design chapter

details considerations and designs for both enterprises (thatare mapping into MPLS VPN service-provider [edge] classes

of service) and service providers (that are provisioning edgeand core classes of service) Service provider designs alsoinclude details on how to provision MPLS DiffServ TunnelingModes (Uniform, Short-Pipe, and Pipe) and an introduction

to MPLS Traffic Engineering (demonstrating per-customertraffic engineering and per-customer/per-application trafficengineering through MPLS DiffServ Traffic Engineering)

Chapter 16 , "IPSec VPN QoS Design"This design

chapter details the considerations and designs for deployingsite-to-site IPSec VPNs and for teleworker IPSec VPNs

(which traverse broadband media, such as cable and DSL)

Appendix , "At-a-Glance" QoS SummariesSingle-page

summaries of key QoS concepts presented throughout thisthe book for ready-reference, including

- QoS Tools

- The Cisco QoS Baseline

Chapter 1 Introduction to QoS

Chapter 2 QoS Design Overview

This chapter provides a brief history of both voice and datanetwork evolution, illustrating the background of the concept ofQuality of Service (QoS) It introduces the fundamental QoSconcepts of IntServ and DiffServ to set the stage for the laterdiscussion of individual QoS mechanisms The following topicsare introduced and briefly discussed:

a topic of concern in modern networks when it was somethingrelatively unheard of only a few years ago It is instructive toreview briefly a small amount of networking history that putsQoS technology in perspective

A century ago, the public switched telephone network (PSTN)started building out a worldwide, circuit-switched network Thisnetwork consisted of fixed-bandwidth, dedicated circuits andideally was suited to carrying real-time traffic, such as voice.Some five decades later, networking experts from military andeducational environments introduced packet-switched networks

switched networks Packet switching chops the information flowinto small chunks of data, which can be routed over

to circumvent any single points of failure, common in circuit-independent paths to the same destination, analogous to theoperation of the postal system

The resiliency of packet-switched networks caused a shift

toward connectionless communication protocols that can handlepackets that might arrive out of order However, for many dataapplications, this was not only complicated to design around,but it also was insufficient in meeting application needs Thus,connection-oriented protocols such as X.25 and Systems

Network Architecture (SNA), and later Frame Relay and

Asynchronous Transfer Mode (ATM), were developed In theseprotocols, a circuit (permanent or switched virtual circuit, PVC

switched network to handle a session of communication

or SVC) is defined over the underlying connectionless packet-between two devices or endpoints

In theory, real-time communications such as voice can use

virtual circuits regardless of the underlying networking

technology Several universities conducted many experiments tothis effect in the 1970s However, voice over virtual circuits didnot become a commercial or practical reality until the routersand switches used in packet-switched networks gained the CPUand memory power required to drive packet streams at real-time speeds at cost-effective prices

points, other issues with carrying real-time communicationsover a packet-switched network manifested themselves Forexample, when packets are delayed or dropped en route

because of buffer overflows or other momentary failures, theintelligent protocols in the seven-layer International

Organization for Standardization (ISO) model recover the

"session" through the use of error-detection and correction

capabilities, such as timeouts and retransmissions Althoughthese recovery methods work well for data applications, theyfall far short of satisfying the needs of real-time informationstreams

ATM was the first general data-networking technology to include

a class of service concept at the lower layers of communicationstransport protocolsthat is, offering different treatments for

different types of traffic (protocols such as SNA already had thisconcept at higher layers in the stack) ATM minimizes latency bydefining fixed-length cells, which can be switched in hardware.ATM also uses the familiar concepts of PVCs and SVCs to

eliminate routing delays by doing an initial connection setup,after which all other packets that belong to the stream can beforwarded to the destination without additional routing

It has been saidonly partly facetiouslythat packet switching hasbeen a 30-year failed experiment The attributes that the ATMarchitecture strived for are none other than those of the originalcircuit-switched PSTN: low latency, fixed circuit-based routing,predictable service levels, and information-order preservation.Then why not just use the PSTN? Options for transmitting dataover the voice network met with equally limited success ThePSTN simply is not optimized for data networks: The equipment

is expensive, the architecture is rigid, the bandwidth allocationsare wasteful, and the infrastructure as a whole is ill suited toapplications in which sessions are short, variable, multipoint, orconnectionless

In an effort to find a more effective solution to support a

were introduced The term integrated services (as in Integrated

Services Digital Network [ISDN] or the IETF Integrated Services[IntServ] model) refers to the mixing of different types of

switched network ISDN, which is considered by some to be thefirst foray into an architecture for converged networks, defineshow data protocols can be carried over a circuit-switched

traffic, such as voice, video, and data, over a single packet-infrastructure that natively supports voice The PSTN evolvedslightly with the introduction of ISDN However, with the

exception of a handful of countries in Europe, ISDN never reallytook off This was primarily because of nontechnical reasons,such as the pricing strategies that the providers adopted

In the late 1990s, IP won out as the technology of choice forconverged networks because of its ease of use, ubiquity, andadvances in handling real-time traffic

The key enablers for IP networks to converge successfully

voice, video, and data over packet-switched infrastructures

were QoS technologies QoS allows for the differentiated

treatment of data traffic versus voice and other delay-sensitivetraffic In other words, it allows the network to include a system

of "managed unfairness." As QoS technologies evolved,

network infrastructure and began planning toward deployingconverged networks

centered on a signaling protocol called the Resource

Reservation Protocol (RSVP) RSVP signals bandwidth and

latency requirements for each discrete session to each nodealong a path (logical circuit) that packets would take from thesending endpoint to the receiving endpoint Initially, RSVP

required every node to heed its reservations, which was highlyimpractical over the Internet, on which servers, switches, androuters of every description, vintage, and vendor coexist

To address this challenge, another set of standardsthe DiffServmodelemerged as a second attempt at standardizing QoS TheDiffServ model describes various behaviors to be adopted byeach compliant node The nodes could use whatever features(proprietary or otherwise) were available, as chosen by the

vendor, to conform Packet markings, such as IP Precedence(IPP) and its successor, Differentiated Services Code Points

(DSCPs), were defined along with specific per-hop behaviors(PHBs) for key traffic types

As the IntServ and DiffServ models have evolved, the generalpopularity of one method versus the other has swung back andforth (as shown in Figure 1-2), and their coexistence has

become an ever-increasing struggle, with committed advocates

on both sides Today the debates over the advantages of eachcontinue without a clear, industry-wide agreed-upon resolution.The realization has begun that neither method offers a completesolution and that elements of both should be combined to

provide the most general method applicable to the widest range

of traffic and application types

Figure 1-2 IntServ and DiffServ

IntServ uses a flow-based concept coupled with a signalingprotocol along the packet path The signaling protocol

guarantees that adequate resources are available (at eachhop) for the flow before admitting the flow onto the

network In initial deployments, the IntServ model sufferedfrom scalability issues because of the many flows that

needed management on network backbones

DiffServ uses packet markings to classify and treat eachpacket independently Although this scales well (which isprobably why enterprises and service providers deploy itmore frequently), it offers no specific bandwidth guarantees

to packets that belong to a flow and, therefore, fails to

provide admission control to new flows

With no clear advantage to either model, QoS mechanisms

continue to use a mix of IntServ and DiffServ technologies tooffer the breadth of services required on networks IntServ andDiffServ are discussed further in the section "QoS Models" later

in this chapter