Cisco Press End To End QoS Network Design Quality Of Service In LANs WANs And VPNs Nov 2004 ISBN 1587051761

(1)

• Table of_Contents • Index

End-to-End QoS Network Design

By Tim Szigeti - CCIE No. 9794, Christina Hattingh

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

Examine strategic QoS best practices, including Scavenger-class QoS tactics for DoS/worm mitigation

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

(2)

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

(3)

• Table of_Contents • Index

By Tim Szigeti - CCIE No. 9794, Christina Hattingh

Publisher: Cisco Press

Pub Date: November 09, 2004 ISBN: 1-58705-176-1

Acknowledgments

Icons Used in This Book

Command Syntax Conventions

(4)

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

Understanding Scheduling and Queuing

Legacy Layer 3 Queuing Mechanisms

Currently Recommended Layer 3 Queuing Mechanisms

Layer 2 Queuing Tools

DSCP-Based Weighted Random Early Detection

Explicit Congestion Notification

Summary

Copyright

Published by: Cisco Press

800 East 96th Street

Indianapolis, IN 46240 USA

mechanical, including photocopying, recording, or by any information storage and retrieval system, without written

permission from the publisher, except for the inclusion of brief quotations in a review.

Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 First Printing October 2004

Library of Congress Cataloging-in-Publication Number: 2003111984 Trademark Acknowledgments

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately

capitalized. Cisco Press or Cisco Systems, Inc., cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any

(9)

Warning and Disclaimer

This book is designed to provide information about Quality-of-Service network design best-practice recommendations. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information is provided on an "as is" basis. The authors, Cisco Press, and Cisco Systems, Inc., shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the discs or programs that may

accompany it.

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

Corporate and Government Sales

Cisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information please contact: U.S. Corporate and Government Sales 1-800-382-3419

corpsales@pearsontechgroup.com

For sales outside the U.S. please contact: International Sales

international@pearsoned.com

Feedback Information

At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional

technical community.

(10)

quality of this book or otherwise alter it to better suit your needs, you can contact us through e-mail at

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

We greatly appreciate your assistance.

Publisher John Wait

Editor-in-Chief John Kane

Cisco Representative Anthony Wolfenden

Cisco Press Program Manager Nannette M. Noble

Executive Editor Christopher Cleveland

Acquisitions Editor Michelle Grandin

Production Manager Patrick Kanouse

Development Editor Howard A. Jones

Copy Editor Krista Hansing

Technical Editors Frank Knox

Anna To

Connie Varner

Team Coordinator Tammi Barnett

Cover Designer Louisa Adair

(11)

Indexer Eric Schroeder

Proofreader Tonya Cupp

Corporate Headquarters Cisco Systems, Inc.

170 West Tasman Drive San Jose, CA 95134-1706 USA

www.cisco.com

Tel: 408 526-4000

800 553-NETS (6387) Fax: 408 526-4100

European Headquarters

Cisco Systems International BV Haarlerbergpark

Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands

www-europe.cisco.com

Tel: 31 0 20 357 1000 Fax: 31 0 20 357 1100 Americas Headquarters Cisco Systems, Inc.

(12)

www.cisco.com

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the Cisco.com Web site at

www.cisco.com/go/offices.

Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica • Croatia • Czech Republic • Denmark • Dubai, UAE • Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea •

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 •

Zimbabwe

(13)

Fastest Way to Increase Your Internet Quotient, and iQuick 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, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PK, Post-Routing, Pre-Routing, RateMUX, Registrar SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0303R)

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 are actually reading this, they probably think I'm only jokingbut, alas, the Greek capacity for vengeance is no laughing matter. I cancelled far too many dates, stayed in my office and labs far too many weekends, and stared blankly into space (thinking about 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.

(14)

the rest). But, for whatever it's worth, I'm dedicating it to you, Lella. I love you with all my heart.

(15)

About the Authors

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 soon after began to specialize in Quality-of-Service technologies, supporting technical marketing initiatives for the Cisco Class Data 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 joined the Enterprise Solutions Engineering team and led large-scale testing initiatives of campus, WAN, and VPN QoS designs. Tim now belongs to the newly formed Technology Solutions

Engineering team within the Cisco Central Technical Marketing organization. There, he continues to define and drive strategic QoS solutions across Cisco technology groups and business units while working with many Fortune 500 companiesboth

(16)

About the Technical Editors

Frank Knox has more than 37 years of telecommunications experience. During his career at IBM, Frank held positions in field service, field support, service planning, and education; his final 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 GTE Directories, where he was responsible for the company's voice and data network design and support. Concurrent with his work at IBM and GTE, Frank taught as an adjunct professor for the University of Dallas MBA program. For the past six years, Frank has 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 Pace University.

Anna To has worked with Cisco for more than three years as a software/deployment engineer on the ITD QoS team. One of Anna's key tasks is to promote QoS deployment and increase the understanding of QoS technology in the field. Anna works on the Modular QoS CLI (MQC) solution team to bring

consistency in QoS configuration across various Cisco platforms. In addition, Anna is involved with the AutoQoS project to

simplify QoS deployment.

Connie Varner is a technical marketing engineer in the Cisco Enterprise Systems Engineering group. She has extensive

experience designing and testing large-scale networks based on customer requirements, in part based on four years of

(17)

Acknowledgments

