QOS SRND Aug 02

Corporate HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706 USAhttp://www.cisco.comTel: 408 526-4000

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

Cisco AVVID Network Infrastructure Enterprise Quality of Service DesignSolutions Reference Network Design

August, 2002

Customer Order Number: 956467

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

CCIP, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All Thats Possible, The 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, IOS, IP/TV, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, 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. (0203R)

Cisco AVVID Network Infrastructure Enterprise Quality of Service DesignCopyright 2002, Cisco Systems, Inc.All rights reserved.

Cisco AVVID Netwo956467

Determining the Classes of Data TrafProvisioning for Important Data TraffiReactive vs. Proactive Policies 1-10Non-Technical QoS Considerations of

Service-Provider QoS Requirements 1-1fic 1-9c 1-9

C O N T E N T S

About this Document xi

Intended Audience xi

Document Organization xi

Document Conventions xii

Obtaining Documentation xiiiWorld Wide Web xiiiDocumentation CD-ROM xiiiOrdering Documentation xiiiDocumentation Feedback xiii

Obtaining Technical Assistance xivCisco.com xivTechnical Assistance Center xiv

Cisco TAC Web Site xvCisco TAC Escalation Center xv

C H A P T E R 1 Overview 1-1

Why is Quality of Service Required for AVVID? 1-1Understanding QoS 1-1

Loss 1-2Delay 1-3Delay Variation 1-3

Quality of Service Requirements for Voice 1-3Voice Traffic 1-4Voice Control Traffic 1-5

Quality of Service Requirements for Video 1-6Streaming Video 1-6Video conferencing 1-7

Quality of Service Requirements for Data 1-7Relative Priority vs. Over-Engineering Bandwidth Provisioning 1-8iiirk Infrastructure Enterprise Quality of Service Design

Data 1-101

Contents

What is the Quality of Service Toolset? 1-12Classification Tools 1-12

Class of Service 1-13Type of Service and Differentiated Services Code Points 1-13Per-Hop Behaviors 1-14Network-Based Application Recognition 1-14Classification Equivalents 1-14

Classification Recommendations 1-15Voice Bearer Traffic 1-16Voice Control Traffic 1-16Video Conferencing 1-16Streaming Video 1-16Mission-Critical Data 1-17Less-Than-Best-Effort Data 1-17Best-Effort Data 1-17

Scheduling Tools 1-17Class-Based Weighted-Fair Queueing 1-18Low-Latency Queueing 1-19Weighted-Random Early Detect 1-20

Scheduling Recommendations 1-22Queue Scheduling 1-22Number of Queues 1-22

Provisioning Tools 1-22Policing and Shaping Tools 1-23Link-Efficiency Mechanisms 1-23Call Admission Control 1-26

Management Tools 1-26

C H A P T E R 2 QoS Considerations When Connecting End-Points to an AVVID Network 2-1

Overview 2-1

The Trusted Edge 2-2

IP Telephony 2-2IP Phones 2-2CallManager 2-2VoIP Gateways 2-3

H.323 2-3MGCP 2-3

Classification for Non-marking Applications 2-3ivCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Contents

Video 2-3Video Conferencing 2-4Streaming Video 2-4

Mission-Critical Applications 2-4DLSW+ 2-4Less-than-Best-Effort 2-5

Summary 2-5

C H A P T E R 3 QoS in an AVVID-Enabled Campus Network 3-1

Overview 3-1Delay Variation 3-2Transmit Buffer Congestion 3-2

QoS Toolset 3-4Classification 3-4Scheduling 3-5

Server Farm Switch Selection 3-6Voice Bearer Traffic 3-7Voice over IP Call Control 3-10

Skinny Protocol 3-10H.323 Protocol 3-11MGCP 3-11Verifying the ACLs 3-12

Mission-Critical Data 3-12

Selecting an Access-Layer Switch 3-14Catalyst 6500 as an Access-Layer Switch 3-15

Enabling QoS 3-17Configuring IP Phone Port Queuing 3-17Configuring the Uplink to the Distribution Switch 3-18Verifying the Configuration 3-19

Catalyst 4000 as an Access-Layer Switch 3-21Catalyst 4000 with Supervisor III 3-22Catalyst 4000 with Supervisor II 3-29

Catalyst 3524-PWR XL as an Access-Layer Switch 3-31Configuring IP Phone Port Queuing 3-32Configuring the Uplink Interface to the Distribution Switch 3-33

Catalyst 3550 as an Access-Layer Switch 3-33Enabling QoS 3-34Modifying the CoS-to-DSCP Mappings 3-34vCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Enabling Priority Queuing 3-35

Contents

Configuring ACLs 3-35Configuring Access-Layer Phone Support 3-36Configuring the Uplink to the Distribution Switch 3-36Verifying the Configuration 3-37

Catalyst 2950 as an Access-Layer Switch 3-38Modifying the CoS-to-DSCP Mappings 3-39Configuring ACLs 3-40Configuring Access-Layer Phone Support 3-40Configuring the Uplink to the Distribution Switch 3-41Verifying the Configuration 3-41

Selecting a Distribution-Layer Switch 3-42Catalyst 6500 (with Catalyst OS) as a Distribution-Layer Switch 3-42

Configuring the Distribution Layer VoIP Control Traffic Transmit Queue 3-43Configuring the Distribution Layer with a Layer 3 Switch 3-43Configuring the Distribution Layer with a Layer 2 Switch 3-44Verifying the Configuration 3-45

Catalyst 6500 (with Native IOS) as a Distribution-Layer Switch 3-47Enabling QoS 3-47Configuring the Distribution Layer VoIP Control Traffic Transmit Queue 3-48Configuring the Distribution Layer with a Layer 3 Switch 3-48Configuring the Distribution Layer with a Layer 2 Switch 3-49Verifying the Configuration 3-51

Catalyst 4000 with Supervisor III as a Distribution-Layer Switch 3-51Enabling QoS 3-52Modifying the CoS-to-DSCP Mapping 3-52Configuring Priority Queuing 3-53Configuring ACLs 3-53Configuring Service Policy 3-54Configuring CoS or DSCP Trust 3-54Verifying the Configuration 3-55

Catalyst 3550 as a Distribution-Layer Switch 3-58Enabling QoS 3-58Modifying the CoS-to-DSCP Mapping 3-59Enabling Priority Queuing 3-59Configuring ACLs 3-59Configuring CoS or DSCP Trust 3-60Verifying the Configuration 3-61

Summary 3-63viCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Contents

C H A P T E R 4 QoS in an AVVID-Enabled Wide-Area Network 4-1

Overview 4-1

QoS Toolset 4-2Classification 4-2Provisioning 4-2

Policers and Shapers 4-2Link-Fragmentation and Interleaving 4-3TX Ring 4-3

Modular QoS Command-Line Interface 4-4

QoS Recommendations for WAN Aggregation Routers 4-4Classifying and Provisioning for Voice on the WAN Edge 4-4Classifying and Provisioning for Video on the WAN Edge 4-6Classifying and Provisioning for Data on the WAN Edge 4-6Link-Specific WAN QoS Recommendations 4-9

High-Speed Point-to-Point Links 4-9Slow-Speed Point-to-Point Links 4-10High-Speed Frame Relay Links 4-11Distributed-Platform High-Speed Frame Relay Links 4-14Slow-Speed Frame Relay Links 4-15Distributed-Platform Slow-Speed Frame Relay Links 4-17High-Speed ATM Links 4-18Slow-Speed ATM Links 4-19ATM-to-Frame Relay Recommendations 4-21ISDN Recommendations 4-24

Summary Configurations 4-26

QoS Recommendations for Remote Branch Routers 4-28WAN Edges 4-28Remote LAN Edge for Voice 4-28Remote LAN Edge for Video 4-29Remote LAN Edge for Data 4-30

Output Policies 4-30Input Policies 4-30

Summary Configuration 4-32

Verifying QoS 4-34show policy 4-34show policy interface 4-36

Example 1 4-36Example 2 4-40viiCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

show interface 4-42

Contents

show queue 4-43show frame-relay pvc 4-43show atm bundle 4-47show policy interface atm 4-47show atm vc 4-47show atm pvc 4-48

C H A P T E R 5 QoS in a SOHO Virtual Private Network for IP Telephony 5-1

Overview 5-1