Off the top, I'd like to thank my friend and co-worker Dave Barton, whoalthough he was extremely busy downing beers at Chicago's Navy Piergallantly managed to sic Brett Bartow onto me, which got the ball rolling on this whole project. (Dave, did you make it back okay to the hotel that night?)

Many thanks to Todd Truitt, one of the top talents at Cisco, for inviting my collaboration on the original AVVID QoS Design Guide, hiring me onto his design team, and recommending Christina as a co-author for this project. Do you ever get tired of being right, Todd?

Thanks also to Neil Anderson, Joel King, Ted Hannock, and

Steve Ochmanski for guidance and collaboration on IPSec V3PN designs. Thanks for letting me leverage your excellent and

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 for DoS/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-scale MPLS VPN testbeds for me and continually tweaking them to suit my mood-of-the-day. I don't know where your patience or your good nature comes from, but they're most appreciated. Thanks, too, for nudging me back into playing ice hockey. Next time I break a leg or chip a tooth, I'll think of you and grimace.

(18)

I'm afraid to ask where you sourced the gear you did. (I'm not sure whether those 10GE linecards "fell off the back of a Cisco truck" or what, but they sure came in handy at just the right time.)

A round of applause is merited by the technical reviewers. Having done this before myself, I can genuinely appreciate the time, effort, and painstaking attention to detail that goes into this process. Frank, your comments were right on and helped make this a better book. Anna, is there anything you don't know about Cisco QoS? I'm very thankful you took time out of your extremely busy schedule, developing code while helping anyone and everyone on planet Earth (and some nearby

systems) that are having QoS problems. And Connie, if you hadn't reviewed this work, I would not have submitted it for publication. You're simply the best technical reviewerand one of the sharpest engineersI've ever had the pleasure of working with.

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 managing the production of this publication and allowing me to make hundreds of last-minute edits in the galley-review phase (when edits are to be kept at a minimum). How you put up with me I'll never know, but I truly appreciate your patience and desire to help make this book as correct and as current as possible. Also thank you Chris Cleveland for your fine recommendations and guidance during the course of production.

(19)

Brett Bartow, what can I say? This would never have happened without you. Time and time again, it seemed to fall by the

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 I read your first draft of your first chapter, I knew you were the best person to embark on this project with (even though you write like an engineer!). Thank you for sacrificing so many

(20)

(21)

Command Syntax Conventions

The conventions used to present command syntax in this book are 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 examples and output (not general command syntax), boldface

indicates commands that are input manually by the user (such as a show command).

Italics indicates arguments for which you supply actual values.

Vertical bars (|) separate alternative, mutually exclusive elements.

Square brackets [ ] indicate optional elements. Braces { } indicate a required choice.

(22)

Introduction

QoS is a maturing technology, one that many networking

professionals, to a greater or lesser extent, are already familiar with. 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, and data onto a single IP network, among other business

advantages. It is a curse because almost every individual with whom I've ever discussed QoS designs has a slightly different opinion on how QoS should be enabled.

The result often has led to confusing babble from the

customer's perspective, especially for customers seeking QoS design 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, the customer might attend an Executive Briefing session in San Jose and receive a different answer (even receiving multiple different 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, despite the touted benefits that they were sold on. Therefore, in my opinion, presenting such inconsistent recommendations is a major disservice to our customers and a considerable barrier to the widespread deployment of QoS.

The Cisco Technology Baseline committees were created to

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

(23)

RFCs and other standards) to which all Cisco products and features must conform. Additionally, these documents provide uniform, strategic recommendations (that can be shared with customers) to help ensure that QoS recommendations are unified and consistent, for both enterprises and service

providers. Specific to QoS, the QoS Baseline strictly defines the Cisco strategic direction in QoS technologies from now into the foreseeable future.

Thus, a unique feature of this book is that it is the first Cisco Press publication to present design recommendations that are compliant with the QoS Baseline.

Another huge advantage of this publication is that it is one of the first documents to present a detailed, cohesive strategy that shows 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 such attacks. This is a fresh perspective and context for a technology that many considered baked and done. Yet in such a role, the critical interdependency of Quality of Service, High-Availability, and Security technologies becomes manifest and holistically promotes the "Self-Defending Networks" business objective. However, having a strategic direction and tactical approaches for QoS designs is only half the solution. An important motto that I like to emphasize is: "In theory, theory and practice are the same." It's one thing to make a design recommendation based on an assumption that something "should work." It's something completely different to make a design

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

Triangle Park, North Carolina.

(24)

done to present working, tested configurationsincluding a rigorous technical reviewing process by some of the sharpest Cisco QoS engineershardware/software/platform-specific issues that didn't surface during our tests may nonetheless exist, as may issues introduced in newer releases of hardware/software dating from our time of testing.

Furthermore, the recommendations presented in this book are not to be taken as commandments or dictates ("Thou shalt configure this or that"), but are simply best-practice design recommendations that are the result of extensive lab testing and customer deployments. They should be viewed as

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

customer to complete and tailor to their individual needs and constraints.

Here's an analogy of how to view these design