QoS Toolset 5-2Classification 5-2

Classification of Voice Bearer traffic 5-2Classification of Voice Signaling Traffic 5-3

Scheduling 5-3Provisioning 5-3

TX Ring Sizing 5-3Link Fragmentation and Interleave 5-3Fragment Sizing for MLPPP over ATM 5-3Traffic Shaping 5-4Bandwidth Calculation 5-5

Solutions 5-6Application of QoS to DSL in a SOHO Environment 5-6

One and Two Box DSL Solution 5-7Third-Party Modem Solution 5-9

Application of QoS to Cable in a SOHO Environment 5-10One and Two Box Cable Solution 5-11Third-Party Modem Solution 5-13

Application of QoS over Other Technologies 5-14Last Mile Wireless, IDSL, etc. 5-14Voice over ISDN 5-15

Summary 5-16

C H A P T E R 6 QoS with MPLS in an AVVID-Enabled Network 6-1

Overview 6-1MPLS VPN Architecture 6-2MPLS Modes of Operation 6-2MPLS Labels 6-3

MPLS Label Stack 6-3viiiCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Placement of Labels by Mode 6-4

Contents

MPLS VPN QoS 6-5

Considerations for MPLS VPN QoS 6-5Convergence 6-5

After a Link Failure 6-5After a Link Recovery 6-6

Redundancy 6-6Using IP Multicast over MPLS VPNs 6-7

Implementing MPLS VPN QoS 6-8CE Routers 6-8PE Routers 6-10P Routers 6-13

A P P E N D I X A Reference Information A-1

DSCP Equivalents A-1

Catalyst 6500 Linecards and Queuing Mechanisms A-2

Mission-Critical Applications Well-Known Ports A-3

DLSW+ Considerations A-4

When to Enable cRTP A-5

Web Sites with Additional Information A-6Cisco Public Documentation A-6Cisco Limited-Access Information A-7RFCs from the IETF A-8Other External Sites A-8ixCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Contents xCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

About this Document

This document is designed to present an overview of the use of Quality of Service (QoS) in a variety of Cisco AVVID environments.

Intended AudienceThis document is intended for customers and Enterprise Systems Engineers (SEs) who has recently become involved with the QoS aspects of a Cisco AVVID network and who may be unfamiliar with the deployment choices available to an Enterprise customer.It provides in-depth design and configuration recommendations for the implementation of QoS to successfully meet the loss, delay, and delay variation (jitter) requirements of voice over IP, video over IP, and mission-critical data in a variety of environments.

Document OrganizationThis document contains the following chapters:

Chapter or Appendix Description

Chapter 1, Overview Provides an overview of QoS, the need for QoS in an AVVID network, and the QoS toolset.

Chapter 2, QoS Considerations When Connecting End-Points to an AVVID Network

Provides information about implementing QoS at the network edge.

Chapter 3, QoS in an AVVID-Enabled Campus Network

Discusses the need for QoS in a campus environment and provides guidelines and examples for implementation.xiCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 4, QoS in an AVVID-Enabled Wide-Area Network

Discusses the need for QoS in a wide-area network (WAN) and provides guidelines and examples for implementation.

Chapter 5, QoS in a SOHO Virtual Private Network for IP Telephony

Discusses the need for QoS in a small office, home office (SOHO) environment and provides guidelines and examples for implementation.

About this DocumentDocument ConventionsNote The chapters of this document contain references to other documents. These references are included as tips in the text. The URL for each referenced document is located in Appendix A Reference Information. In some cases, an internal document is referenced. For copies of internal documents, please see your Cisco Systems representative.

Document ConventionsThis guide uses the following conventions to convey instructions and information:

Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the manual.

Timesaver Means the described action saves time. You can save time by performing the action described in the paragraph.

Tips Means the following information will help you solve a problem. The tips information might not be troubleshooting or even an action, but could be useful information, similar to a Timesaver.

Chapter 6, QoS with MPLS in an AVVID-Enabled Network

Discusses the nuances of implementing QoS with MPLS in an AVVID network.

Appendix A, Reference Information

Provides reference information, such as equivalence tables and URLs for referenced documents.

Chapter or Appendix Description

Table 1 Document Conventions

Convention Description

boldface font Commands and keywords.italic font Variables for which you supply values.[ ] Keywords or arguments that appear within square brackets are optional.{x | y | z} A choice of required keywords appears in braces separated by vertical bars. You must select one.screen font Examples of information displayed on the screen.boldface screen font

Examples of information you must enter.

< > Nonprinting characters, for example passwords, appear in angle brackets.[ ] Default responses to system prompts appear in square brackets.xiiCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

About this DocumentObtaining DocumentationCaution Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data.

Obtaining DocumentationThe following sections explain how to obtain documentation from Cisco Systems.

World Wide WebYou can access the most current Cisco documentation on the World Wide Web at the following URL:http://www.cisco.comTranslated documentation is available at the following URL:http://www.cisco.com/public/countries_languages.shtml

Documentation CD-ROMCisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.

Ordering DocumentationCisco documentation is available in the following ways:

Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace:http://www.cisco.com/cgi-bin/order/order_root.pl

Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:http://www.cisco.com/go/subscription

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation FeedbackIf you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click the Fax or Email option under the Leave Feedback at the bottom of the Cisco Documentation home page.

You can e-mail your comments to [email protected] AVVID Network Infrastructure Enterprise Quality of Service Design

956467

About this DocumentObtaining Technical AssistanceTo submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:Cisco SystemsAttn: Document Resource Connection170 West Tasman DriveSan Jose, CA 95134-9883We appreciate your comments.

Obtaining Technical AssistanceCisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.

Cisco.comCisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world. Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to

Streamline business processes and improve productivity Resolve technical issues with online support Download and test software packages Order Cisco learning materials and merchandise Register for online skill assessment, training, and certification programs

You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:

http://www.cisco.com

Technical Assistance CenterThe Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.Inquiries to Cisco TAC are categorized according to the urgency of the issue:

Priority level 4 (P4)You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.

Priority level 3 (P3)Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.xivCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

About this DocumentObtaining Technical Assistance Priority level 2 (P2)Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.

Priority level 1 (P1)Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.

Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.

Cisco TAC Web Site

The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:http://www.cisco.com/tacAll customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:http://www.cisco.com/register/If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL:http://www.cisco.com/tac/caseopenIf you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtmlBefore calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.xvCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

About this DocumentObtaining Technical AssistancexviCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Cisco AVVID Network Infrastructure956467

Delay

Delay Variation

There are many points in AVVID networks where QoS mechaand delay variation. Figure 1-1 illustrates areas where QoS mimpact of loss, delay, and delay variation on voice performannisms are required to manage loss, delay, echanisms are required to control the ce. C H A P T E R

1Overview

This chapter provides an overview of Quality of Service (QoS) and its uses. This chapter provides high-level answers to the following questions:

Why is Quality of Service Required for AVVID? What is the Quality of Service Toolset?

Note This chapter contains references to other documents. These references are included as tips in the text. The URL for each referenced document is located in Appendix A, Reference Information. In some cases, an internal document is referenced. For copies of internal documents, please see your Cisco Systems representative.

Why is Quality of Service Required for AVVID?The key enabling technology for network convergence in the Architecture for Voice, Video, and Integrated Data (AVVID) is QoS. This is because voice, video, and mission-critical data have stringent service requirements from the network infrastructure. These requirements supersede the requirements of generic data traffic. If voice, interactive-video, and mission-critical data are not given priority service from network devices, then the quality of these important applications would quickly degrade to the point of being unusable.

Understanding QoSQoS is defined as the measure of performance for a transmission system that reflects its transmission quality and service availability. Service availability is a crucial foundation element of QoS. Before any QoS can be implemented successfully, the network infrastructure must be designed to be highly available. The transmission quality is determined by the following factors:

Loss1-1 Enterprise Quality of Service Design

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?Figure 1-1 Areas Where QoS is Needed

Loss

Loss (or packet loss) is a comparative measure of packets faithfully transmitted and received to the total number that were transmitted. Loss is expressed as the percentage of packets that were dropped.

8109

9

M

WAN

Central campus Remote branch

SiSi

IP

IP

QoS - Campus Access QoS - Campus Dist. QoS - WAN QoS - Branch

Establish Trust Boundary

Layer 2 (802.1p) to Layer 3(DSCP) classificationLayer 3 (DSCP) to Layer 2(802.1p) classificationLayer 2 or Layer 3classification whererequired-service policies

CoS/DSCP to queue entrycriteria

Multiple queues and queuescheduling (priority or high)

Establish Trust Boundary-Trust DSCP or CoS fromAccess Layer




Map L3 DSCP to L2 CoSvia sevice policy out and802.1q trunk




Low-latency queuing

Data traffic queue provisioning

Link Fragmentation and interleave

Traffic shaping

Admission control1-2Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?Delay

Delay (or latency) is the amount of time it takes a packet to reach the receiving endpoint after being transmitted from the sending endpoint. This time period is termed the end-to-end delay and can be broken into two areas: fixed network delay and variable network delay. Fixed network delay includes encoding/decoding time (for voice and video), as well as the finite amount of time required for the electrical/optical pulses to traverse the media en route to their destination. Variable network delay generally refers to network conditions, such as congestion, that may affect the overall time required for transit.In data networks carrying voice, there are three types of delay:

Packetization delay, which is the amount of time that it takes to sample and encode the analog voice signals and turn them in to packets.

Serialization delay, which is the amount of time that it takes to place the bits of the data packets onto the physical media.

Propagation delay, which is the amount of time it takes to transmit the bits of a packet across the physical wire.

Delay Variation

Delay variation (or jitter) is the difference in the end-to-end delay between packets. For example, if one packet required 100 ms to traverse the network from the source-endpoint to the destination-endpoint and the following packet required 125 ms to make the same trip, then the delay variation is calculated as 25 ms.Each end station in a VoIP or Video over IP conversation has a jitter buffer. Jitter buffers are used to smooth out changes in arrival times of data packets containing voice. A jitter buffer is dynamic and can adjust for up to a 30 ms average change in arrival times of packets. If you have instantaneous changes in arrival times of packets that are outside of the capabilities of a jitter buffers ability to compensate you will have jitter buffer over-runs and under-runs.

A jitter buffer under-run occurs when arrival times of packets increases to the point where the jitter buffer has been exhausted and contains no packets to be processed by the DSPs when it is time to play out the next piece of voice or video.

A jitter buffer over-run occurs when packets containing voice or video arrive faster than the jitter buffer can dynamically resize itself to accommodate. When this happens packets are dropped and when it is time to play out the voice or video samples contained in the dropped packets quality is degraded.

Quality of Service Requirements for VoiceWhen addressing the QoS needs of voice traffic, keep the following in mind:

Loss should be no more than 1%. One-way latency should be no more than 150-200 ms. Average jitter should be no more than 30 ms. 21-106 kbps of guaranteed priority bandwidth is required per call (depending on the sampling rate,

codec and Layer 2 overhead). 150 bps (+ Layer 2 overhead) per phone of guaranteed bandwidth is required for Voice Control

traffic.1-3Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?Voice quality is directly affected by all three QoS quality factors: loss, delay, and delay variation. Loss causes voice clipping and skips. The industry standard codec algorithms used in Cisco Digital Signal Processor (DSP) can correct for up to 30 ms of lost voice. Cisco VoIP technology uses 20 ms samples of voice payload per VoIP packet. Therefore, for the codec correction algorithms to be effective, only a single Real Time Transport (RTP) packet can be lost during any given time. If two successive voice packets are lost, the 30ms correctable window is exceeded and voice quality begins to degrade. Delay can cause voice quality degradation if it is above 200 ms. If the end-to-end voice delay becomes too long (for example, 250 ms), the conversation begins to sound like two parties talking on over a satellite link or even a CB radio. The ITU standard for VoIP (G.114) states that a 150 ms one-way delay budget is acceptable for high voice quality. The Cisco Technical Marketing Team has shown that there is a negligible difference in voice quality scores using networks built with 200 ms delay budgets. With respect to delay variation, there are adaptive jitter buffers within Cisco IP Telephony devices. However, these can usually only compensate for 20 to 50 ms of jitter.Implementing QoS is a means to use bandwidth efficiently, but not a blanket substitute for bandwidth itself. When an enterprise is faced with ever increasing congestion, a certain point is reached where QoS alone will not solve bandwidth requirements. At such a point, nothing short of additional bandwidth will suffice. The following sections provide guidelines that can help you determine when this point is reached.

Voice Traffic

The bandwidth consumed by VoIP streams is calculated by adding the packet payload and all headers (in bits), then multiplying by the packet rate per second (default of 50 packets per second). Table 1-1 details the bandwidth per VoIP flow at a default packet rate of 50 packets per second (pps) and at 33 pps. This does not include Layer 2 overhead and does not take into account any possible compression schemes, such as compressed Real-time Transport Protocol (cRTP). The Service Parameters menu in Cisco CallManager Administration can be used to adjust the packet rate.

Note Although it is possible to configure the sampling rate above 30 ms, this usually results in very poor voice quality.

Table 1-1 Voice Bandwidth (without Layer 2 overhead)

Bandwidth Consumption Sampling Rate Voice Payload in Bytes

Packets per Second

Bandwidth per Conversation

G.711 20 ms 160 50 80 kbpsG.711 30 ms 240 33 74 kbpsG.729A 20 ms 20 50 24 kbpsG.729A 30 ms 30 33 19 kbps1-4Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?A more accurate method for provisioning VoIP is to include the Layer 2 overhead, which includes: preambles, headers, flags, CRCs, and ATM cell-padding. The amount of overhead depends on the technology used:

802.1Q Ethernet adds 32 bytes of Layer 2 overhead. Point-to-point protocol (PPP) adds 12 bytes of Layer 2 overhead. Multilink PPP (MLP) adds 13 bytes of Layer 2 overhead. Frame Relay adds 8 bytes of Layer 2 overhead. ATM adds varying amounts of overhead. depending on the cell-padding requirements.

When Layer 2 overhead is included in the bandwidth calculations, the VoIP call requirements translate to the figures shown in Table 1-2.

Table 1-2 Voice Bandwidth (with Layer 2 overhead)

Bandwidth requirements for voice traffic range from 21 kbps to 106 kbps, depending on the CODEC, the sampling rate, and the Layer 2 media used.Figure 1-2 shows the bandwidth requirements of a G.711 voice call (64 kbps) over Frame-Relay media.

Figure 1-2 G.711 Pulse-Code Modulation (PCM) Voice-Call Over Frame-Relay

Voice Control Traffic

In centralized call processing designs, the IP phones use a TCP control connection to communicate with the Cisco CallManager. If there is not enough bandwidth provisioned for these lightweight control connections, the user might be adversely affected. For example, lets look at the Delay to Dial-Tone (DTT) time periods. When an IP phone goes off-hook, it asks the CallManager what to do. The CallManager instructs the IP phone to play a Dial-Tone. If control traffic is dropped or delayed within the network, the user will not get the Dial-Tone played out. This same logic applies to all signaling traffic for gateways and phones.For Cisco IP phones, the control traffic required is approximately 150 bps per phone (not including layer 2 overhead).

Bandwidth Consumption

802.1Q Ethernet PPP MLP Frame-Relay ATM

G.711 at 50 pps 93 kbps 84 kbps 86 kbps 84 kbps 106 kbpsG.711 at 33 pps 83 kbps 77 kbps 78 kbps 77 kbps 84 kbpsG.729A at 50 pps 37 kbps 28 kbps 30 kbps 28 kbps 43 kbpsG.729A at 33 pps 27 kbps 21 kbps 22 kbps 21 kbps 28 kbps

Single PCM VoIP Call

84Kbps64Kbps

7463

51-5Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?Tip Detailed calculations of call control traffic can be found in the Network Infrastructure Requirements chapter of the IP Telephony Solution Reference Network Design Guide.

Quality of Service Requirements for VideoWhen addressing the QoS needs of streaming video traffic, keep the following in mind:

Loss should be no more than 2%. Latency should be no more than 4-5 seconds (depending on video application's buffering

capabilities). There are no significant jitter requirements. Bandwidth requirements depends on the encoding and rate of video stream. Non-entertainment streaming video should be provisioned into the Silver data-traffic class. (The

silver data class is discussed in Provisioning for Important Data Traffic section on page 1-9.)For video content distribution, keep the following in mind:

Streaming video content is delay and delay variation insensitive. Streaming video requires large file transfers (traffic patterns similar to FTP sessions). Try to restrict to distribution to less-busy times of day. Provision as less-than-best-effort data. (The less-than-best-effort data class is discussed in

Provisioning for Important Data Traffic section on page 1-9.)When addressing the QoS needs of video conferencing traffic, keep the following in mind:

Loss should be no more than 1%. One-way latency should be no more than 150-200 ms. Average jitter should be no more than 30 ms. The minimum bandwidth guarantee is the size of the video conferencing session + 20% (meaning

that a 384 kbps video conferencing session requires 460 kbps guaranteed priority bandwidth).There are two main types of video applications: streaming video (such as IP/TV, which may be either on-demand or multicast) and interactive video (such as video conferencing).

Streaming Video

Streaming video applications have more lenient QoS requirements, as they are delay insensitive (the video can take several seconds to 'cue-up'), and are largely delay variation insensitive (due to application buffering). Streaming video may contain valuable content, as in the case of an E-learning application, and therefore may require service guarantees via QoS. Streaming video would be appropriately provisioned in the Silver class of data traffic.When you are provisioning for streaming video, you should also take into account the video content distribution requirements. Video file distribution is very similar to FTP traffic in nature and can have a major impact on network performance (due to the file size). Distribution traffic should be managed to avoid impacting the network. For example, video content transfers could be limited to off-peak hours or treated as less-than-best-effort traffic.1-6Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?Video conferencing

Video conferencing has the same loss, delay, and delay variation requirements as voice, but the traffic patterns of video conferencing are radically different from voice. For example, video conferencing traffic has varying packet sizes and extremely variable packet rates (as shown in Figure 1-3.)

Figure 1-3 Video conferencing Bandwidth Requirements for a 384 kbps Session

Because of its bursty nature, video conferencing has two unique requirements in provisioning for strict-priority bandwidth:

The LLQ must be provisioned to the stream-rate plus 20%. The LLQ burst parameter must be provisioned to 30000 bytes per 384 kbps stream.

Quality of Service Requirements for DataWhen addressing the QoS needs of data application traffic, keep the following in mind:

Profile applications to get a basic understanding of their network requirements and traffic patterns. Don't over-engineer the provisioning. Instead, use the proven relative priority model (as explained

in the following section). Use no more than four traffic classes, such as:

Gold (Mission-Critical)Enterprise Resource Planning (ERP), transactional, in-house software

Silver (Guaranteed-Bandwidth)Streaming video, messaging, intranet Bronze (Best-Effort and Default class)Internet browsing, E-Mail Less-than-Best-Effort (Optional; higher-drop preferences)FTP, backups, Peer-to-Peer (P2P)

applications (Napster, KaZaa) Do not assign more than 3 applications to each class of protected data traffic. Use proactive provisioning polices before reactive policing policies. Obtain executive endorsement of relative ranking of application priority (from a QoS perspective)

prior to committing to the actual policy implementation, to avoid potential derailing of the project.

"P" and "B" FramesDifferential/Predicted Frames

128-256 Bytes

"I" Frame(Full-Sample Video)

1024-1518 Bytes

"I" Frame(Full-Sample Video)

1024-1518 Bytes

35Kbps15pps

30pps

600Kbps

7463


956467

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?Relative Priority vs. Over-Engineering Bandwidth Provisioning

Because bandwidth requirements vary greatly from application to application (and even between versions of the same applications) it is not possible to provide a blanket rule for provisioning data bandwidth. Traffic analysis and lab-testing are required to ascertain bandwidth requirements for data applications.Figure 1-4 shows a comparison of traffic patterns between two popular mission-critical ERP applications, Oracle and SAP.

Figure 1-4 Oracle versus SAP R/3 Packet Distribution

In addition to the wide variation of traffic patterns and requirements between different data applications, traffic patterns often vary greatly between two versions of the same application. Figure 1-5 illustrates a situation where the same transaction in one version of SAP requires 35 times more bytes than an earlier version.

Figure 1-5 SAP Version Traffic Comparison for Identical Transactions

The following is an example of basic bandwidth provisioning for data.An enterprise has as SAP R/3 as its mission-critical application. The task most typically performed by users in the remote offices is the Create Sales Order transaction (VA01). This transaction entails 14 KB of data, which translates to 112 kbps of required bandwidth to ensure a response time of less than 1 second. If SAP is provisioned as a mission-critical application receiving 25% of the link's capacity, then a link size of approximately 512 kbps is required to provide this service-level.

Oracle SAP

7463

9

0-64 Bytes 1024-1518 Bytes512-1023 Bytes

253-511 Bytes65-127 Bytes128-252 Bytes253-511 Bytes512-1023 Bytes1024-1518 Bytes

128-252 Bytes65-127 Bytes

0-64 Bytes

7464

0

SAP GUI,Release

3.0F

500,000

400,000

300,000

200,000

100,000

0SAP GUI,Release

4.6C,with Cache

Bytes per Sales Order Entry (VA01)Transaction

SAP GUI,Release

4.6C,no Cache

SAP GUI(HTML),Release

4.6C1-8Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?However, if the enterprise chooses to run a newer version of SAP (4.6c) in an uncompressed HTML format, the VA01 transaction would then require 490 KB per transaction. If link and bandwidth-provisioning remained unchanged, then the new end-user response time would be approximately 32 seconds per transaction. If there is no other traffic traversing the 512 kbps link, the transaction would require approximately 8 seconds. Clearly this is a case where QoS alone is insufficient to accommodate required service-levels given the nature of the data traffic.Continuing the example, lets assume that the average employee in this enterprise receives 10 MB of e-mail per day (including all attachments). While E-Mail is a highly asynchronous application and is recommended to be classified as best-effort traffic, it nonetheless requires bandwidth. The daily average mail spool divided over an 8 hour workday equates to average of 2.8 kbps of e-mail traffic per employee. If the remote branch has 50 employees, this requirement becomes 140 kbps as a daily average. But, e-mail traffic generally displays a cyclical burst according to time of day (with highest traffic levels between 8-10:30 am). If the assumption is made that e-mail traffic during these periods is double the daily average, then more than 280 kbps of bandwidth could be consumed by e-mail during these hours.These are the type of calculations that should be taken into account not only when provisioning QoS policies, but also in determining when to increase link bandwidth.Absolute application provisioning requires a myriad of assumptions that are unlikely to all hold true on a daily basis. Application updates, fluctuation in the numbers of users, varying business environments, as well as the time of day, month, and year, all affect bandwidth requirements of data applications. Therefore, rather than attempting to determine exact kilobits of bandwidth requirements for data applications, a simpler and proven approach is to assign relative priorities to data applications.

Determining the Classes of Data Traffic

It is counterproductive to use too many discrete classes for data traffic. This is because the more classes that are defined, the less the distinction between service-levels. To illustrate, the available bandwidth could be likened to a pie. If the pie is sliced into 64 gradually smaller pieces and then served to respectively important guests (with the largest slice being served to the most important guest), it would be quite difficult to ascertain who's getting the better slivers. Likewise, having too many classes will reduce the overall effectiveness of QoS. Therefore, it is recommended that you define only four classes of data traffic at the most.Additionally, if too many applications are assigned to the highest classes, then the overall effectiveness of QoS provisioning is dampened. Taken to an extreme, if all applications are assigned 'gold' service levels, then the end result is the same as when no QoS is provisioned at all (first-in-first-out scheduling). For this reason, applications provisioned with QoS should be limited to only a select few (maximum 3 applications per class).

Provisioning for Important Data Traffic

The relative-priority model suits data applications, as these can easily be categorized into three broad classes of traffic: important, best-effort and less-than-best-effort. Important traffic can additionally be sub-divided into multiple categories, as required. Usually mission-critical traffic is assigned to the highest class of data applications, gold. Mission-critical applications are those that directly contribute to the core operations of an enterprise. These applications are highly-interactive and are therefore sensitive to loss and delay. Examples of mission-critical applications include ERP applications, such as SAP, Oracle, and PeopleSoft, as well as proprietary applications that were designed in-house. 1-9Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?Some applications are better suited to a silver class of data traffic. Such applications are generally viewed as secondary in importance to business operations or are highly asynchronous in nature. These applications include Netmeeting and messaging applications, calendaring, groupware, and intranet browsing.Best-effort is the default category for data applications. These applications play an indirect role in normal enterprise operations. While some of these applications might be interactive, no bandwidth guarantees are required. Perhaps the best examples of these types of application are E-mail and generic Internet browsing.Less-than-best-effort is a category for applications that are bandwidth intensive and that may not have anything to do with the enterprises' business. These applications are typically highly delay and drop insensitive, and often the executions of such applications span over hours. Therefore, these applications can be given a higher-drop preference to prevent them from robbing bandwidth away from best-effort applications. Examples of less-than-best-effort of traffic include large file transfers, backup operations, and peer-to-peer entertainment-media swapping applications (like Napster, KaZaa, Gnutella).