recommendations: Given a business objective (for example, to hammer a nail into a wall), you will have certain tools at your disposaltools that may or may not be optimally suited to the task (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 never knowI've seen some pretty funky frozen bananas that might do the trick). It's still up to the customer to pick the tool that best suits their objectives, situations, and comfort levels. These recommendations are not mandates; they are simply

(25)

Who Should Read This Book?

Some might ask, "Why should I read this book? Especially when I have AutoQoS?"

Certainly, AutoQoS-VoIP is an excellent tool for customers

whose objective is enabling QoS for VoIP (only) on their campus and WAN infrastructures, and AutoQoS-Enterprise is a fine tool for enabling basic WAN-edge QoS for voice, video, and multiple classes of data. For customers who have basic QoS needs and don't have the time or desire to learn or do more with QoS, AutoQoS is definitely the way to go.

However, it's important to remember where AutoQoS came from. AutoQoS tools are the result of QoS design guides that Cisco Technical Marketing Engineers (including myself) put together based on large-scale lab testing. AutoQoS-VoIP is the product of our first "AVVID QoS Design Guide," one of the most popular and most downloaded technical whitepapers ever

produced within Cisco. AutoQoS-Enterprise is the result of the QoS Baseline coupled with our second-generation QoS Design Guide. This book represents our third-generation QoS Design Guide. 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 proposed blueprint for the next version of AutoQoS.

When it comes to any given technology, there are really only two types of people: those who are interested in the technology and seek a thorough understanding of the relation of the parts to the whole, and those who just want to "turn it on" and walk away. The former are the ones who will confidently unleash the true power of the technology and push it to its limits; the latter are the ones who are usually hesitant, timid, and conservative in their use of the technology, typically accompanied with

(26)

For example, there are those who enjoy looking under the hood of a Ferrari and want to know all the details about how the

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

(27)

Goals and Methods

The main goal of this book is to present templates that address 80 percent or more of a customer's requirement of QoS in a particular context and architecture (LAN, WAN, VPN).

Additionally, the rationales and considerations behind the

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

A key approach that we've used throughout this configuration-rich book is to incorporate inline explanations of configurations. In this way, the QoS-relevant commands are highlighted and detailed line-by-line to illustrate the function of each element and how these parts make up the whole solution.

To complement these line-by-line design recommendations, related verification commands are detailed. These verification commands are presented in context with the design examples, and specific details of what to look for in the resulting output are 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 recommended designs have been deployed correctly.

Finally, each design chapter has a case-study example at the end that ties together many of the design elements presented in the chapter and presents a bigger-picture detailed example for the infrastructure architecture being discussed

(28)

How This Book Is Organized

This book is divided into three main parts: an introduction and overview 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're headed 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 it presents the Scavenger-class DoS/worm-mitigation strategy and high-level QoS best practices that will be detailed in the design chapters to follow.

To set proper context for the design chapters, various QoS tools are reviewed. This review is not indented to serve as feature documentation, but it supplements Cisco documentation to highlight various interdependancies or caveats for these tools that at times impact the recommended QoS designs that follow. The QoS toolset review section, Chapters 3 through 11, covers the 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 Loss Priority, and MPLS Experimental Values) and Layer 3 marking mechanisms (such as IP Precedence and Differentiated Services Code Points).

(29)

reviews the token bucket algorithm, which is the basis for most policers and shapers. Both two-rate and three-rate policers are covered as are ATM and Frame Relay traffic shaping.

Chapter 5, "Congestion-Management Tools"This

chapter reviews the evolution of queuing mechanisms and focuses on Low-Latency Queuing and Class-Based Weighted Fair Queuing. This chapter highlights the interoperation and interdependencies of these mechanisms with other QoS mechanisms, such as link-fragmentation and shaping tools.

Chapter 6, "Congestion-Avoidance Tools"This chapter reviews the Weighted Random Early Detection mechanism and shows how this can be used to provide Differentiated Services within an (RFC 2597) Assured Forwarding traffic class. This chapter also shows how this mechanism can be used to set (RFC 3168) IP Explicit Congestion Notification bits.

Chapter 7, "Link-Specific Tools"This chapter reviews header-compression techniques (such as TCP and RTP header compression) and link-fragmentation and

interleaving techniques (such as Multilink PPP Link

Fragmentation and Interleaving [MLP LFI] and Frame Relay fragmentation [FRF.12]).

Chapter 8, "Bandwidth Reservation"This chapter reviews the Resource Reservation Protocol (RSVP) and

shows how it can be applied to admission control and MPLS Traffic Engineering.

(30)

protect voice from data, but only CAC tools can protect voice from voice.

Chapter 10, "Catalyst QoS Tools"This chapter reviews the main classification, marking, mapping, policing, and queuing tools available on the current Cisco Catalyst

platforms (including the Catalyst 2950, 2970, 3550, 3560, 3570, 4500-Supervisors II+ to V, and Catalyst 6500

Supervisor 2 and Supervisor 720).

Chapter 11, "WLAN QoS Tools"This chapter reviews QoS mechanisms available for wireless access points, including the 802.11e Enhanced Distributed Coordination Function (EDCF) and the QoS Basic Service Set (QBSS).

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

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

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

Chapter 12, "Campus QoS Design"This design chapter details access, distribution, and core layer considerations and designs for Cisco Catalyst 2950, 2970, 3550, 3560, 3570, 4500-Supervisors III-V, and Catalyst 6500 Supervisor 2 and Supervisor 720 series switches. Five separate access-edge models are presented, along with detailed

queuing/dropping recommendations on a per-platform basis. Platform-unique features, such as the Catalyst 3550 per-Port/per-VLAN policing feature, the Catalyst 6500 PFC2 Dual-Rate Policing feature, and the PFC3 Per-User Microflow Policing feature, are highlighted in context.