Reactive vs. Proactive Policies

Sometimes administrators chase after the less-than-best-effort traffic and implement limiting policies on these in hopes of indirectly improving available bandwidth to other applications. With this reactive approach, bandwidth is monopolized by unimportant applications until users of important applications complain enough to warrant investigation into the cause by the IT or networking departments. After time, the investigations reveal the culprit application, which is subsequently policed. Performance of the important applications will likely improve, but only until another lesser-important, bandwidth-intensive application emerges. In this approach, the bandwidth-limiting policies will become increasingly complex to administer and will require more CPU overhead to enforce as their complexity grows.A proactive approach is to properly provision (minimum) bandwidth guarantees for important data applications (in their respective orders) and provision a best-effort default class. After these protective policies are in place, optional policing policies can be overlaid for less-than-best-effort traffic. However, the implementation of policing policies creates a static limit that may not always be desirable. For example, data backups, which usually occur overnight, often make use of the additional bandwidth that is available during non-peak hours. With policing policies, the unused bandwidth would not be available, which could cause the backup process to carry over into morning work hours. Therefore, increasing the drop preference of less-than-best- effort traffic (instead of using strict policing policies) is a more efficient use of available bandwidth.

Non-Technical QoS Considerations of Data

QoS is essentially segregating applications and giving preference to certain applications over others. With voice and video, the need for QoS is relatively objective and obvious. However, this is not the case with data applications.Arriving at the design principles of relatively few classes of data traffic and also of assigning only a select few applications to these classes opens up a variety of subjective non-technical issues. This is because the enterprise is left to subjectively rank their applications in relative priority. This process is usually very politically and organizationally charged and quite often takes more time to complete than the actual technical portion of a QoS implementation.

Tip It is important to have agreement (preferably with executive endorsement) on the relative ranking of data applications within the enterprise, otherwise QoS rollout projects could get derailed when disagreements arise over which applications are the more important.1-10Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?Service-Provider QoS RequirementsEnd-to-end QoS is like a chain, which is only as strong as the weakest link. Therefore, it's essential for enterprises to use service providers that can provide the service-level agreements required for AVVID applications. For example, the end-to-end requirements of voice and video conferencing are:

No more than 1% loss No more than 150 ms of one-way latency from mouth-to-ear (per ITU G.114 standard) No more than 30 ms jitter

Thus, the service provider's component (a subset of the trip) must be considerably tighter, as shown below and in Figure 1-6.

No more than 0.5% loss No more than 60 ms of one-way latency from edge-to-edge No more than 20 ms jitter

Figure 1-6 Service-Provider Service-Level Agreements Required for AVVID

To achieve such values, enterprises and service-providers must cooperate and be consistent in classifying, provisioning and integrating their respective QoS solutions.

Maximum One-WayService-ProviderService-Levels

Latency

Chapter 1 OverviewWhat is the Quality of Service Toolset?What is the Quality of Service Toolset? As applications that are sensitive to packet loss, delay, and delay variation (jitter) are implemented in Enterprise network environments, the ability to manage these sensitivities has become necessary. The packet loss, delay, and delay variation requirements that VoIP, video, and mission-critical data applications make of the network can be satisfied through the implementation of the QoS classification, scheduling, provisioning, and management tools. This section provides an overview of the following topics:

Classification Tools Classification Recommendations Scheduling Tools Scheduling Recommendations Provisioning Tools

Management Tools

Classification ToolsThe first element to a QoS policy is to identify the traffic that is to be treated differently. Classification tools mark a packet or flow with a specific priority. This marking establishes a trust boundary that must be enforced. Classification set this boundary by examining any of the following:

Layer 2 Parameters (802.1Q Class of Service [CoS] bits, MAC address, Multiprotocol Label Switching [MPLS] experimental values)

Layer 3 Parameters (IP Precedence, Differentiated-Services Code Points [DSCP], Source/Destination IP address)

Layer 4 Parameters (TCP or UDP ports) Layer 7 Parameters (application signatures)

Only after traffic can be positively identified can policies be applied. Best-practice design recommendations are to identify and mark (with DSCP values) traffic as close to the source of the traffic as possible. The network edge where markings are accepted (or rejected) is referred to as the trust-boundary. If markings and trusts are set correctly, then intermediate hops do not have to perform detailed traffic identification, but can administer QoS policies based on these previously set DSCP markings. This approach simplifies policy administration and reduces CPU overhead.Classification should take place at the network edge, typically in the wiring closet or within the IP phones or voice endpoints themselves.There are several mechanisms that can be used for marking traffic, including:

Class of Service Type of Service and Differentiated Services Code Points Per-Hop Behaviors

Network-Based Application Recognition

Tip For more information, see Classification in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2. 1-12Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Class of Service

Packets can be marked as important by using Layer 2 Ethernet CoS settings in the User Priority bits of the 802.1p portion of the 802.1Q header (as shown in Figure 1-7).

Figure 1-7 Layer 2 Ethernet (802.1Q) CoS Settings

Type of Service and Differentiated Services Code Points

As Layer 2 media often changes as a packet travels from source to destination, a more ubiquitous classification would occur at Layer 3. The second byte in an IPv4 packet is the Type of Service (ToS) byte. The first three bits (by themselves) of the ToS byte are referred to as the IP Precedence bits. These same three bits, in conjunction with the next three bits, are known collectively as the DSCP bits. These bits are illustrated in Figure 1-8.

Figure 1-8 Layer 3 ToS and DSCP Settings

PREAM. SFD DA

PRI CFI VLAN ID

SA Type PT DATA FCSTAG4 Bytes

Three bits used for CoS(User priority) 81

034

VersionLength

ToS1 Byte LEN

7 6 5 4 3 2 1 0

ID Offset Proto FCS IP-SA IP-DA DataTTL

Unused bits;Flow control for

DS CP

IP precedence

DS CPStandard IPV4: Three MSB called IP precedence

(DiffServ may use six D.S. bits plus two for flow control) 81035

Layer 3 IPV41-13Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Per-Hop Behaviors

The Internet Engineering Task Force (IETF) has defined certain Per-Hop Behaviors (PHBs) in RFC 2597 and RFC 2598 to identify consistent service levels to be provided by each node in the network infrastructure to packets with DSCP markings.

Tip For more information on RFC 2597, see Assured Forwarding PHB Group. And for more information on RFC 2598, see An Expedited Forwarding PHB.

There are three broad classes of PHBs: Best Effort (BE or DSCP 0), Assured Forwarding (AFxy), and Expedited Forwarding (EF or DSCP 46).Assured Forwarding has 4 sub-classes within it (corresponding to IP Precedence values) and also 3 levels of drop-preference within each class. For example, AF31 would refer to Assured Forwarding Class 3 drop-preference 1.DSCP values can be expressed in decimal form or with their PHB keywords; for example DSCP EF is synonymous with DSCP 46, also DSCP AF31 is synonymous with DSCP 26. In this document the DSCP values will be referred to by their PHB keywords.

Network-Based Application Recognition

Although the majority of data applications can be identified by using Layer 3 or Layer 4 criteria (such as discrete IP addresses or well-known TCP/UDP ports), there are applications that cannot be identified such criteria alone. This may be due to legacy limitations, but more likely due to deliberate design. For example, peer-to-peer media-sharing applications deliberately negotiate dynamic ports with the objective of penetrating firewalls. When Layer 3 or 4 parameters are insufficient to positively identify an application, then Network-Based Application Recognition (NBAR) may be a viable alternative solution. It should be noted that NBAR is a more CPU intensive classification mechanism than matching traffic by DSCP or access-lists. NBAR identifies application layer protocols by matching them against a Protocol Description Language Module (PDLM), which is essentially an application signature. NBARs deep-packet classification engine examines the data payload of stateless protocols against PDLMs. There are over 70 PDLMs embedded into IOS 12.2 code. Furthermore, since PDLMs are modular, they can be added to system without upgrading requiring an IOS upgrade.NBAR is dependent on Cisco Express Forwarding (CEF) and performs deep-packet classification only on the first packet of a flow. The remainder of the packets belonging to the flow is then CEF switched.

Tip For more information, see Network-Based Application Recognition and the NBAR Performance white paper (internal).

Classification Equivalents

Table 1-3 shows the recommended DSCP traffic classifications (in PHB and decimal) and how they relate to IP Precedence and MPLS experimental values.1-14Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Table 1-3 AVVID Classification Recommendations by PHB, DSCP and MPLS EV

Note Although many documents on QoS refer to DSCP classifications by their PHB label, you must use their decimal equivalent to make configuration changes in the Catalyst switches. For additional information about the decimal equivalents of PHBs, see Appendix A, Reference Information.

Note On routers enabled with MPLS, the IP Precedence values will (by default) be mapped to corresponding MPLS Experimental Values. If the classification recommendations shown in Table 1-3 are used, then no additional classification or reclassification is needed when interfacing with MPLS backbones.

Classification RecommendationsThis section provides classification recommendations for

Voice Bearer Traffic Voice Control Traffic Video Conferencing Streaming Video Mission-Critical Data

Traffic DSCP PHB DSCP Decimal IP Precedence MPLS EV

Voice EF 46 5 5Video AF41 34 4 4Voice-Control AF31 26 3 3Gold-Data

Application 1 AF21 18 2 2Application 2 AF22 20 2 2Application 3 AF23 22 2 2

Silver-Data Application 1 AF11 10 1 1Application 2 AF12 12 1 1Application 3 AF13 14 1 1

Bronze Data (best effort) BE 0 0 0Less-than-best-effort data

Application 1 - 2 0 0Application 2 - 4 0 0Application 3 - 6 0 01-15Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Voice Bearer Traffic

Recommendation: DSCP EF, IP Precedence 5, COS 5The IETF draft recommends a DSCP PHB label of EF for VoIP traffic. To remain backwardly compatible with IP Precedence, use an IP Precedence value of 5 and a CoS marking of 5. These markings can be used as selection criteria for entry into the priority queue, where it exists, or the queue with the highest service weight and lowest drop probability in a WRR/WRED scheduling scheme.

Voice Control Traffic

Recommendation: DSCP AF31, IP Precedence 3, CoS 3Typically the voice gateway or voice application server will mark it's RTP and control traffic with the appropriate DSCP and CoS markings. However, some end devices may not have the capability to correctly classify their own traffic. It is also possible, for reasons of control and security, that you would not want to trust the CoS and ToS markings assigned by the device (and would prefer to rewrite them upon ingress to the network).Signaling traffic should be assigned a DSCP PHB label of AF31. This assignment is backwardly compatible with an IP Precedence value of 3.

Video Conferencing

Recommendation: DSCP AF41, IP Precedence 4, CoS 4In enterprise networks, video conferencing over IP (IPVC) has similar loss, delay, and delay variation requirements to that of VoIP traffic. It is necessary to classify IPVC traffic so that network devices can recognize it and provide the appropriate treatment during periods of congestion. In enterprise networks, video conferencing packets should be marked with a DSCP PHB label of AF41. This assignment is backwardly compatible with an IP Precedence value of 4. A Layer 2 802.1p CoS value of 4 should be used for IPVC traffic in 802.1Q environments.

Streaming Video

Recommendation: DSCP AF13, IP Precedence 1, CoS 1Streaming video applications, like IPTV Video on Demand (VoD) programs, are relatively high bandwidth applications with a high tolerance for loss, delay, and delay variation. As such, significant QoS tools are not required to meet the needs of these applications. However, in most enterprise environments, these types of applications are considered more important than regular background applications (such as e-mail and web browsing) and should be given preferential treatment. A Layer 2 classification of CoS 1 in 802.1Q/p environments should be used for these applications. Because streaming video is not drop or delay sensitive, you can use the high drop preference DSCP PHB. The DSCP label AF13 should be used. This assignment is backwardly compatible with an IP Precedence value of 1.1-16Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Mission-Critical Data

Recommendation: Gold class or mission-criticalDSCP AF21-23, IP Precedence 2, CoS 2; Silver classDSCP AF11-AF13, IP Precedence 1, CoS 1Although the variety of factors that determine the importance of application traffic make it difficult to apply a formula to the provisioning of data, guidelines can be set for the classification of mission-critical traffic. Delay-sensitive applications that are critical to the operation of an enterprise, should be placed in the gold-data category and assigned a DSCP PHB ranging from AF21 to AF23 to protect them from drops. Less delay-sensitive applications that are important, but not critical, to the operation of an enterprise, should be placed in the silver-data category and assigned a higher drop preference of AF11 to AF13. If gold-data traffic is assigned AF21-AF23 and silver-data is assigned AF11-AF13, then these traffic flows will automatically be backwardly compatible with the IP Precedence model. Gold-data will be recognized as IP Precedence 2 and silver-data will be recognized as IP Precedence 1.

Less-Than-Best-Effort Data

Recommendation: DSCP 2-6, IP Precedence 0, CoS 0As mentioned before, non-critical, bandwidth-intensive data traffic should be assigned to the class known as less-than-best-effort. This traffic is delay-insensitive and should be given the least preference of any of the classes and, as such, should be dropped sooner than any other traffic. Therefore, less-than-best-effort traffic should be assigned a DSCP of 2-6 (decimal). This assignment is backwardly compatible with an IP Precedence value of 0.

Best-Effort Data

Recommendation: DSCP BE, IP Precedence 0, CoS 0All other traffic should be placed in the best-effort category. This includes all non-interactive traffic, regardless of importance.Best-effort traffic should be assigned a DSCP of BE. This assignment is backwardly compatible with an IP Precedence value of 0.

Scheduling ToolsScheduling tools refer to the set of tools that determine how a frame/packet exits a node. Whenever packets enter a device faster than they can exit it (as with speed mismatches) then a point of congestion, or a bottleneck, can occur. Devices have buffers that allow for scheduling higher-priority packets to exit sooner than lower priority ones, which is commonly called queueing. Queueing algorithms are activated only when a devices is experiencing congestion and are deactivated when the congestion clears.Figure 1-9 shows a generic example of queueing.1-17Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Figure 1-9 Generic Queueing Example

Queueing buffers are finite in capacity and act very much like a funnel for water being poured into a small opening. However, if water is continually entering the funnel much faster than it exits, then eventually the funnel will being overflowing from the top. When queueing buffers begin overflowing, packets may be dropped either as they arrive (tail-drop) or selectively before all buffers are filled. Selective dropping of packets when the queues are filling is referred to as congestion avoidance. Congestion avoidance mechanisms work best with TCP-based applications, as selective dropping of packets causes the TCP windowing mechanisms to 'throttle-back' and adjust the rate of flows to manageable rates. Congestion avoidance mechanisms are complementary to queueing algorithms; queueing algorithms manage the front of a queue, congestion avoidance mechanisms manage the tail of the queue. Therefore, congestion avoidance mechanisms indirectly affect scheduling.Scheduling tools include:

Class-Based Weighted-Fair Queueing Low-Latency Queueing Weighted-Random Early Detect

Tip For more information, see Congestion Management in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

Class-Based Weighted-Fair Queueing

Class-Based Weighted-Fair Queueing (CBWFQ) is a hybrid queueing algorithm, combining the ability to guarantee bandwidth (from Custom Queueing) with the ability to dynamically ensure fairness to other flows (from Weighted-Fair Queueing). CBWFQ allows for the creation of up to 64 classes of traffic, each with its own reserved queue. Each queue is serviced in a Weighted-Round-Robin (WRR) fashion.CBWFQ is a highly efficient algorithm for data applications, but is not able to provide strict-priority servicing to real-time applications, such as voice or video. To avoid bandwidth starvation of background applications (such as routing protocols, network services, and Layer 2 overhead and keepalives), it is recommended that you not provision total bandwidth guarantees to exceed 75% of the link's capacity (see Figure 1-11).

Note Distributed CBWFQ (dCBWFQ) is the distributed counterpart of CBWFQ.

7464

2

Router