(31)

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

leased lines, Frame Relay, ATM, ATM-to-Frame Relay service interworking, and ISDN.

Chapter 14, "Branch Router QoS Design"This design chapter details branch-specific considerations and designs, such as unidirectional applications, and branch-to-campus traffic classification through access lists and Network-Based Application Recognition (NBAR). Branch-specific designs include Cisco SAFE recommendations for using NBAR for known worm identification and policing.

Chapter 15, "MPLS VPN QoS Design"This design chapter details considerations and designs for both enterprises (that are mapping into MPLS VPN service-provider [edge] classes of service) and service providers (that are provisioning edge and core classes of service). Service provider designs also include details on how to provision MPLS DiffServ Tunneling Modes (Uniform, Short-Pipe, and Pipe) and an introduction to MPLS Traffic Engineering (demonstrating per-customer traffic engineering and per-customer/per-application traffic engineering through MPLS DiffServ Traffic Engineering).

Chapter 16, "IPSec VPN QoS Design"This design

chapter details the considerations and designs for deploying site-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 this the book for ready-reference, including

- QoS Tools

(32)

- QoS Best Practices

- Scavenger-Class QoS Design - Campus QoS Design

- WAN QoS Design - Branch QoS Design

- MPLS VPN QoS Design (for Enterprise Subscribers) - MPLS VPN QoS Design (for Service-Providers)

(33)

Part I: Introduction to QoS

Part I of this book provides a brief background of the evolution of QoS technologies and overviews various currently available QoS features and tools. The QoS

requirements of voice, 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 design principles are introduced to show how QoS mechanisms can be strategically deployed to address application requirements while mitigating such attacks. The chapters in this part of the book are as follows:

Chapter 1 Introduction to QoS

(34)

Chapter 1. Introduction to QoS

This chapter provides a brief history of both voice and data network evolution, illustrating the background of the concept of Quality of Service (QoS). It introduces the fundamental QoS concepts of IntServ and DiffServ to set the stage for the later discussion of individual QoS mechanisms. The following topics are introduced and briefly discussed:

IntServ and DiffServ QoS tools categories Modular QoS CLI QoS Baseline QoS classes Automatic QoS

(35)

A Brief Historical Perspective

A century ago, the public switched telephone network (PSTN) started building out a worldwide, circuit-switched network. This network consisted of fixed-bandwidth, dedicated circuits and ideally was suited to carrying real-time traffic, such as voice. Some five decades later, networking experts from military and educational environments introduced packet-switched networks to circumvent any single points of failure, common in circuit-switched networks. Packet switching chops the information flow into small chunks of data, which can be routed over

independent paths to the same destination, analogous to the operation of the postal system.

The resiliency of packet-switched networks caused a shift

toward connectionless communication protocols that can handle packets that might arrive out of order. However, for many data applications, 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 these protocols, a circuit (permanent or switched virtual circuit, PVC or SVC) is defined over the underlying connectionless packet-switched network to handle a session of communication

between two devices or endpoints.

In theory, real-time communications such as voice can use virtual circuits regardless of the underlying networking

(36)

When processing power became available at affordable cost points, other issues with carrying real-time communications over a packet-switched network manifested themselves. For example, when packets are delayed or dropped en route because of buffer overflows or other momentary failures, the intelligent 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. Although these recovery methods work well for data applications, they fall far short of satisfying the needs of real-time information streams.

ATM was the first general data-networking technology to include a class of service concept at the lower layers of communications transport protocolsthat is, offering different treatments for

different types of traffic (protocols such as SNA already had this concept at higher layers in the stack). ATM minimizes latency by defining 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 be forwarded to the destination without additional routing.

It has been saidonly partly facetiouslythat packet switching has been a 30-year failed experiment. The attributes that the ATM architecture strived for are none other than those of the original circuit-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 data over the voice network met with equally limited success. The PSTN simply is not optimized for data networks: The equipment is expensive, the architecture is rigid, the bandwidth allocations are wasteful, and the infrastructure as a whole is ill suited to applications in which sessions are short, variable, multipoint, or connectionless.

(37)

combination of voice and data, integrated services offerings 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

traffic, such as voice, video, and data, over a single packet-switched network. ISDN, which is considered by some to be the first foray into an architecture for converged networks, defines how data protocols can be carried over a circuit-switched

infrastructure that natively supports voice. The PSTN evolved slightly with the introduction of ISDN. However, with the

exception of a handful of countries in Europe, ISDN never really took 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 for converged networks because of its ease of use, ubiquity, and advances 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-sensitive traffic. In other words, it allows the network to include a system of "managed unfairness." As QoS technologies evolved,

(38)

QoS Evolution

IP networks of the mid-1990s were invariably best-effort networks, and the Internet, as a whole, remains so today. Privately owned enterprise and service provider networks,

though, have been widely transformed from best-effort models to more complex differentiated services models, meaning that the network gives different applications differing levels of

service.

Figure 1-1 shows the broad steps in the evolution of QoS concepts since the early 1990s.

Figure 1-1. QoS Evolution

(39)

RFCsstarting with RFC 1633 in June 1994). These RFCs centered on a signaling protocol called the Resource

Reservation Protocol (RSVP). RSVP signals bandwidth and latency requirements for each discrete session to each node along a path (logical circuit) that packets would take from the sending endpoint to the receiving endpoint. Initially, RSVP required every node to heed its reservations, which was highly impractical over the Internet, on which servers, switches, and routers of every description, vintage, and vendor coexist.