Prioritization can be strict,bandwidth guarantee by traffic class,

or automatically weighted

Voice

Video

Data

11

2223 12 1


956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Low-Latency Queueing

Like CBWFQ, Low-Latency Queueing (LLQ) is also a hybrid queueing algorithm. LLQ is a combination of Priority Queueing, Custom Queueing, and Weighted-Fair Queueing. In fact, LLQ was originally named PQ-CBWFQ, but this name was dropped in favor of LLQ for fairly-obvious marketing reasons.LLQ adds a strict-priority queue to the CBWFQ scheduler. LLQ is designed exclusively for voice and interactive-video applications. The strict-priority queue is completely emptied before the CBWFQ queues are serviced. The Layer 3 queueing subsystem for LLQ/CBWFQ is shown on the left side of Figure 1-10.

Figure 1-10 CBWFQ/LLQ Queueing Subsystem Logic

In this illustration, VoIP bearer traffic is placed in the LLQ, commonly known as the priority queue (PQ). When traffic is present in the LLQ, it is serviced with preferential treatment exhaustively (first until none is present). The priority queue is policed so that traffic in the priority queue cannot starve out the other classes of traffic. It is important to provision the LLQ properly. This policing action could negatively affect voice quality if the policing value is set lower than the total amount of voice traffic to be serviced by the LLQ, in which case the excess will be dropped.This illustration also shows VoIP control traffic being placed in a class-based weighted fair queue of its own so that a small bandwidth guarantee can be made. This insures that call control traffic is transmitted even during periods of congestion on the link. This means that the time to dial tone and call setup/transfer are performed quickly enough to assure a positive user experience.It is important to keep in mind that the LLQ is in effect a first-in first-out (FIFO) queue. The amount of bandwidth reservable for the LLQ is variable, yet if the LLQ is over-provisioned, the overall effect will be a dampening of QoS functionality. This is because the scheduling algorithm that decides how packets exit the device will be predominantly FIFO (which is essentially no QoS). Over-provisioning the LLQ defeats the purpose of enabling QoS at all. For this reason, it is recommended that you not provision more than 33% of the link's capacity as a LLQ (see Figure 1-11).More than one LLQ can be provisioned. One LLQ could be provisioned for voice and another for video conferencing. Each queue would be serviced exhaustively before the next one would begin to be serviced (this scheduling is similar to legacy Priority Queueing). If more than one LLQ is provisioned, the 33% limit for all LLQs still applies.

7491

7

Low latency queuing Link fragmentationand interleave

Police

PQ Voice

VoIPControl

FragmentDefault

CBWFQWFQ

Packets inPackets out

PQ

Interleave TXRing1-19Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Note The 33% limit for all LLQs is a design recommendation. There may be cases where specific business needs cannot be met while holding to this recommendation. In such cases, the enterprise must provision queueing according to their specific requirements and constraints.

Figure 1-11 illustrates the recommendations that LLQ is no more than 33% of the link and all bandwidth guarantees are no more than 75% of the link capacity.

Figure 1-11 LLQ and CBWFQ

The functionality of LLQ has been extended in IOS 12.2 to allow the specification of a burst size for the LLQ. This burst parameter is highly useful in provisioning QoS for video conferencing.

Note Distributed LLQ (dLLQ) is the distributed counterpart of LLQ.

Weighted-Random Early Detect

As mentioned before, congestion avoidance mechanisms, like Weighted-Random Early Detect (WRED), are complementary to and dependent on queueing algorithms.The default router behavior allows output buffers to fill during periods of congestion and then drops everything thereafter (tail-drop). Due to the nature of the sliding-windows mechanism of TCP, a potentially large number of packets from numerous connections are discarded because of lack of buffer capacity during tail-drop. This behavior can result in waves of congestion followed by periods during which the transmission link is not fully used. Figure 1-12 illustrates such congestion waves created by tail-drop.

VideoVoice Control Data Routing

LLQ 33%

LLQ/CBWFQ Bandwidth Provisioning Principles

LLQ (Voice) + LLQ (Video) 33% Link CapacityLLQ (Voice) + LLQ (Video) + CBWFQ (All Data) 75% Link

Sum of all BW guarantees 75% of link

Link capacity

8103


956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Figure 1-12 Congestion Waves Attributable to Tail-Drop

WRED obviates this situation proactively by providing congestion avoidance. That is, instead of waiting for buffers to fill before dropping packets, the router monitors the buffer depth and performs early discards on selected packets sent over selected connections. WRED is primarily designed to work with TCP applications. When WRED is used and the TCP source detects the dropped packet, the source slows its transmission. WRED can selectively discard lower priority traffic when the interface begins to get congested.WRED can also be configured to use the DSCP value when it calculates the drop probability of a packet. The DiffServ Compliant WRED feature extends the functionality of WRED to enable support for PHBs. Thus, packets marked with Assured Forwarding PHBs will be assigned preferential drop probabilities based on these markings by the WRED algorithm. Figure 1-13 illustrates a simplified (3 PHB) example of DSCP-based WRED.

Figure 1-13 DSCP-Based WRED for AF11, AF12, and AF13

Note Distributed WRED (dWRED) is the distributed counterpart of WRED.

8103

7

100

Three traffic flowsstart at different times

Another traffic flowstarts at this point

Time

Queueutilization

8103

8

1

0Begin

droppingAF13

Begindropping

AF12

Begindropping

AF11

Dropall

AF13

Dropall

AF12

Dropall

AF11

Max queue length(tail drop everything)

Dropprobability1-21Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Tip For more information, see Congestion Avoidance in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

Scheduling RecommendationsThis section provides some recommendations for queue scheduling and the number of queues to use.

Queue Scheduling

Once you have marked your traffic appropriately and have allowed the traffic admission into the appropriate queue, you need to control how the queues are serviced. The scheduler process can use a variety of methods to service each of the transmit queues (voice, video, mission critical data, and general access data). The easiest method is a round-robin algorithm, which services queue 1 through queue N in a sequential manner. While not robust, this is an extremely simple and efficient method that can be used for branch office and wiring closet switches. Distribution layer switches use a WRR algorithm in which higher priority traffic is given a scheduling weight.Today's QoS-enabled switches have the ability to use hybrid scheduling algorithms that allow an exhaustive priority queue to be serviced until it is empty and WRR is used for the additional queues on a given interface.

Where supported, it is best to use a priority queue for voice and video bearer traffic. If a priority queue is not supported, use WRR and WRED to service the queue that contains the voice and video traffic. Set the WRR to service that queue most frequently and set the WRED thresholds such that the queue does not participate in WRED congestion avoidance.

Number of Queues

There has been much discussion about how many queues are actually needed on transmit interfaces in the campus. Should you add a queue to the wiring closet switches for each CoS value? Should you add eight queues to the distribution layer switches? Should you add a queue for each of the 64 DSCP values? This section presents some guidelines that address these questions.First, it is important to remember that each port has a finite amount of buffer memory. A single queue has access to all the memory addresses in the buffer. As soon as a second queue is added, the finite buffer amount is split into two portions, one for each queue. At this point, all packets entering the switch must contend for a much smaller portion of buffer memory. During periods of high traffic, the buffer fills and packets are dropped at the ingress interface. Because the majority of network traffic today is TCP-based, a dropped packet results in a resend, which further increases network congestion. Therefore, queuing should be used cautiously and only when particular priority traffic is sensitive to packet delays and drops.

Provisioning ToolsThe category of provisioning tools includes:

Policing and Shaping Tools Link-Efficiency Mechanisms1-22Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Policing and Shaping Tools

Policers and shapers are the oldest forms of QoS mechanisms. These tools have the same objectives, namely to identify and respond to traffic violations. Policers and shapers usually identify traffic violations in an identical manner; however, their main difference is the manner in which they respond to violations:

A policer typically drops traffic. A shaper typically delays excess traffic using a buffer, or queueing mechanism, to hold packets and

shape the flow when the data rate of the source is higher than expected. Shaping tools meter the transmit rate of frames from a source router to a destination router. This metering is typically done at a value that is lower than the line or circuit rate of the transmitting interface, as shown inFigure 1-14. The metering is done at this rate to account for the circuit speed mismatches that are common in current non-broadcast multiple-access (NBMA) networks, such as Frame-Relay and ATM.

Figure 1-14 Shaping Traffic at Less than Line Rate for NBMA Networks

Tip For more information, see Policing and Shaping in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

Link-Efficiency Mechanisms

Newer mechanisms have been developed to address link-specific requirements, such as minimizing serialization delay and traffic compression.

Tip For more information, see Link Efficiency Mechanisms in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

Link Fragmentation and Interleave

To offset link-specific delays, larger data packets can be fragmented and interleaved with higher priority voice or video packets. This helps reduce the variation in delay caused by periodic congestion on slow-link edges. Figure 1-15 illustrates the process of link fragmentation and interleaving (LFI).

Traffic shaping limits the transmit rateto a value (R) lower than line rate

Without Traffic Shaping

With Traffic Shaping

Line Rate

R

7464


956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Note In the context of Link-Efficiency Mechanisms, slow-speed links are defined as WAN links with clock speeds of 768 kbps or less.

Figure 1-15 Fragmentation and Interleaving to Reduce Serialization Delay

LFI belongs to the Layer 2 queueing subsystem and operates on packets that have already exited the Layer 3 queueing subsystem (LLQ/CBWFQ). As illustrated in Figure 1-10, only packets that are not assigned to the LLQ are fragmented. Table 1-4 shows the serialization delays of various packet sizes on increasingly faster links.

Table 1-4 Serialization Delays at Various Clocking Speeds

A maximum of 10 ms serialization delay is the recommended target to use for setting fragmentation size, as this allows adequate time for end-to-end delay required by voice (150-200 ms).

7464

4

Serialization Delay =Frame Size

Before

Link Speed

After using LFI Tools

Data Data Voice Data

60 Byte Voice 1500 Byte Data Frame214 ms Serialization Delay

for 1500 Byte Frame at 56 kbps

Link SpeedDelay at 64 Bytes

Delay at 128 Bytes

Delay at 256 Bytes

Delay at 512 Bytes

Delay at 1024 Bytes

Delay at 1500 Bytes

56kbps 9 ms 18 ms 36 ms 72 ms 144 ms 214 ms64kbps 8 ms 16 ms 32 ms 64 ms 128 ms 187 ms128kbps 4 ms 8 ms 16 ms 32 ms 64 ms 93 ms256kbps 2 ms 4 ms 8 ms 16 ms 32 ms 46 ms512kbps 1 ms 2 ms 4 ms 8 ms 16 ms 23 ms768kbps 640 s 1.28 ms 2.56 ms 5.12 ms 10.4 ms 15 ms1-24Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Compressed Real-Time Protocol

RTP is the Internet Standard (RFC 1889) protocol for the transport of real-time voice and/or video. At 40 bytes total, the header portion of an RTP packet is considerably large and can account for nearly two-thirds or the entire packet. For example, G.729 VoIP payloads are only 20 bytes when sampled at 20 ms.

Tip For more information on RFC 1889, see RTP: A Transport Protocol for Real-Time Applications.

To avoid the unnecessary consumption of available bandwidth, cRTP can be used on a link-by-link basis. cRTP compresses IP/UDP/RTP headers from 40 bytes to between 2 and 5 bytes. Such compression is illustrated in Figure 1-16.

Figure 1-16 IP/UDP/RTP Header Compression

Note Distributed RTP Header Compression (dCRTP) is the distributed counterpart of cRTP.

Compression techniques minimize bandwidth requirements and are highly useful on slow-links. Due to the additional CPU loads these compression techniques require, they need to be used with caution, especially in scenarios with many remote sites attaching to a central WAN Aggregation router. For more information on when to use cRTP, see Appendix A, Reference Information.

Tip For more information on cRTP, see Configuring Compressed Real-Time Protocol.

TX Ring

The transmit (TX) ring is a FIFO queue located just prior to the physical interface. Its purpose is to hold packets prior to the physical interface to insure that a packet will be available when the interface is ready to transmit traffic. It is the unprioritized, final buffer used to hold frames prior to transmission in order to drive link utilization to 100%. The placement of the TX ring in the Layer 2 queueing subsystem is shown in Figure 1-10.

UDP HDR RTP HeaderIP Header

20 Bytes 8 Bytes 12 Bytes

2-5 Bytes 8104


956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Call Admission Control

After performing the calculations to provision the network with the required bandwidth to support voice, video and data applications, it's important to ensure that voice or video do not oversubscribe the portion of the bandwidth allocated to them. While most QoS mechanisms are used to protect voice from data, Call Admission Control (CAC) is used to protect voice from voice (and video from video). CAC is illustrated in Figure 1-17, which shows an environment where the network has been provisioned to support only two voice calls. However, if a third voice call is attempted, the quality of all calls will degrade.

Figure 1-17 Call Admission ControlProtects Provisioned Bandwidth for Voice from Voice

Tip A detailed discussion of CAC is not in the scope of this document, but it is and important consideration in successful AVVID rollouts. The details of CAC are covered in the Call Admission Control chapter of the IP Telephony Solution Reference Network Design Guide.

Management ToolsImplementing a QoS solution is not a one-time task that is complete upon policy deployment. A successful QoS deployment is followed by ongoing monitoring of service levels and periodic adjustments and tuning of QoS policies, as shown in Figure 1-18.

IP IP IP

IP WAN

8103

2

V

M

IP WAN link provisioned for 2 VoIP calls

CAC limits number of VoIP calls on each WAN link

No physical limitation on IP links.If third call accepted, voice qualityof all calls degrades.

CallManager

IP WANlink

Router/Gateway1-26Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?Figure 1-18 Quality of Service Management Cycle

Short-term monitoring is useful for verifying that the deployed QoS policies are having the desired end-to-end effect. Long-term monitoring, or trending, is needed to determine whether the provisioned bandwidth is still adequate for changing needs. For example, upgrading to a newer version of an application may cause the provisioned bandwidth to be exceeded (as would the addition of new users). Furthermore, business objective themselves may change, and periodically the overall ranking of priority of applications may need revision.Monitoring and adapting QoS policies to such business changes is efficiently done through QoS Management solutions.

7464

8

Mo

nitor

Clas

sify

Adjust Service Levels1-27Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?1-28Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Cisco AVVID Network Infrastructure956467

variation because it is easy to illustrate how network performDelay-sensitive applications, like video-conferencing over IPERP applications or mainframe SNA applications, have similadversely affected by packet loss, delay, and delay variation.ance can adversely affect voice quality. , and mission critical applications, like ar requirements of the network and are C H A P T E R

2QoS Considerations When Connecting End-Points to an AVVID Network

This chapter provides information about implementing QoS at the edge of an AVVID network. It includes the following:

Overview The Trusted Edge IP Telephony

Video Mission-Critical Applications Summary

Note This chapter contains references to other documents. These references are included as tips in the text. The URL for each referenced document is located in Appendix A, Reference Information. In some cases, an internal document is referenced. For copies of internal documents, please see your Cisco Systems representative.

OverviewClassification (or marking) of traffic at the edge of the network (where CPU resources are plentiful and scalability of classification services is not an issue) is a requirement that needs to be addressed in today's enterprise networking environments. This chapter focuses on the design requirements at the edge of the network needed to classify traffic so that devices throughout the network can recognize loss, delay, and delay variation sensitive applications and give them the appropriate treatment end-to-end.Throughout this chapter VoIP traffic will be used to illustrate how QoS can limit loss, delay, and delay 2-1 Enterprise Quality of Service Design

Chapter 2 QoS Considerations When Connecting End-Points to an AVVID NetworkThe Trusted EdgeThe Trusted EdgeWhen classifying traffic types in an enterprise networking environment, a trust boundary must be established. A trust boundary is the point at which classification of traffic is either applied by the device allowing traffic into the network or the device allowing traffic into the network trusts classification that has been applied by the end station. Today's enterprise switch platforms have the ability to trust CoS in an 802.1Q/p environment or DSCP or IP Precedence in an environment where more granularity is required or where 802.1Q/p is not available. It is desirable to have traffic classified by the signaling device itself and use trust as the traffic enters the network, as is the case with Cisco IP phones and voice gateways. However, there are places in the network where due to the need for administrative control or the lack of end station capabilities classification or marking at the edge is required.Chapter 3, QoS in an AVVID-Enabled Campus Network contains detailed configuration examples for the various platforms that have classifica

QOS SRND Aug 02

Documents

Transcript of QOS SRND Aug 02