To address this challenge, another set of standardsthe DiffServ modelemerged as a second attempt at standardizing QoS. The DiffServ model describes various behaviors to be adopted by each 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 general popularity of one method versus the other has swung back and forth (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 each continue without a clear, industry-wide agreed-upon resolution. The realization has begun that neither method offers a complete solution and that elements of both should be combined to

provide the most general method applicable to the widest range of traffic and application types.

(40)

A short definition of IntServ and DiffServ follows:

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

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

network. In initial deployments, the IntServ model suffered from scalability issues because of the many flows that

needed management on network backbones.

DiffServ uses packet markings to classify and treat each packet independently. Although this scales well (which is probably why enterprises and service providers deploy it more frequently), it offers no specific bandwidth guarantees to packets that belong to a flow and, therefore, fails to

provide admission control to new flows.

(41)

In the late 1990s, QoS techniques became more sophisticated and were adapted to advanced networking technologies, such as Multiprotocol Label Switching (MPLS) and Virtual Private Networks (VPNs).

The most recent trend in QoS is simplification and automation, with the goal of simply and efficiently provisioning "intelligent" QoS on IP networks. When viewed as individual features, QoS technologies offer a myriad of "nerd knobs" that can be turned. In the hands of capable administrators, these can be used to build very sophisticated networks. However, they also can result in very complex configurations. Many administrators do not

(42)

User Network Expectations

The perception of how the network behaves, or how well it behaves, depends on how you look at it. End users, or

consumers, of the network might have a very different view of network quality of service than the staff managing the network.

End User

An end user's perception of QoS is typically subjective and relative, and not easily measurable.

End users perceive the network quality through their end device and have certain expectations of appropriate service levels. For example, typical users expect a voice call on a standard phone to be of toll quality. Yet they do not expect that same quality level from a cell phone or a voice call spoken into a microphone on a personal computer. This is the general expectation,

regardless of the fact that all three calls might be carried by the same network in the same manner.

The end user has no concept of and typically very little interest in the capabilities of the networks in betweenunless, of course, the quality of the network response is lacking. Therefore, end users' perception of the quality of the service that they receive is based on previously observed behavior on similar devices (examples include a PSTN phone call, a PBX phone call, a bank teller application, and the refresh of a web page display) and the cost of the service (which, in an enterprise network, the general end user perceives as $0).

(43)

IT management perceives the network quality through

management statistics such as throughput, usage, percentage of loss, and user complaints. Expectations and "quality

problems" from an IT perspective tend to be more absolute and measurable. (For example, the one-way latency of more than 150 ms is unacceptable for a voice call, or a transaction refresh time for a bank teller application must be fewer than 5

seconds.)

Service providers formalize these expectations within service-level agreements (SLAs), which clearly state the acceptable bounds of network performance. Corporate enterprise networks typically do not have such formal SLAs, but they nevertheless manage their networks on some form of measurement and monitoring. Some enterprise networks indeed might use SLAs of various levels of formality between the IT department and the customer departments that they serve.

User complaints might result even though the network met the SLA (formal or otherwise). For example, the packet loss

(44)

Understanding QoS

Appreciating what QoS tools and methods do to packets in a network is fundamental to appreciating the effect of individual QoS tools discussed in later chapters, and ultimately

understanding the network designs and methods that constitute the material in this book.

End-to-End QoS

Regardless of how it is measured, QoS is a vital element in any converged network. To ensure the highest level of quality,

however, QoS must be implemented across all areas of the network.

QoS is described aptly by an age-old cliché: It's only as strong as the weakest link. Optimally, every device (host, server,

switch, or router) that handles the packet along its network path should employ QoS to ensure that the packet is not unduly delayed or lost between the endpoints. It is a popular myth that QoS is applicable only to slow-speed wide-area networks

(WANs) or the Internet. Testing has shown that delay-sensitive applications, such as voice, suffer quality loss when QoS is not enabled on campus devices, such as Cisco IP phones and Cisco Catalyst switches.

Figure 1-3 shows the segments of the network where QoS must be deployed in the typical IP telephony enterprise network and what QoS techniques are common in each segment.

(45)

[View full size image]

All Packets Are (Not) Equal

Networks without QoS enabled are described as best-effort

networks. Best-effort network designs treat all packets as equally important. Such networks work well if there is enough CPU, memory, and bandwidth to handle immediately all the packets traversing the network as they arrive (in other words, at line rate). However, because this is rarely the case, the following scenarios tend to emerge:

User-based contention occurs when packets from different users, user groups, departments, or even enterprises

contend for the same network resources.

Application-based contention occurs when different

(46)

network, as illustrated in Figure 1-4.

Figure 1-4. Application-Based Contention

To obtain the appropriate levels of service from often scarce network resources experiencing contention, the fundamental concept of QoS must be appliednamely, that all packets are not equal. In other words, to resolve the contention, packets must be treated with managed unfairness (either preferentially or deferentially). In other words, administrative policies must be defined and deployed throughout the network infrastructure to ensure that each node makes consistent decisions about the relative importance of an individual packet (or flow) and adjusts its packet-handling behavior accordingly.

This concept of unfairness applies equally to traffic for which higher levels of priority must be maintained (for example, to voice and video traffic) and traffic that is undesirable in the network (denial-of-service [DoS] or worm-generated traffic, or even general web surfing to destinations unrelated to the goals of the enterprise). The latter category of traffic introduces the concept of less than best-effort service, also referred to as

(47)

service to unwanted traffic. Such Scavenger traffic, if not dropped outright, is carried only when spare capacity is available.

The Challenges of Converged Networks

The high-level goal of QoS technologies in a converged network is to abstract the fact that there is only one network and to

make voice, video, and data convergence appear transparent to the end users. To achieve this goal, QoS technologies allow

different types of traffic to contend inequitably for network resources. Real-time applications, such as voice or interactive video, can be given priority or preferential services over generic data applicationsbut not to the point that data applications are starving for bandwidth.

QoS is defined as the measure of a system's service availability and transmission quality. Service availability is a crucial

foundation element of QoS. Before any QoS can be

implemented successfully, the network infrastructure should be designed to be highly available. The target for high availability is 99.999 percent uptime, with only 5 minutes of downtime permitted per year. The transmission quality of the network is determined by the following factors:

Packet loss This is a comparative measure of the number of packets faithfully transmitted and received to the total number transmitted, expressed as a percentage. Packet loss in the context of QoS does not relate to drops because of network outages or link flaps (because these are a function of a high-availability network design), but instead relates to drops because of network congestion.

(48)

transmitted from the sending endpoint. In the case of voice, this equates to the amount of time that it takes for speech to leave the speaker's mouth and be heard by the listener's ear. This time period is termed end-to-end delay and is comprised of two components: fixed network delay and variable network delay.

In data networks carrying voice, fixed network delay further is broken down into the following:

- Packetization delay The time required to sample and encode voice or video signals into packets.

- Serialization delay The time required to transmit the packet bits onto the physical media, based on the

clocking rate of the interface.

- Propagation delay The time required for the

electrical/optical pulses to traverse the media en route to their destination, based on the laws of physics.

Delay variation (or jitter) Also known as interpacket

delay, this is the difference in the end-to-end delay between sequential packets. For example, if one packet requires 100 ms to traverse the network from the source endpoint to the destination endpoint, and the following packet requires 125 ms to make the same trip, the delay variation would be calculated as 25 ms, as illustrated in Figure 1-5.

(49)

Each end station in a VoIP or video over IP conversation has a jitter buffer, which is used to smooth out the variation in arrival times of data packets that contain voice. Jitter buffers can be fixed or adaptive.

Instantaneous changes in arrival times of packets that exceed the jitter buffer's capability to compensate result in jitter buffer overruns and underruns.

- A jitter buffer underrun occurs when the arrival times of packets increase to the point that the jitter buffer has been exhausted and contains no packets for the digital signal processors (DSP) to process when it is time to play the next piece of voice or video, resulting in clips.

- A jitter buffer overrun occurs when packets containing voice or video arrive faster than the jitter buffer can accommodate. When this happens, packets are dropped when it is time to play the voice or video samples, resulting in degraded voice quality.

(50)

(51)

QoS Models

As briefly introduced earlier, there are two models for providing the differentiated levels of network service required in

converged networks: IntServ and DiffServ.

IntServ Overview

Think of best-effort IP service in terms of the regular mail

(snail-mail) service. The mail is delivered if and when it can be, but it also might be lost (arriving at some undetermined time in the future or not at all). By comparison, IntServ is analogous to a custom mail service, such as diplomatic mail or courier

services, with certain parameters regarding loss and delivery guaranteed.

More specifically, IntServ is a specification of the following: What the sender is sending (rate, maximum transmission unit [MTU], and so on), as described by the Transmission Specification (TSpec)

What the receiver needs (bandwidth, MTU, and so on), as described by the Receiver Specification (RSpec)

How the signaling is performed on the network by the sender and receiver (that is, the use of RSVP)

The framework of IntServ preserves the end-to-end semantics of QoS for IP. Key endpoints are the sender and receiver

(52)

IntServ describes three main classes of service that an application can request:

Guaranteed services (RFC 2212) Provides firm

(mathematically provable) bounds on end-to-end packet-queuing delays, making it possible to provide a service that guarantees both delay and bandwidth

Controlled load (RFC 2211) Provides the application flow with a quality of service closely approximating the QoS that the same flow would receive from an unloaded network element, but uses capacity (admission) control to ensure that this service is received even when the network element is overloaded

Best-effort service Provides no service guarantees of any type

The advantages of the IntServ model include the following: Conceptual simplicity, facilitating the integration with network policy administration

Discrete per-flow QoS, making it architecturally suitable to voice calls

Call admission control (CAC) capabilities, which can indicate to endpoints whether the desired bandwidth is available The disadvantages of the IntServ model include these:

(53)

Periodic refresh messages are used, which might require protection from packet loss to keep the session(s) intact. All intermediate nodes must implement RSVP.

DiffServ Overview

Continuing the analogy of mail services, DiffServ can be compared to different tiers of mail service, such as regular, registered, priority, and express mail. Each service offers particular parameters of delivery, and the piece of mail is stamped at each intermediate handling point to ensure that it gets the required service. However, there is no specific

connection between the sender of the piece of mail and the treatment that the mail receives.

The premise of DiffServ is very simple: It offers different network service levels to a packet, thereby "enable[ing]

scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop" (RFC 2474).

Packets of a particular service belong to a particular "class," and the treatment of each "class" is described by PHBs with which the network node must comply. Meaningful services can be constructed by a combination of the following:

Setting a field in the IP header upon network entry or at a network boundary (IPP or DSCPs)

Using this field to determine the nodes inside the network forward the packets

(54)

The essence of DiffServ is the specification of PHBs that an application can receive from the network:

Expedited forwarding (RFC 3246, previously RFC 2598) Provides a strict-priority service (compare this to express mail service)

Assured forwarding (RFC 2597) Provides a qualified delivery guarantee (compare this to registered mail service) and makes the provision for oversubscription to this service (specifically, markdown and dropping schemes for excess traffic)

Class selectors (RFC 2474) Provides code points that can be used for backward compatibility with IP Precedence

models

Best-effort service Provides a "delivery when possible" service (compare this to regular mail service)

DiffServ constructs services from the PHBs by classifying

packets into "classes" at the edge, or boundary, of the network and marking the packets accordingly. Optionally, the packets can be metered with policing or shaping techniques. The core of the network implements the PHBs and uses the packet

markings to make queuing and dropping decisions. The DiffServ model include these advantages:

Scalability No state or flow information is required to be maintained.

(55)

value of a fixed field in the packet header, reducing processing requirements.

Interoperability All vendors already are running IP. Flexibility The DiffServ model does not prescribe any particular feature (such as a queuing technique) to be implemented by a network node. The node can use

whatever features optimize its hardware and architecture, as long as it is consistent with the behavior expectation defined in the PHBs.

The disadvantages of the DiffServ model include the following: No end-to-end bandwidth reservations are present;

therefore, guarantees of services can be impaired by network nodes that do not implement the PHBs

appropriately over congested links or by nodes that are not engineered correctly for the expected traffic volume of a specific class.

(56)

Introduction to the QoS Toolset

A fair amount of literature exists on QoS concepts,

technologies, and features. The purpose of this book is not to reiterate in depth how these tools work, but rather to show how these tools interact with each other and what combination of tools can be used to achieve the overall design objectives of a network. However, to lay the context for the designs set forth in this book, a brief overview of the toolset follows.

Generally, QoS tools fall into the following categories: Classification and marking tools

Policing and shaping tools

Congestion-avoidance (selective dropping) tools Congestion-management (queuing) tools

Link-specific tools

Figure 1-6 illustrates the relationship and overall cohesiveness of different QoS tools.

Figure 1-6. QoS Toolset

(57)

Packets or frames entering a network device must be analyzed to determine the treatment that they should be given. This analysis is referred to as classification. Classification is the first QoS function to occur for any given QoS policy, and it can occur repeatedly at various stages of policy enforcement. To reduce the requirement for detailed recursive classification, it generally is recommended that traffic types be classified as close to their sources as possible and that their packets be marked

accordingly.

Marking establishes a distinct trust boundary that demarcates the point where the packet markings are set properly and,

therefore, detailed classification (Layer 4 through 7 analysis) no longer is required.

When packets enter a network device, three generic marking possibilities exist:

Packets are unmarked.

(58)

Packets are marked and the markings are trusted.

In the first two scenarios, it is recommended that the packets be marked or re-marked.

After marking, the next step is another classification process based on packet markings. At this point, packets might be

discarded by a policer (for example, if they exceed an SLA) or a congestion-avoidance mechanism (for example, early dropping because buffers reached the maximum limit). Packets that are not discarded are subject to congestion management (queuing) to prioritize and protect various traffic types when congestion happens to the transmission link. Finally, these packets are scheduled for transmission on the egress link, where shaping might occur to control bursts and ensure that outgoing traffic conforms to any SLA that is in effect on the ingress of the next hop.

Link-specific tools usually are required only at WAN edges and include mechanisms for compression or fragmentation to reduce delay and jitter.

Some QoS tools (such as marking and policing) can be applied in both the ingress and egress directions of the traffic flow on an interface. Other tools (such as queuing) can be applied only in the egress direction (with some platform-specific exceptions). The QoS mechanisms (primarily DiffServ) described previously are applicable to packets already admitted to the network. Such tools are very effective in protecting real-time (voice) from non-real-time (data) traffic, but they are completely ineffective in protecting real-time applications from other real-time

applications (that is, protecting voice traffic from other voice traffic). Such protection can be achieved only through call

(59)

(60)

Simplifying QoS

In the late 1990s, Cisco spent significant development effort to implement an extensive QoS tool and feature set. The portfolio of QoS mechanisms and options became very rich and,

simultaneously, very complicated to deploy. During the early 2000s, the predominant customer feedback relating to QoS was the request to simplify QoS deployment. In response to this feedback, a series of QoS simplification and automation projects was initiated. The result included the following:

The creation of a Modular QoS Command-Line Interface (CLI)

The establishment of a QoS Baseline

Default behavior (conforming to the QoS Baseline) Cross-platform feature consistency

Automatic QoS (AutoQoS)

Modular QoS Command-Line Interface

The first step toward simplification was to modularize the configuration of QoS and make it consistent across platforms. To this end, a new configuration syntax, termed Modular QoS Command-Line Interface (MQC), was introduced in Cisco IOS Release 12.0(5)T.

(61)

class-map A classification filter defined within the policy map to identify traffic for preferential or deferential

treatment. Traffic can be identified by IPP or DSCP, named or numbered access control lists (ACLs), Network-Based Application Recognition (NBAR), Layer 2 parameters (CoS, FR DE, ATM cell loss priority [CLP], MPLS Experimental [EXP] value), or a combination of these.

policy-map A statement that defines how each traffic type, as identified by the class map(s), should be serviced.

Options include marking/re-marking, policing, shaping, low-latency or class-based weighted fair queuing, selective

dropping, and header compression.

service-policy A statement that binds the policy to an interface and specifies direction.

Example 1-1 demonstrates a sample MQC policy. This is just an example of a possible configuration; the significance of the commands used in this example is explained in subsequent chapters.

Example 1-1. MQC Policy

Router(config)# class-map match-any CRITICAL-DATA

Router(config-cmap)# match protocol http url "*customer*" Router(config-cmap)# match protocol citrix

Router(config)# policy-map WAN-EDGE

Router(config-pmap)# class CRITICAL-DATA Router(config-pmap-c)# bandwidth 1000 Router(config)# interface Serial 0/0

(62)

QoS Baseline

Although MQC was a major step in simplifying QoS features, it addressed only the user interface element of QoS deployment. Another factor in the complexity of QoS deployment is the

inconsistency of QoS features across specific hardware platform releases or software releases.

In 2002, a series of internal Cisco initiatives, dubbed Technology Baselines, was launched to address the

inconsistency of which features exist on which platforms. Specific to QoS, the QoS Baseline is a strategic internal

document written by Cisco's most qualified QoS experts, each of whom had contributed to multiple QoS RFCs and so was best qualified to interpret these standards in additional detail. The QoS Baseline was developed with two primary goals:

To document which QoS features are required on platforms that are considered QoS-enabled products

To provide a gap analysis of which features, deemed important by the baseline, existed on what platforms In part, the Cisco QoS Baseline is aimed at producing higher-quality new products, predictable QoS feature sets across products, and improved consistency of QoS features across platforms. To that end, it provides engineers who are

developing new products with a reference list of QoS features that they must include and test. For existing platforms, it

provides a gap analysis that is used to steer product roadmaps to achieve QoS baseline compliance.

(63)

concept of traffic classification inevitably begs the question of how many classes of traffic there should be. MQC supports up to 256 different traffic classes within a policy map. Although adept QoS administrators might see this as desirable, those who are new to QoS and have no idea how many classes of traffic they need in their networks might view it as daunting. To address the needs of the both expert and casual QoS users, the QoS Baseline defines a set of class template

recommendations that can be either be implemented "as is" or customized to individual needs. It gives a starting point for network design and implementation, and it provides a basis for comparable product testing and performance reportingboth of which significantly simplify the implementation of QoS in a network.

The QoS Baseline defines up to 11 classes of traffic that are used in all Cisco design guides, configuration examples, and testing suites. The QoS Baseline does not dictate that every enterprise deploy all these traffic classes immediately. The set of 11 classes is designed to accommodate the QoS needs of an enterprise not only for today, but also for the foreseeable

future. Even if an enterprise needs only a handful of these 11 classes today, following the QoS Baseline recommendations will enable it to smoothly implement additional traffic classes in the future.

Table 1-1 gives a summary of the QoS Baseline recommendations.

Table 1-1. QoS Baseline Recommendations

PHB DSCP DSCPBinary

Value Reference

Intended

Protocols Configuration

EF EF 101110 RFC 3246 Interactive voice Admission control = RSVP

(64)

AF1 AF11

RFC 2597 Bulk transfers, web,

general data service Queuing = ratebased Active queue

and associated voiceAdmission control =RSVP Queuing = rate based

Active queue management = DSCP-based WRED

IP routing Class 6 110000 RFC 2474 section 4.2.2

BGP, OSPF, and so

on Queuing = ratebased Small guaranteed

Often proprietary Admission control = RSVP

(65)

Network

usage User-selectedservice Queuing = ratebased No bandwidth

section 4.1 Unspecified traffic Queuing = ratebased Minimal bandwidth

The next step in the trend toward simplification was for the network nodes "to do the right thing." Through a series of changes in Cisco IOS Software and selected nonCisco IOS

products (such as IP phones), voice packets now are marked by default to the recommended value of DSCP EF. These

(66)

Cross-Platform Feature Consistency

An additional objective in the simplification of QoS (beyond syntax and automation) is to improve the operational and semantic feature consistency across platforms.

As part of this effort, Cisco is consolidating and improving the QoS code bases of the distributed router architectures (such as the Cisco 7500 series of routers) and the nondistributed router families (such as the Cisco 7200 to 1700 series routers). This initiative is called Consistent QoS Behavior code and should remove most (if not all) of the traditional QoS idiosyncrasies between the distributed and nondistributed platforms.

Such projects are ongoing, as the application drivers for QoS continue to demand unique features for specific scenarios, but administrators generally prefer QoS consistency and simplicity.

Automatic QoS

Automatic QoS (AutoQoS) is essentially an intelligent macro that enables an administrator to enter one or two simple

AutoQoS commands to enable all the appropriate features for the recommended QoS settings for an application on a specific interface.

For example, in its first release, AutoQoS VoIP would provide best-practice QoS configurations for VoIP on Cisco Catalyst switches and routers. By entering one global or one interface command (depending on the platform), the AutoQoS VoIP macro then would expand these commands into the

recommended VoIP QoS configurations (complete with all the calculated parameters and settings) for the platform and