• Tidak ada hasil yang ditemukan

End to End QoS Network Design Quality of Service in LANs, WANs, and VPNs pdf pdf

N/A
N/A
Protected

Academic year: 2019

Membagikan "End to End QoS Network Design Quality of Service in LANs, WANs, and VPNs pdf pdf"

Copied!
827
0
0

Teks penuh

(1)

By Tim Szigeti - CCIE No. 9794, Christina Hattingh

Publisher: Cisco Press

Pub Date: November 09, 2004

ISBN: 1-58705-176-1

Pages: 768

Best - pract ice QoS designs for prot ect ing voice, video, and crit ical dat a while m it igat ing net work denial- of- service at t acks

Underst and t he service- level requirem ent s of voice, video, and dat a applicat ions

Exam ine st rat egic QoS best pract ices, including Scavenger- class QoS t act ics for DoS/ worm m it igat ion

Learn about QoS t ools and t he various int erdependencies and caveat s of t hese t ools t hat can im pact design considerat ions

Learn how t o prot ect voice, video, and dat a t raffic using various QoS m echanism s

Evaluat e design recom m endat ions for prot ect ing voice, video, and m ult iple classes of dat a while m it igat ing DoS/ worm at t acks for t he following net work infrast ruct ure archit ect ures: cam pus LAN, privat e WAN, MPLS VPN, and I PSec VPN

Qualit y of Service ( QoS) has already proven it self as t he enabling t echnology for t he convergence of voice, video, and dat a net works. As business needs evolve, so do t he dem ands for QoS. The need t o prot ect crit ical applicat ions via QoS m echanism s in business net works has escalat ed over t he past few years, prim arily due t o t he increased

frequency and sophist icat ion of denial- of- service ( DoS) and worm at t acks.

End- t o- End QoS Net work Design is a det ailed handbook for planning and deploying QoS solut ions t o address current business needs. This book goes beyond discussing available QoS t echnologies and considers det ailed

design exam ples t hat illust rat e where, when, and how t o deploy various QoS feat ures t o provide validat ed and t est ed solut ions for voice, video, and crit ical dat a over t he LAN, WAN, and VPN.

The book st art s wit h a brief background of net work infrast ruct ure

evolut ion and t he subsequent need for QoS. I t t hen goes on t o cover t he various QoS feat ures and t ools current ly available and com m ent s on t heir

By Tim Szigeti - CCIE No. 9794, Christina Hattingh

Publisher: Cisco Press

Pub Date: November 09, 2004

ISBN: 1-58705-176-1

Pages: 768

Best - pract ice QoS designs for prot ect ing voice, video, and crit ical dat a while m it igat ing net work denial- of- service at t acks

Underst and t he service- level requirem ent s of voice, video, and dat a applicat ions

Exam ine st rat egic QoS best pract ices, including Scavenger- class QoS t act ics for DoS/ worm m it igat ion

Learn about QoS t ools and t he various int erdependencies and caveat s of t hese t ools t hat can im pact design considerat ions

Learn how t o prot ect voice, video, and dat a t raffic using various QoS m echanism s

Evaluat e design recom m endat ions for prot ect ing voice, video, and m ult iple classes of dat a while m it igat ing DoS/ worm at t acks for t he following net work infrast ruct ure archit ect ures: cam pus LAN, privat e WAN, MPLS VPN, and I PSec VPN

Qualit y of Service ( QoS) has already proven it self as t he enabling t echnology for t he convergence of voice, video, and dat a net works. As business needs evolve, so do t he dem ands for QoS. The need t o prot ect crit ical applicat ions via QoS m echanism s in business net works has escalat ed over t he past few years, prim arily due t o t he increased

frequency and sophist icat ion of denial- of- service ( DoS) and worm at t acks.

End- t o- End QoS Net work Design is a det ailed handbook for planning and deploying QoS solut ions t o address current business needs. This book goes beyond discussing available QoS t echnologies and considers det ailed

design exam ples t hat illust rat e where, when, and how t o deploy various QoS feat ures t o provide validat ed and t est ed solut ions for voice, video, and crit ical dat a over t he LAN, WAN, and VPN.

The book st art s wit h a brief background of net work infrast ruct ure

(2)

evolut ion and direct ion. The QoS requirem ent s of voice, int eract ive and st ream ing video, and m ult iple classes of dat a applicat ions are present ed, along wit h an overview of t he nat ure and effect s of various t ypes of DoS and worm at t acks. QoS best - pract ice design principles are int roduced t o show how QoS m echanism s can be st rat egically deployed end- t o- end t o address applicat ion requirem ent s while m it igat ing net work at t acks. The next sect ion focuses on how t hese st rat egic design principles are applied t o cam pus LAN QoS design. Considerat ions and det ailed design

recom m endat ions specific t o t he access, dist ribut ion, and core layers of an ent erprise cam pus net work are present ed. Privat e WAN QoS design is discussed in t he following sect ion, where WAN- specific considerat ions and det ailed QoS designs are present ed for leased- lines, Fram e Relay, ATM, ATM- t o- FR Service I nt erworking, and I SDN net works. Branch- specific designs include Cisco( r) SAFE recom m endat ions for using Net work- Based Applicat ion Recognit ion ( NBAR) for known- worm ident ificat ion and policing. The final sect ion covers Layer 3 VPN QoS design- for bot h MPLS and I PSec VPNs. As businesses are m igrat ing t o VPNs t o m eet t heir wide- area net working needs at lower cost s, considerat ions specific t o t hese t opologies are required t o be reflect ed in t heir cust om er- edge QoS

designs. MPLS VPN QoS design is exam ined from bot h t he ent erprise and service provider's perspect ives. Addit ionally, I PSec VPN QoS designs cover sit e- t o- sit e and t eleworker cont ext s.

Whet her you are looking for an int roduct ion t o QoS principles and

pract ices or a QoS planning and deploym ent guide, t his book provides you wit h t he expert advice you need t o design and im plem ent com prehensive QoS solut ions.

This book is part of t he Net working Technology Series from Cisco Press, which offers net working professionals valuable inform at ion for const ruct ing efficient net works, underst anding new t echnologies, and building

(3)

By Tim Szigeti - CCIE No. 9794, Christina Hattingh

Publisher: Cisco Press

About the Technical Editors Acknowledgments A Brief Historical Perspective QoS Evolution

User Network Expectations Understanding QoS QoS Models

Introduction to the QoS Toolset Simplifying QoS

If I Have AutoQoS, Why Should I Be Reading This Book? The Continuing Evolution of QoS

Summary

QoS Requirements of the Control Plane Scavenger Class

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

(4)

Further Reading Understanding Scheduling and Queuing Legacy Layer 3 Queuing Mechanisms

Currently Recommended Layer 3 Queuing Mechanisms Layer 2 Queuing Tools

Weighted Random Early Detection

DSCP-Based Weighted Random Early Detection Explicit Congestion Notification

Summary Further Reading

(5)

Gatekeeper CAC

RSVP

Summary Further Reading

Chapter 10. Catalyst QoS Tools Generic Catalyst QoS Models Catalyst 2950 Upstream Versus Downstream QoS

IEEE 802.11 DCF Call-Signaling TCP/UDP Ports in Use Access-Edge Trust Models

Catalyst 2950 QoS Considerations and Design Catalyst 3550 QoS Considerations and Design

Catalyst 2970/3560/3750 QoS Considerations and Design Catalyst 4500-SupII+/III/IV/V QoS Considerations and Design Catalyst 6500 QoS Considerations and Design

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

WAN Edge Classification and Provisioning Models WAN Edge Link-Specific QoS Design

Case Study: WAN Aggregation Router QoS Design Summary

(6)

Chapter 14. Branch Router QoS Design Branch WAN Edge QoS Design Branch Router LAN Edge QoS Design Case Study: Branch Router QoS Design Summary

Further Reading Part V: VPN QoS Design

Chapter 15. MPLS VPN QoS Design Where Is QoS Needed over an MPLS VPN? Customer Edge QoS Design Considerations Provider-Edge QoS Considerations

Core QoS Considerations

Case Study: MPLS VPN QoS Design (CE/PE/P Routers) Summary

Further Reading

Chapter 16. IPSec VPN QoS Design Site-to-Site V3PN QoS Considerations Site-to-Site V3PN QoS Designs

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

Teleworker V3PN QoS Designs Case Study: IPSec VPN QoS Design Summary

Further Reading

(7)

Copyright

elect ronic or m echanical, including phot ocopying, recording, or by any inform at ion st orage and ret rieval syst em , wit hout writ t en perm ission from t he publisher, except for t he inclusion of brief quot at ions in a review.

Print ed in t he Unit ed St at es of Am erica 1 2 3 4 5 6 7 8 9 0

First Print ing Oct ober 2004

Library of Congress Cat aloging- in- Publicat ion Num ber: 2003111984

Tr a de m a r k Ack n ow le dgm e n t s

All t erm s m ent ioned in t his book t hat are known t o be t radem arks or service m arks have been appropriat ely capit alized. Cisco Press or Cisco Syst em s, I nc., cannot at t est t o t he accuracy of t his inform at ion. Use of a t erm in t his book should not be regarded as affect ing t he validit y of any t radem ark or service m ark.

W a r n in g a n d D iscla im e r

This book is designed t o provide inform at ion about Qualit y- of- Service net work design best - pract ice recom m endat ions. Every effort has been m ade t o m ake t his book as com plet e and as accurat e as possible, but no warrant y or fit ness is im plied.

The inform at ion is provided on an " as is" basis. The aut hors, Cisco Press, and Cisco Syst em s, I nc., shall have neit her liabilit y nor responsibilit y t o any person or ent it y wit h respect t o any loss or dam ages arising from t he inform at ion cont ained in t his book or from t he use of t he discs or program s t hat m ay accom pany it .

The opinions expressed in t his book belong t o t he aut hor and are not necessarily t hose of Cisco Syst em s, I nc.

(8)

Cisco Press offers excellent discount s on t his book when ordered in quant it y for bulk purchases or special

At Cisco Press, our goal is t o creat e in- dept h t echnical books of t he highest qualit y and value. Each book is craft ed wit h care and precision, undergoing rigorous developm ent t hat involves t he unique expert ise of m em bers from t he professional t echnical com m unit y.

Readers' feedback is a nat ural cont inuat ion of t his process. I f you have any com m ent s regarding how we could im prove t he qualit y of t his book or ot herwise alt er it t o bet t er suit your needs, you can cont act us t hrough e- m ail at feedback@ciscopress.com. Please m ake sure t o include t he book t it le and I SBN in your m essage.

We great ly appreciat e your assist ance.

Publisher John Wait

Developm ent Edit or Howard A. Jones

Copy Edit or Krist a Hansing

Technical Edit ors Frank Knox

Anna To

Connie Varner

Team Coordinat or Tam m i Barnet t

Cover Designer Louisa Adair

Com posit ion Oct al Publishing, I nc.

I ndexer Eric Schroeder

(9)

Cor por a t e H e a dqu a r t e r s

Cisco Syst em s I nt ernat ional BV Haarlerbergpark

Cisco Syst em s has m ore t han 200 offices in t he following count ries and regions. Addresses, phone num bers, and fax num bers are list ed on t he Cisco.com W e b sit e a t w w w .cisco.com / go/ office s.

(10)

Sweden • Swit zerland • Taiwan • Thailand • Turkey • Ukraine • Unit ed Kingdom • Unit ed St at es • Venezuela • Viet nam • Zim babwe

Copyright © 2003 Cisco Syst em s, I nc. All right s reserved. COP, CCSP, t he Cisco Arrow logo, t he Cisco Powered Net work m ark, t he Cisco Syst em s Verified logo, Cisco Unit y, Follow Me Browsing, Form Share, iQ Net Readiness Scorecard, Net working Academ y, and Script Share are t radem arks of Cisco Syst em s, I nc.; Changing t he Way We Work, Live, Play, and Learn, The Fast est Way t o I ncrease Your I nt ernet Quot ient , and iQuick St udy are service m arks of Cisco Syst em s, I nc.; and Aironet , ASI ST, BPX, Cat alyst , CCDA, CCDP, CCI E, CCNA, CCNP, Cisco, t he Cisco Cert ified I nt ernet work Expert logo, Cisco I OS, t he Cisco I OS logo, Cisco Press, Cisco Syst em s, Cisco Syst em s Capit al, t he Cisco Syst em s logo, Em powering t he I nt ernet Generat ion, Ent erprise/ Solver, Et herChannel, Et herSwit ch, Fast St ep, GigaSt ack, I nt ernet Quot ient , I OS, I P/ TV, iQ Expert ise, t he iQ logo, Light St ream , MGX, MI CA, t he Net workers logo, Net work Regist rar, Packet, PK, Post - Rout ing, Pre- Rout ing, Rat eMUX, Regist rar SlideCast , SMARTnet , St rat aView Plus, St rat m , Swit chProbe, TeleRout er, TransPat h, and VCO are regist ered t radem arks of Cisco Syst em s, I nc. and/ or it s affiliat es in t he U.S. and cert ain ot her count ries.

All ot her t radem arks m ent ioned in t his docum ent or Web sit e are t he propert y of t heir respect ive owners. The use of t he word part ner does not im ply a part nership relat ionship bet ween Cisco and any ot her com pany. ( 0303R)

Print ed in t he USA

Dedications

Tim : This book is obviously dedicat ed t o m y wife; ot herwise, of course, she'd kill m e. I t am uses m e t o t hink t hat if ot hers are act ually reading t his, t hey probably t hink I 'm only j okingbut , alas, t he Greek capacit y for vengeance is no laughing m at t er. I cancelled far t oo m any dat es, st ayed in m y office and labs far t oo m any weekends, and st ared blankly int o space ( t hinking about t hese designs) far t oo m any t im es ( while she was t alking t o m e) t o ever allow t he t hought of not dedicat ing t his work t o her t o even cross m y t iny xeno- brain.

I know, I know, it 's not a work of lit erat ure or a collect ion of poet ry: I t 's j ust a t echnical bookboring t o t ears for any not int erest ed in t he subj ect ( and probably j ust boring t o yawns for t he rest ) . But , for what ever it 's wort h, I 'm dedicat ing it t o you, Lella. I love you wit h all m y heart .

(11)

About the Authors

Tim Sz ige t i, CCI E N o. 9 7 9 4, at t ended t he Universit y of Brit ish Colum bia, where he m aj ored in

m anagem ent inform at ion syst em s. Aft er graduat ing, Tim j oined Cisco Syst em s and soon aft er began t o specialize in Qualit y- of- Service t echnologies, support ing t echnical m arket ing init iat ives for t he Cisco Class Dat a acquisit ion, which led t o t he Cisco QoS Policy Manager ( QPM) product . Aft er support ing QPM t hrough several generat ions and serving as product m anager for t he Cisco Qualit y of Service Device Manager ( QDM) product , Tim j oined t he Ent erprise Solut ions Engineering t eam and led large- scale t est ing init iat ives of cam pus, WAN, and VPN QoS designs. Tim now belongs t o t he newly form ed Technology Solut ions Engineering t eam wit hin t he Cisco Cent ral Technical Market ing organizat ion. There, he cont inues t o define and drive st rat egic QoS solut ions across Cisco t echnology groups and business unit s while

working wit h m any Fort une 500 com paniesbot h ent erprise and service providersproviding QoS design expert ise.

(12)

About the Technical Editors

Fr a n k Kn ox has m ore t han 37 years of t elecom m unicat ions experience. During his career at I BM, Frank held posit ions in field service, field support , service planning, and educat ion; his final posit ion before ret irem ent was curriculum m anager for I BM's Net work Educat ion in Nort h Am erica. Aft er leaving I BM, Frank held t he posit ion of net work engineering m anager for GTE Direct ories, where he was responsible for t he com pany's voice and dat a net work design and support . Concurrent wit h his work at I BM and GTE, Frank t aught as an adj unct professor for t he Universit y of Dallas MBA program . For t he past six years, Frank has worked for Skyline Com put er as a senior inst ruct or and consult ant ; he is current ly Skyline's chief t echnical officer ( CTO) . Frank holds t wo CCI E cert ificat ions ( R&S and SNA/ I P) ; he also has a m ast er's degree in t elecom m unicat ions from Pace Universit y.

An n a To has worked wit h Cisco for m ore t han t hree years as a soft ware/ deploym ent engineer on t he I TD QoS t eam . One of Anna's key t asks is t o prom ot e QoS deploym ent and increase t he underst anding of QoS t echnology in t he field. Anna works on t he Modular QoS CLI ( MQC) solut ion t eam t o bring consist ency in QoS configurat ion across various Cisco plat form s. I n addit ion, Anna is involved wit h t he Aut oQoS proj ect t o sim plify QoS deploym ent .

(13)

Acknowledgments

Thanks also t o Neil Anderson, Joel King, Ted Hannock, and St eve Ochm anski for guidance and

collaborat ion on I PSec V3PN designs. Thanks for let t ing m e leverage your excellent and t horough work so t hat I did not t o have t o reinvent t he wheel on t hese designs.

Thank you, Mike Herbert , for your brilliant flash of using QoS for DoS/ worm m it igat ion via t he Scavenger class. Though you derailed and post poned m any whit epapers and publicat ions ( including t his one) , you opened up a whole new scope of applicat ion for QoS t echnologiesand we're all bet t er off for it .

Thank you, t oo, Alex Dolan, for building out m ult iple large- scale MPLS VPN t est beds for m e and

cont inually t weaking t hem t o suit m y m ood- of- t he- day. I don't know where your pat ience or your good nat ure com es from , but t hey're m ost appreciat ed. Thanks, t oo, for nudging m e back int o playing ice hockey. Next t im e I break a leg or chip a t oot h, I 'll t hink of you and grim ace.

Muchos gracias, Arlindo Callej as, for being m uch m ore t han m y awesom e lab adm inist rat or. You always went out of your way for m e and got m e everyt hing I ever neededinst ant ly. Som et im es I 'm afraid t o ask where you sourced t he gear you did. ( I 'm not sure whet her t hose 10GE linecards " fell off t he back of a Cisco t ruck" or what , but t hey sure cam e in handy at j ust t he right t im e.)

A round of applause is m erit ed by t he t echnical reviewers. Having done t his before m yself, I can genuinely appreciat e t he t im e, effort , and painst aking at t ent ion t o det ail t hat goes int o t his process. Frank, your com m ent s were right on and helped m ake t his a bet t er book. Anna, is t here anyt hing you don't know about Cisco QoS? I 'm very t hankful you t ook t im e out of your ext rem ely busy schedule, developing code while helping anyone and everyone on planet Eart h ( and som e nearby syst em s) t hat are having QoS problem s. And Connie, if you hadn't reviewed t his work, I would not have subm it t ed it for publicat ion. You're sim ply t he best t echnical reviewerand one of t he sharpest engineersI 've ever had t he pleasure of working wit h.

Thank you Howard Jones for your excellent edit ing and coordinat ing t he com plex cont ent review and copy review processes. And t hank you, t oo, Pat rick Kanouse for m anaging t he product ion of t his publicat ion and allowing m e t o m ake hundreds of last - m inut e edit s in t he galley- review phase ( when edit s are t o be kept at a m inim um ) . How you put up wit h m e I 'll never know, but I t ruly appreciat e your pat ience and desire t o help m ake t his book as correct and as current as possible. Also t hank you Chris Cleveland for your fine recom m endat ions and guidance during t he course of product ion.

(14)

you now t hat you've gone on t o bigger and bet t er t hings. ( I 'm so t errified of t he fut urewho's going t o m ake m e look good now?)

Bret t Bart ow, what can I say? This would never have happened wit hout you. Tim e and t im e again, it seem ed t o fall by t he wayside, but your persist ence, perseverance, and pat ience 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 t o your product ion t eam .

(15)
(16)

Command Syntax Conventions

The convent ions used t o present com m and synt ax in t his book are t he sam e convent ions used in t he Cisco I OS Com m and Reference. The Com m and Reference describes t hese convent ions as follows:

Boldfa ce indicat es com m ands and keywords t hat are ent ered lit erally as shown. I n act ual

configurat ion exam ples and out put ( not general com m and synt ax) , boldface indicat es com m ands t hat are input m anually by t he user ( such as a sh ow com m and) .

I t alics indicat es argum ent s for which you supply act ual values. Vert ical bars ( | ) separat e alt ernat ive, m ut ually exclusive elem ent s.

Square bracket s [ ] indicat e opt ional elem ent s.

Braces { } indicat e a required choice.

(17)

Introduction

QoS is a m at uring t echnology, one t hat m any net working professionals, t o a great er or lesser ext ent , are already fam iliar wit h. This is bot h a blessing and a curse. I t is a blessing because m ore adm inist rat ors are enabling QoS on t heir net works, which allows for t he convergence of voice, video, and dat a ont o a single I P net work, am ong ot her business advant ages. I t is a curse because alm ost every individual wit h whom I 've ever discussed QoS designs has a slight ly different opinion on how QoS should be enabled.

The result oft en has led t o confusing babble from t he cust om er's perspect ive, especially for cust om ers seeking QoS design guidance for non- VoI P applicat ions. For exam ple, a cust om er m ight ask t he local Cisco Syst em s engineer how best t o enable QoS for net works and receive one answer. Lat er, t he cust om er m ight at t end an Execut ive Briefing session in San Jose and receive a different answer ( even receiving m ult iple different answers wit hin t he sam e day from different present ers) . Lat er, while at t ending a Net workers conference, t he cust om er m ight be t old som et hing else ent irely. Finally, when t he cust om er get s hom e and picks up a Cisco Press book, he or she m ight get st ill anot her st ory. Confused and

frust rat ed, m any cust om ers decide t o enable m inim al QoS, if any, despit e t he t out ed benefit s t hat t hey were sold on. Therefore, in m y opinion, present ing such inconsist ent recom m endat ions is a m aj or disservice t o our cust om ers and a considerable barrier t o t he widespread deploym ent of QoS.

The Cisco Technology Baseline com m it t ees were creat ed t o rem edy t he sit uat ion and help unify various t echnologies across Cisco product s and plat form s. To t his end, a series of Technology Baselines were developed int ernally by our leading expert s ( m any of whom likewise developed t he relat ed I ETF RFCs and ot her st andards) t o which all Cisco product s and feat ures m ust conform . Addit ionally, t hese docum ent s provide uniform , st rat egic recom m endat ions ( t hat can be shared wit h cust om ers) t o help ensure t hat QoS recom m endat ions are unified and consist ent , for bot h ent erprises and service providers. Specific t o QoS, t he QoS Baseline st rict ly defines t he Cisco st rat egic direct ion in QoS t echnologies from now int o t he foreseeable fut ure.

Thus, a unique feat ure of t his book is t hat it is t he first Cisco Press publicat ion t o present design recom m endat ions t hat are com pliant wit h t he QoS Baseline.

Anot her huge advant age of t his publicat ion is t hat it is one of t he first docum ent s t o present a det ailed, cohesive st rat egy t hat shows how QoS can ext end beyond it s t radit ional role ( of priorit izing im port ant applicat ions) and be used t o provide deferent ial services t o DoS/ worm - generat ed t raffic, t hus m it igat ing and cont aining t he collat eral dam age caused by such at t acks. This is a fresh perspect ive and cont ext for a t echnology t hat m any considered baked and done. Yet in such a role, t he crit ical int erdependency of Qualit y of Service, High- Availabilit y, and Securit y t echnologies becom es m anifest and holist ically prom ot es t he " Self- Defending Net works" business obj ect ive.

However, having a st rat egic direct ion and t act ical approaches for QoS designs is only half t he solut ion. An im port ant m ot t o t hat I like t o em phasize is: " I n t heory, t heory and pract ice are t he sam e." I t 's one t hing t o m ake a design recom m endat ion based on an assum pt ion t hat som et hing " should work." I t 's som et hing com plet ely different t o m ake a design recom m endat ion t hat has been verified in large- scale, com plex lab scenarios, such as provided by one of t he largest Cisco labs: t he Ent erprise Solut ions Engineering t est beds in Research Triangle Park, Nort h Carolina.

(18)

diligence has been done t o present working, t est ed configurat ionsincluding a rigorous t echnical reviewing process by som e of t he sharpest Cisco QoS engineershardware/ soft ware/ plat form - specific issues t hat didn't surface during our t est s m ay nonet heless exist , as m ay issues int roduced in newer releases of hardware/ soft ware dat ing from our t im e of t est ing.

Furt herm ore, t he recom m endat ions present ed in t his book are not t o be t aken as com m andm ent s or dict at es ( " Thou shalt configure t his or t hat " ) , but are sim ply best - pract ice design recom m endat ions t hat are t he result of ext ensive lab t est ing and cust om er deploym ent s. They should be viewed as t em plat es t hat can be m odified and t weaked t o cust om er- specific requirem ent s. Following t he 80/ 20 Paret o Rule, t hese design recom m endat ions should be viewed as 80 percent of t he solut ion, t o which t he rem aining 20 percent is up t o each cust om er t o com plet e and t ailor t o t heir individual needs and const raint s.

Here's an analogy of how t o view t hese design recom m endat ions: Given a business obj ect ive ( for

(19)

Who Should Read This Book?

Som e m ight ask, " Why should I read t his book? Especially when I have Aut oQoS?"

Cert ainly, Aut oQoS- VoI P is an excellent t ool for cust om ers whose obj ect ive is enabling QoS for VoI P ( only) on t heir cam pus and WAN infrast ruct ures, and Aut oQoS- Ent erprise is a fine t ool for enabling basic WAN-edge QoS for voice, video, and m ult iple classes of dat a. For cust om ers who have basic QoS needs and don't have t he t im e or desire t o learn or do m ore wit h QoS, Aut oQoS is definit ely t he way t o go.

However, it 's im port ant t o rem em ber where Aut oQoS cam e from . Aut oQoS t ools are t he result of QoS design guides t hat Cisco Technical Market ing Engineers ( including m yself) put t oget her based on large-scale lab t est ing. Aut oQoS- VoI P is t he product of our first " AVVI D QoS Design Guide," one of t he m ost popular and m ost downloaded t echnical whit epapers ever produced wit hin Cisco. Aut oQoS- Ent erprise is t he result of t he QoS Baseline coupled wit h our second- generat ion QoS Design Guide. This book

represent s our t hird- generat ion QoS Design Guide. And it is t he goal of t he aut hors t o drive t hese designs ( including DoS/ worm - m it igat ion st rat egies) int o fut ure releases of Aut oQoS. So, basically, what you are reading is t he proposed blueprint for t he next version of Aut oQoS.

When it com es t o any given t echnology, t here are really only t wo t ypes of people: t hose who are

int erest ed in t he t echnology and seek a t horough underst anding of t he relat ion of t he part s t o t he whole, and t hose who j ust want t o " t urn it on" and walk away. The form er are t he ones who will confident ly unleash t he t rue power of t he t echnology and push it t o it s lim it s; t he lat t er are t he ones who are usually hesit ant , t im id, and conservat ive in t heir use of t he t echnology, t ypically accom panied wit h m ediocre result s.

For exam ple, t here are t hose who enj oy looking under t he hood of a Ferrari and want t o know all t he det ails about how t he engine generat es it s beaut iful purring and power, and t here are ot hers who want only t o t urn it on, drive away, and look sexy. The form er group will drive m ore confident ly, boldly unleashing t he engine's t rem endous power and, t hus, pushing t he car t o it s lim it s.

(20)

Goals and Methods

The m ain goal of t his book is t o present t em plat es t hat address 80 percent or m ore of a cust om er's requirem ent of QoS in a part icular cont ext and archit ect ure ( LAN, WAN, VPN) . Addit ionally, t he rat ionales and considerat ions behind t he recom m endat ions are explained in det ail so t hat as t weaking is required, net work adm inist rat ors are well inform ed of t he t rade- offs involved.

A key approach t hat we've used t hroughout t his configurat ion- rich book is t o incorporat e inline

explanat ions of configurat ions. I n t his way, t he QoS- relevant com m ands are highlight ed and det ailed line-by- line t o illust rat e t he funct ion of each elem ent and how t hese part s m ake up t he whole solut ion.

To com plem ent t hese line- by- line design recom m endat ions, relat ed verificat ion com m ands are det ailed. These verificat ion com m ands are present ed in cont ext wit h t he design exam ples, and specific det ails of what t o look for in t he result ing out put are highlight ed. These verificat ion exam ples are, t herefore, significant ly richer in relevance t han m ost such exam ples present ed in Cisco docum ent at ion, and t hey allow net work adm inist rat ors t o confirm quickly whet her t he recom m ended designs have been deployed correct ly.

(21)

How This Book Is Organized

This book is divided int o t hree m ain part s: an int roduct ion and overview sect ion, a QoS t oolset review sect ion, and ( t he heart of t he book) a QoS design sect ion.

Ch a pt e r 1, " I n t r odu ct ion t o QoS," is an int roduct ion and brief hist ory of t he developm ent of QoS t echnologies, showing where t hese cam e from and t he direct ion t hey're headed in.

Ch a pt e r 2, " QoS D e sign Ove r vie w ," is an overview of QoS design. I t begins by det ailing t he service- level requirem ent s of voice, video, and dat a applicat ions, and it present s t he Scavenger-class DoS/ worm - m it igat ion st rat egy and high- level QoS best pract ices t hat will be det ailed in t he design chapt ers t o follow.

To set proper cont ext for t he design chapt ers, various QoS t ools are reviewed. This review is not indent ed t o serve as feat ure docum ent at ion, but it supplem ent s Cisco docum ent at ion t o highlight various

int erdependancies or caveat s for t hese t ools t hat at t im es im pact t he recom m ended QoS designs t hat follow. The QoS t oolset review sect ion, Chapt ers 3 t hrough 11, covers t he following t opics:

Ch a pt e r 3, " Cla ssifica t ion a n d M a r k in g Tools"This chapt er reviews Layer 2 m arking

m echanism s ( such as 802.1Q/ p, Fram e Relay Discard Eligibilit y, ATM Cell Loss Priorit y, and MPLS Experim ent al Values) and Layer 3 m arking m echanism s ( such as I P Precedence and Different iat ed Services Code Point s) .

Ch a pt e r 4, " Policin g a n d Sh a pin g Tools"This chapt er reviews t he t oken bucket algorit hm , which is t he basis for m ost policers and shapers. Bot h t wo- rat e and t hree- rat e policers are covered as are ATM and Fram e Relay t raffic shaping.

Ch a pt e r 5, " Con ge st ion - M a n a ge m e n t Tools"This chapt er reviews t he evolut ion of queuing m echanism s and focuses on Low- Lat ency Queuing and Class- Based Weight ed Fair Queuing. This chapt er highlight s t he int eroperat ion and int erdependencies of t hese m echanism s wit h ot her QoS m echanism s, such as link- fragm ent at ion and shaping t ools.

Ch a pt e r 6, " Con ge st ion - Avoida n ce Tools"This chapt er reviews t he Weight ed Random Early Det ect ion m echanism and shows how t his can be used t o provide Different iat ed Services wit hin an ( RFC 2597) Assured Forwarding t raffic class. This chapt er also shows how t his m echanism can be used t o set ( RFC 3168) I P Explicit Congest ion Not ificat ion bit s.

Ch a pt e r 7, " Lin k - Spe cific Tools"This chapt er reviews header- com pression t echniques ( such as TCP and RTP header com pression) and link- fragm ent at ion and int erleaving t echniques ( such as Mult ilink PPP Link Fragm ent at ion and I nt erleaving [ MLP LFI ] and Fram e Relay fragm ent at ion [ FRF.12] ) .

Ch a pt e r 8, " Ba n dw idt h Re se r va t ion "This chapt er reviews t he Resource Reservat ion Prot ocol ( RSVP) and shows how it can be applied t o adm ission cont rol and MPLS Traffic Engineering.

(22)

m easurem ent - based call adm ission cont rol ( CAC) m echanism s, including t he use of RSVP for CAC. The t ools reviewed in previous chapt ers can prot ect voice from dat a, but only CAC t ools can prot ect voice from voice.

Ch a pt e r 1 0, " Ca t a lyst QoS Tools"This chapt er reviews t he m ain classificat ion, m arking, m apping, policing, and queuing t ools available on t he current Cisco Cat alyst plat form s ( including t he Cat alyst 2950, 2970, 3550, 3560, 3570, 4500- Supervisors I I + t o V, and Cat alyst 6500 Supervisor 2 and Supervisor 720) .

Ch a pt e r 1 1, " W LAN QoS Tools"This chapt er reviews QoS m echanism s available for wireless access point s, including t he 802.11e Enhanced Dist ribut ed Coordinat ion Funct ion ( EDCF) and t he QoS Basic Service Set ( QBSS) .

When t he QoS t oolset is reviewed, t he cont ext is set for t he det ailed design recom m endat ions t hat follow. The next chapt erswhich com prise t he heart of t his bookcover t he QoS design recom m endat ions for

prot ect ing voice, video, and m ult iple classes of dat a while m it igat ing DoS/ worm at t acks for t he following net work infrast ruct ure archit ect ures:

Ch a pt e r 1 2, " Ca m pu s QoS D e sign "This design chapt er det ails access, dist ribut ion, and core layer considerat ions and designs for Cisco Cat alyst 2950, 2970, 3550, 3560, 3570, 4500 Supervisors I I I -V, and Cat alyst 6500 Supervisor 2 and Supervisor 720 series swit ches. Five separat e access- edge m odels are present ed, along wit h det ailed queuing/ dropping recom m endat ions on a per- plat form basis. Plat form - unique feat ures, such as t he Cat alyst 3550 per- Port / per- VLAN policing feat ure, t he Cat alyst 6500 PFC2 Dual- Rat e Policing feat ure, and t he PFC3 Per- User Microflow Policing feat ure, are highlight ed in cont ext .

Ch a pt e r 1 3, " W AN Aggr e ga t or QoS D e sign "This design chapt er det ails considerat ions and designs for low- speed ( 768 kbps) , m edium - speed ( > 768 kbps and T1/ E1) , and high- speed ( > T1/ E1) privat e WAN t opologies, such as leased lines, Fram e Relay, ATM, ATM- t o- Fram e Relay service int erworking, and I SDN.

Ch a pt e r 1 4, " Br a n ch Rou t e r QoS D e sign "This design chapt er det ails branch- specific considerat ions and designs, such as unidirect ional applicat ions, and branch- t o- cam pus t raffic classificat ion t hrough access list s and Net work- Based Applicat ion Recognit ion ( NBAR) . Branch-specific designs include Cisco SAFE recom m endat ions for using NBAR for known worm ident ificat ion and policing.

Ch a pt e r 1 5, " M PLS V PN QoS D e sign "This design chapt er det ails considerat ions and designs for bot h ent erprises ( t hat are m apping int o MPLS VPN service- provider [ edge] classes of service) and service providers ( t hat are provisioning edge and core classes of service) . Service provider designs also include det ails on how t o provision MPLS DiffServ Tunneling Modes ( Uniform , Short - Pipe, and Pipe) and an int roduct ion t o MPLS Traffic Engineering ( dem onst rat ing per- cust om er t raffic

engineering and per- cust om er/ per- applicat ion t raffic engineering t hrough MPLS DiffServ Traffic Engineering) .

Ch a pt e r 1 6, " I PSe c V PN QoS D e sign "This design chapt er det ails t he considerat ions and designs for deploying sit e- t o- sit e I PSec VPNs and for t eleworker I PSec VPNs ( which t raverse broadband m edia, such as cable and DSL) .

(23)

- QoS Tools

- The Cisco QoS Baseline

- QoS Best Pract ices

- Scavenger- Class QoS Design

- Cam pus QoS Design

- WAN QoS Design

- Branch QoS Design

- MPLS VPN QoS Design ( for Ent erprise Subscribers)

- MPLS VPN QoS Design ( for Service- Providers)

(24)

Part I: Introduction to QoS

Part I of t his book provides a brief background of t he evolut ion of QoS t echnologies and overviews

various current ly available QoS feat ures and t ools. The QoS requirem ent s of voice, video, and m ult iple classes of dat a applicat ions are present ed, along wit h an overview of t he nat ure and effect s of various t ypes of DoS and worm at t acks. QoS design principles are int roduced t o show how QoS m echanism s can be st rat egically deployed t o address applicat ion requirem ent s while m it igat ing such at t acks.

The chapt ers in t his part of t he book are as follows:

Chapt er 1 I nt roduct ion t o QoS

(25)

Chapter 1. Introduction to QoS

This chapt er provides a brief hist ory of bot h voice and dat a net work evolut ion, illust rat ing t he background of t he concept of Qualit y of Service ( QoS) . I t int roduces t he fundam ent al QoS concept s of I nt Serv and DiffServ t o set t he st age for t he lat er discussion of individual QoS m echanism s. The following t opics are int roduced and briefly discussed:

I nt Serv and DiffServ

QoS t ools cat egories

Modular QoS CLI

QoS Baseline

QoS classes

Aut om at ic QoS

(26)

A Brief Historical Perspective

A cent ury ago, t he public swit ched t elephone net work ( PSTN) st art ed building out a worldwide, circuit -swit ched net work. This net work consist ed of fixed- bandwidt h, dedicat ed circuit s and ideally was suit ed t o carrying real- t im e t raffic, such as voice. Som e five decades lat er, net working expert s from m ilit ary and educat ional environm ent s int roduced packet - swit ched net works t o circum vent any single point s of failure, com m on in circuit - swit ched net works. Packet swit ching chops t he inform at ion flow int o sm all chunks of dat a, which can be rout ed over independent pat hs t o t he sam e dest inat ion, analogous t o t he operat ion of t he post al syst em .

The resiliency of packet - swit ched net works caused a shift t oward connect ionless com m unicat ion prot ocols t hat can handle packet s t hat m ight arrive out of order. However, for m any dat a applicat ions, t his was not only com plicat ed t o design around, but it also was insufficient in m eet ing applicat ion needs. Thus,

connect ion- orient ed prot ocols such as X.25 and Syst em s Net work Archit ect ure ( SNA) , and lat er Fram e Relay and Asynchronous Transfer Mode ( ATM) , were developed. I n t hese prot ocols, a circuit ( perm anent or swit ched virt ual circuit , PVC or SVC) is defined over t he underlying connect ionless packet - swit ched net work t o handle a session of com m unicat ion bet ween t wo devices or endpoint s.

I n t heory, real- t im e com m unicat ions such as voice can use virt ual circuit s regardless of t he underlying net working t echnology. Several universit ies conduct ed m any experim ent s t o t his effect in t he 1970s. However, voice over virt ual circuit s did not becom e a com m ercial or pract ical realit y unt il t he rout ers and swit ches used in packet - swit ched net works gained t he CPU and m em ory power required t o drive packet st ream s at real- t im e speeds at cost - effect ive prices.

When processing power becam e available at affordable cost point s, ot her issues wit h carrying real- t im e com m unicat ions over a packet - swit ched net work m anifest ed t hem selves. For exam ple, when packet s are delayed or dropped en rout e because of buffer overflows or ot her m om ent ary failures, t he int elligent prot ocols in t he seven- layer I nt ernat ional Organizat ion for St andardizat ion ( I SO) m odel recover t he " session" t hrough t he use of error- det ect ion and correct ion capabilit ies, such as t im eout s and

ret ransm issions. Alt hough t hese recovery m et hods work well for dat a applicat ions, t hey fall far short of sat isfying t he needs of real- t im e inform at ion st ream s.

ATM was t he first general dat a- net working t echnology t o include a class of service concept at t he lower layers of com m unicat ions t ransport prot ocolst hat is, offering different t reat m ent s for different t ypes of t raffic ( prot ocols such as SNA already had t his concept at higher layers in t he st ack) . ATM m inim izes lat ency by defining fixed- lengt h cells, which can be swit ched in hardware. ATM also uses t he fam iliar concept s of PVCs and SVCs t o elim inat e rout ing delays by doing an init ial connect ion set up, aft er which all ot her packet s t hat belong t o t he st ream can be forwarded t o t he dest inat ion wit hout addit ional rout ing.

I t has been saidonly part ly facet iouslyt hat packet swit ching has been a 30- year failed experim ent . The at t ribut es t hat t he ATM archit ect ure st rived for are none ot her t han t hose of t he original circuit - swit ched PSTN: low lat ency, fixed circuit - based rout ing, predict able service levels, and inform at ion- order

(27)

I n an effort t o find a m ore effect ive solut ion t o support a com binat ion of voice and dat a, int egrat ed services offerings were int roduced. The t erm int egrat ed services ( as in I nt egrat ed Services Digit al

Net work [ I SDN] or t he I ETF I nt egrat ed Services [ I nt Serv] m odel) refers t o t he m ixing of different t ypes of t raffic, such as voice, video, and dat a, over a single packet - swit ched net work. I SDN, which is considered by som e t o be t he first foray int o an archit ect ure for converged net works, defines how dat a prot ocols can be carried over a circuit - swit ched infrast ruct ure t hat nat ively support s voice. The PSTN evolved slight ly wit h t he int roduct ion of I SDN. However, wit h t he except ion of a handful of count ries in Europe, I SDN never really t ook off. This was prim arily because of nont echnical reasons, such as t he pricing st rat egies t hat t he providers adopt ed.

I n t he lat e 1990s, I P won out as t he t echnology of choice for converged net works because of it s ease of use, ubiquit y, and advances in handling real- t im e t raffic.

The key enablers for I P net works t o converge successfully voice, video, and dat a over packet - swit ched infrast ruct ures were QoS t echnologies. QoS allows for t he different iat ed t reat m ent of dat a t raffic versus voice and ot her delay- sensit ive t raffic. I n ot her words, it allows t he net work t o include a syst em of

(28)

QoS Evolution

I P net works of t he m id- 1990s were invariably best - effort net works, and t he I nt ernet , as a whole, rem ains so t oday. Privat ely owned ent erprise and service provider net works, t hough, have been widely

t ransform ed from best - effort m odels t o m ore com plex different iat ed services m odels, m eaning t hat t he net work gives different applicat ions differing levels of service.

Figure 1- 1 shows t he broad st eps in t he evolut ion of QoS concept s since t he early 1990s.

Figu r e 1 - 1 . QoS Evolu t ion

The first at t em pt t o st andardize QoS cam e in t he m id- 1990s, when t he I nt ernet Engineering Task Force ( I ETF) published t he I nt egrat ed Services Request For Com m ent s ( I nt Serv RFCsst art ing wit h RFC 1633 in June 1994) . These RFCs cent ered on a signaling prot ocol called t he Resource Reservat ion Prot ocol ( RSVP) . RSVP signals bandwidt h and lat ency requirem ent s for each discret e session t o each node along a pat h ( logical circuit ) t hat packet s would t ake from t he sending endpoint t o t he receiving endpoint . I nit ially, RSVP required every node t o heed it s reservat ions, which was highly im pract ical over t he I nt ernet , on which servers, swit ches, and rout ers of every descript ion, vint age, and vendor coexist .

(29)

Services Code Point s ( DSCPs) , were defined along wit h specific per- hop behaviors ( PHBs) for key t raffic t ypes.

As t he I nt Serv and DiffServ m odels have evolved, t he general popularit y of one m et hod versus t he ot her has swung back and fort h ( as shown in Figure 1- 2) , and t heir coexist ence has becom e an ever- increasing st ruggle, wit h com m it t ed advocat es on bot h sides. Today t he debat es over t he advant ages of each

cont inue wit hout a clear, indust ry- wide agreed- upon resolut ion. The realizat ion has begun t hat neit her m et hod offers a com plet e solut ion and t hat elem ent s of bot h should be com bined t o provide t he m ost general m et hod applicable t o t he widest range of t raffic and applicat ion t ypes.

Figu r e 1 - 2 . I n t Se r v a n d D iffSe r v

A short definit ion of I nt Serv and DiffServ follows:

I nt Serv uses a flow- based concept coupled wit h a signaling prot ocol along t he packet pat h. The signaling prot ocol guarant ees t hat adequat e resources are available ( at each hop) for t he flow before adm it t ing t he flow ont o t he net work. I n init ial deploym ent s, t he I nt Serv m odel suffered from

scalabilit y issues because of t he m any flows t hat needed m anagem ent on net work backbones.

DiffServ uses packet m arkings t o classify and t reat each packet independent ly. Alt hough t his scales well ( which is probably why ent erprises and service providers deploy it m ore frequent ly) , it offers no specific bandwidt h guarant ees t o packet s t hat belong t o a flow and, t herefore, fails t o provide adm ission cont rol t o new flows.

Wit h no clear advant age t o eit her m odel, QoS m echanism s cont inue t o use a m ix of I nt Serv and DiffServ t echnologies t o offer t he breadt h of services required on net works. I nt Serv and DiffServ are discussed furt her in t he sect ion "QoS Models" lat er in t his chapt er.

(30)
(31)

User Network Expectations

The percept ion of how t he net work behaves, or how well it behaves, depends on how you look at it . End users, or consum ers, of t he net work m ight have a very different view of net work qualit y of service t han t he st aff m anaging t he net work.

End User

An end user's percept ion of QoS is t ypically subj ect ive and relat ive, and not easily m easurable.

End users perceive t he net work qualit y t hrough t heir end device and have cert ain expect at ions of

appropriat e service levels. For exam ple, t ypical users expect a voice call on a st andard phone t o be of t oll qualit y. Yet t hey do not expect t hat sam e qualit y level from a cell phone or a voice call spoken int o a m icrophone on a personal com put er. This is t he general expect at ion, regardless of t he fact t hat all t hree calls m ight be carried by t he sam e net work in t he sam e m anner.

The end user has no concept of and t ypically very lit t le int erest in t he capabilit ies of t he net works in bet weenunless, of course, t he qualit y of t he net work response is lacking. Therefore, end users' percept ion of t he qualit y of t he service t hat t hey receive is based on previously observed behavior on sim ilar devices ( exam ples include a PSTN phone call, a PBX phone call, a bank t eller applicat ion, and t he refresh of a web page display) and t he cost of t he service ( which, in an ent erprise net work, t he general end user perceives as $0) .

Information Technologies Management

I T m anagem ent perceives t he net work qualit y t hrough m anagem ent st at ist ics such as t hroughput , usage, percent age of loss, and user com plaint s. Expect at ions and " qualit y problem s" from an I T perspect ive t end t o be m ore absolut e and m easurable. ( For exam ple, t he one- way lat ency of m ore t han 150 m s is

unaccept able for a voice call, or a t ransact ion refresh t im e for a bank t eller applicat ion m ust be fewer t han 5 seconds.)

Service providers form alize t hese expect at ions wit hin service- level agreem ent s ( SLAs) , which clearly st at e t he accept able bounds of net work perform ance. Corporat e ent erprise net works t ypically do not have such form al SLAs, but t hey nevert heless m anage t heir net works on som e form of m easurem ent and

m onit oring. Som e ent erprise net works indeed m ight use SLAs of various levels of form alit y bet ween t he I T depart m ent and t he cust om er depart m ent s t hat t hey serve.

(32)

Understanding QoS

Appreciat ing what QoS t ools and m et hods do t o packet s in a net work is fundam ent al t o appreciat ing t he effect of individual QoS t ools discussed in lat er chapt ers, and ult im at ely underst anding t he net work designs and m et hods t hat const it ut e t he m at erial in t his book.

End-to-End QoS

Regardless of how it is m easured, QoS is a vit al elem ent in any converged net work. To ensure t he highest level of qualit y, however, QoS m ust be im plem ent ed across all areas of t he net work.

QoS is described apt ly by an age- old cliché: I t 's only as st rong as t he weakest link. Opt im ally, every device ( host , server, swit ch, or rout er) t hat handles t he packet along it s net work pat h should em ploy QoS t o ensure t hat t he packet is not unduly delayed or lost bet ween t he endpoint s. I t is a popular m yt h t hat QoS is applicable only t o slow- speed wide- area net works ( WANs) or t he I nt ernet . Test ing has shown t hat delay- sensit ive applicat ions, such as voice, suffer qualit y loss when QoS is not enabled on cam pus

devices, such as Cisco I P phones and Cisco Cat alyst swit ches.

Figure 1- 3 shows t he segm ent s of t he net work where QoS m ust be deployed in t he t ypical I P t elephony

ent erprise net work and what QoS t echniques are com m on in each segm ent .

Figu r e 1 - 3 . En a blin g QoS in a n En t e r pr ise N e t w or k

(33)

All Packets Are (Not) Equal

Net works wit hout QoS enabled are described as best - effort net works. Best - effort net work designs t reat all packet s as equally im port ant . Such net works work well if t here is enough CPU, m em ory, and bandwidt h t o handle im m ediat ely all t he packet s t raversing t he net work as t hey arrive ( in ot her words, at line rat e) . However, because t his is rarely t he case, t he following scenarios t end t o em erge:

User- based cont ent ion occurs when packet s from different users, user groups, depart m ent s, or even ent erprises cont end for t he sam e net work resources.

Applicat ion- based cont ent ion occurs when different applicat ions from t he sam e user or user group cont end wit h each ot her for lim it ed net work resources. These applicat ions m ight have different service requirem ent s from t he net work, as illust rat ed in Figure 1- 4.

Figu r e 1 - 4 . Applica t ion - Ba se d Con t e n t ion

To obt ain t he appropriat e levels of service from oft en scarce net work resources experiencing cont ent ion, t he fundam ent al concept of QoS m ust be appliednam ely, t hat all packet s are not equal. I n ot her words, t o resolve t he cont ent ion, packet s m ust be t reat ed wit h m anaged unfairness ( eit her preferent ially or

deferent ially) . I n ot her words, adm inist rat ive policies m ust be defined and deployed t hroughout t he

net work infrast ruct ure t o ensure t hat each node m akes consist ent decisions about t he relat ive im port ance of an individual packet ( or flow) and adj ust s it s packet - handling behavior accordingly.

(34)

The Challenges of Converged Networks

The high- level goal of QoS t echnologies in a converged net work is t o abst ract t he fact t hat t here is only one net work and t o m ake voice, video, and dat a convergence appear t ransparent t o t he end users. To achieve t his goal, QoS t echnologies allow different t ypes of t raffic t o cont end inequit ably for net work resources. Real- t im e applicat ions, such as voice or int eract ive video, can be given priorit y or preferent ial services over generic dat a applicat ionsbut not t o t he point t hat dat a applicat ions are st arving for

bandwidt h.

QoS is defined as t he m easure of a syst em 's service availabilit y and t ransm ission qualit y. Service

availabilit y is a crucial foundat ion elem ent of QoS. Before any QoS can be im plem ent ed successfully, t he net work infrast ruct ure should be designed t o be highly available. The t arget for high availabilit y is 99.999 percent upt im e, wit h only 5 m inut es of downt im e perm it t ed per year. The t ransm ission qualit y of t he net work is det erm ined by t he following fact ors:

Pa ck e t loss This is a com parat ive m easure of t he num ber of packet s fait hfully t ransm it t ed and received t o t he t ot al num ber t ransm it t ed, expressed as a percent age. Packet loss in t he cont ext of QoS does not relat e t o drops because of net work out ages or link flaps ( because t hese are a funct ion of a high- availabilit y net work design) , but inst ead relat es t o drops because of net work congest ion.

D e la y ( or la t e n cy) This is t he finit e am ount of t im e t hat it t akes a packet t o reach t he receiving endpoint aft er being t ransm it t ed from t he sending endpoint . I n t he case of voice, t his equat es t o t he am ount of t im e t hat it t akes for speech t o leave t he speaker's m out h and be heard by t he list ener's ear. This t im e period is t erm ed end- t o- end delay and is com prised of t wo com ponent s: fixed net work delay and variable net work delay.

I n dat a net works carrying voice, fixed net w ork delay furt her is broken down int o t he following: - Pa ck e t iz a t ion de la y The t im e required t o sam ple and encode voice or video signals int o packet s.

- Se r ia liz a t ion de la y The t im e required t o t ransm it t he packet bit s ont o t he physical m edia, based on t he clocking rat e of t he int erface.

- Pr opa ga t ion de la y The t im e required for t he elect rical/ opt ical pulses t o t raverse t he m edia en rout e t o t heir dest inat ion, based on t he laws of physics.

D e la y va r ia t ion ( or j it t e r ) Also known as int erpacket delay, t his is t he difference in t he end- t o-end delay bet ween sequent ial packet s. For exam ple, if one packet requires 100 m s t o t raverse t he net work from t he source endpoint t o t he dest inat ion endpoint , and t he following packet requires 125 m s t o m ake t he sam e t rip, t he delay variat ion would be calculat ed as 25 m s, as illust rat ed in Figure 1- 5.

(35)

Each end st at ion in a VoI P or video over I P conversat ion has a j it t er buffer, which is used t o sm oot h out t he variat ion in arrival t im es of dat a packet s t hat cont ain voice. Jit t er buffers can be fixed or adapt ive.

I nst ant aneous changes in arrival t im es of packet s t hat exceed t he j it t er buffer's capabilit y t o com pensat e result in j it t er buffer overruns and underruns.

- A j it t er buffer underrun occurs when t he arrival t im es of packet s increase t o t he point t hat t he j it t er buffer has been exhaust ed and cont ains no packet s for t he digit al signal processors ( DSP) t o process when it is t im e t o play t he next piece of voice or video, result ing in clips.

- A j it t er buffer overrun occurs when packet s cont aining voice or video arrive fast er t han t he j it t er buffer can accom m odat e. When t his happens, packet s are dropped when it is t im e t o play t he voice or video sam ples, result ing in degraded voice qualit y.

(36)

QoS Models

As briefly int roduced earlier, t here are t wo m odels for providing t he different iat ed levels of net work service required in converged net works: I nt Serv and DiffServ.

IntServ Overview

Think of best - effort I P service in t erm s of t he regular m ail ( snail- m ail) service. The m ail is delivered if and when it can be, but it also m ight be lost ( arriving at som e undet erm ined t im e in t he fut ure or not at all) . By com parison, I nt Serv is analogous t o a cust om m ail service, such as diplom at ic m ail or courier services, wit h cert ain param et ers regarding loss and delivery guarant eed.

More specifically, I nt Serv is a specificat ion of t he following:

What t he sender is sending ( rat e, m axim um t ransm ission unit [ MTU] , and so on) , as described by t he Transm ission Specificat ion ( TSpec)

What t he receiver needs ( bandwidt h, MTU, and so on) , as described by t he Receiver Specificat ion ( RSpec)

How t he signaling is perform ed on t he net work by t he sender and receiver ( t hat is, t he use of RSVP)

The fram ework of I nt Serv preserves t he end- t o- end sem ant ics of QoS for I P. Key endpoint s are t he sender and receiver applicat ions t hat request a desired service from t he net work for a set of flows, as defined by t he source address, dest inat ion address, t ransport prot ocol, source port , and dest inat ion port .

I nt Serv describes t hree m ain classes of service t hat an applicat ion can request :

Gu a r a n t e e d se r vice s ( RFC 2 2 1 2 ) Provides firm ( m at hem at ically provable) bounds on end- t o- end packet - queuing delays, m aking it possible t o provide a service t hat guarant ees bot h delay and bandwidt h

Con t r olle d loa d ( RFC 2 2 1 1 ) Provides t he applicat ion flow wit h a qualit y of service closely approxim at ing t he QoS t hat t he sam e flow would receive from an unloaded net work elem ent , but uses capacit y ( adm ission) cont rol t o ensure t hat t his service is received even when t he net work elem ent is overloaded

Be st - e ffor t se r vice Provides no service guarant ees of any t ype

The advant ages of t he I nt Serv m odel include t he following:

Concept ual sim plicit y, facilit at ing t he int egrat ion wit h net work policy adm inist rat ion

(37)

Call adm ission cont rol ( CAC) capabilit ies, which can indicat e t o endpoint s whet her t he desired bandwidt h is available

The disadvant ages of t he I nt Serv m odel include t hese:

All net work elem ent s m ust m aint ain st at e and exchange signaling m essages on a per- flow basis, which m ight require a significant am ount of bandwidt h on large net works.

Periodic refresh m essages are used, which m ight require prot ect ion from packet loss t o keep t he session( s) int act .

All int erm ediat e nodes m ust im plem ent RSVP.

DiffServ Overview

Cont inuing t he analogy of m ail services, DiffServ can be com pared t o different t iers of m ail service, such as regular, regist ered, priorit y, and express m ail. Each service offers part icular param et ers of delivery, and t he piece of m ail is st am ped at each int erm ediat e handling point t o ensure t hat it get s t he required service. However, t here is no specific connect ion bet ween t he sender of t he piece of m ail and t he t reat m ent t hat t he m ail receives.

The prem ise of DiffServ is very sim ple: I t offers different net work service levels t o a packet , t hereby " enable[ ing] scalable service discrim inat ion in t he I nt ernet wit hout t he need for per- flow st at e and signaling at every hop" ( RFC 2474) . Packet s of a part icular service belong t o a part icular " class," and t he t reat m ent of each " class" is described by PHBs wit h which t he net work node m ust com ply. Meaningful services can be const ruct ed by a com binat ion of t he following:

Set t ing a field in t he I P header upon net work ent ry or at a net work boundary ( I PP or DSCPs)

Using t his field t o det erm ine t he nodes inside t he net work forward t he packet s

Condit ioning t he m arked packet s at net work boundaries in accordance wit h t he requirem ent s or rules of each " class" or service

The essence of DiffServ is t he specificat ion of PHBs t hat an applicat ion can receive from t he net work:

Ex pe dit e d for w a r din g ( RFC 3 2 4 6 , pr e viou sly RFC 2 5 9 8 ) Provides a st rict - priorit y service ( com pare t his t o express m ail service)

Assu r e d for w a r din g ( RFC 2 5 9 7 ) Provides a qualified delivery guarant ee ( com pare t his t o regist ered m ail service) and m akes t he provision for oversubscript ion t o t his service ( specifically, m arkdown and dropping schem es for excess t raffic)

Cla ss se le ct or s ( RFC 2 4 7 4 ) Provides code point s t hat can be used for backward com pat ibilit y wit h I P Precedence m odels

(38)

DiffServ const ruct s services from t he PHBs by classifying packet s int o " classes" at t he edge, or boundary, of t he net work and m arking t he packet s accordingly. Opt ionally, t he packet s can be m et ered wit h policing or shaping t echniques. The core of t he net work im plem ent s t he PHBs and uses t he packet m arkings t o m ake queuing and dropping decisions.

The DiffServ m odel include t hese advant ages:

Sca la bilit y No st at e or flow inform at ion is required t o be m aint ained.

Pe r for m a n ce The packet cont ent s need be inspect ed only once for classificat ion purposes. At t hat t im e, t he packet is m arked and all subsequent QoS decisions are m ade on t he value of a fixed field in t he packet header, reducing processing requirem ent s.

I n t e r ope r a bilit y All vendors already are running I P.

Fle x ibilit y The DiffServ m odel does not prescribe any part icular feat ure ( such as a queuing

t echnique) t o be im plem ent ed by a net work node. The node can use what ever feat ures opt im ize it s hardware and archit ect ure, as long as it is consist ent wit h t he behavior expect at ion defined in t he PHBs.

The disadvant ages of t he DiffServ m odel include t he following:

No end- t o- end bandwidt h reservat ions are present ; t herefore, guarant ees of services can be

im paired by net work nodes t hat do not im plem ent t he PHBs appropriat ely over congest ed links or by nodes t hat are not engineered correct ly for t he expect ed t raffic volum e of a specific class.

(39)

Introduction to the QoS Toolset

A fair am ount of lit erat ure exist s on QoS concept s, t echnologies, and feat ures. The purpose of t his book is not t o reit erat e in dept h how t hese t ools work, but rat her t o show how t hese t ools int eract wit h each ot her and what com binat ion of t ools can be used t o achieve t he overall design obj ect ives of a net work. However, t o lay t he cont ext for t he designs set fort h in t his book, a brief overview of t he t oolset follows.

Generally, QoS t ools fall int o t he following cat egories:

Classificat ion and m arking t ools

Policing and shaping t ools

Congest ion- avoidance ( select ive dropping) t ools

Congest ion- m anagem ent ( queuing) t ools

Link- specific t ools

Figure 1- 6 illust rat es t he relat ionship and overall cohesiveness of different QoS t ools.

Figu r e 1 - 6 . QoS Toolse t

[View full size image]

(40)

should be given. This analysis is referred t o as classificat ion. Classificat ion is t he first QoS funct ion t o occur for any given QoS policy, and it can occur repeat edly at various st ages of policy enforcem ent . To reduce t he requirem ent for det ailed recursive classificat ion, it generally is recom m ended t hat t raffic t ypes be classified as close t o t heir sources as possible and t hat t heir packet s be m arked accordingly.

Marking est ablishes a dist inct t rust boundary t hat dem arcat es t he point where t he packet m arkings are set properly and, t herefore, det ailed classificat ion ( Layer 4 t hrough 7 analysis) no longer is required.

When packet s ent er a net work device, t hree generic m arking possibilit ies exist :

Packet s are unm arked.

Packet s are m arked, but t he m arkings are not t rust ed.

Packet s are m arked and t he m arkings are t rust ed.

I n t he first t wo scenarios, it is recom m ended t hat t he packet s be m arked or re- m arked.

Aft er m arking, t he next st ep is anot her classificat ion process based on packet m arkings. At t his point , packet s m ight be discarded by a policer ( for exam ple, if t hey exceed an SLA) or a congest ion- avoidance m echanism ( for exam ple, early dropping because buffers reached t he m axim um lim it ) . Packet s t hat are not discarded are subj ect t o congest ion m anagem ent ( queuing) t o priorit ize and prot ect various t raffic t ypes when congest ion happens t o t he t ransm ission link. Finally, t hese packet s are scheduled for t ransm ission on t he egress link, where shaping m ight occur t o cont rol burst s and ensure t hat out going t raffic conform s t o any SLA t hat is in effect on t he ingress of t he next hop.

Link- specific t ools usually are required only at WAN edges and include m echanism s for com pression or fragm ent at ion t o reduce delay and j it t er.

Som e QoS t ools ( such as m arking and policing) can be applied in bot h t he ingress and egress direct ions of t he t raffic flow on an int erface. Ot her t ools ( such as queuing) can be applied only in t he egress direct ion ( wit h som e plat form - specific except ions) .

The QoS m echanism s ( prim arily DiffServ) described previously are applicable t o packet s already adm it t ed t o t he net work. Such t ools are very effect ive in prot ect ing real- t im e ( voice) from non- real- t im e ( dat a) t raffic, but t hey are com plet ely ineffect ive in prot ect ing real- t im e applicat ions from ot her real- t im e

(41)

Simplifying QoS

I n t he lat e 1990s, Cisco spent significant developm ent effort t o im plem ent an ext ensive QoS t ool and feat ure set . The port folio of QoS m echanism s and opt ions becam e very rich and, sim ult aneously, very com plicat ed t o deploy. During t he early 2000s, t he predom inant cust om er feedback relat ing t o QoS was t he request t o sim plify QoS deploym ent . I n response t o t his feedback, a series of QoS sim plificat ion and aut om at ion proj ect s was init iat ed. The result included t he following:

The creat ion of a Modular QoS Com m and- Line I nt erface ( CLI )

The est ablishm ent of a QoS Baseline

Default behavior ( conform ing t o t he QoS Baseline)

Cross- plat form feat ure consist ency

Aut om at ic QoS ( Aut oQoS)

Modular QoS Command-Line Interface

The first st ep t oward sim plificat ion was t o m odularize t he configurat ion of QoS and m ake it consist ent across plat form s. To t his end, a new configurat ion synt ax, t erm ed Modular QoS Com m and- Line I nt erface ( MQC) , was int roduced in Cisco I OS Release 12.0( 5) T.

Three m ain com ponent s m ake up t he MQC:

cla ss- m a p A classificat ion filt er defined wit hin t he policy m ap t o ident ify t raffic for preferent ial or deferent ial t reat m ent . Traffic can be ident ified by I PP or DSCP, nam ed or num bered access cont rol list s ( ACLs) , Net work- Based Applicat ion Recognit ion ( NBAR) , Layer 2 param et ers ( CoS, FR DE, ATM cell loss priorit y [ CLP] , MPLS Experim ent al [ EXP] value) , or a com binat ion of t hese.

policy- m a p A st at em ent t hat defines how each t raffic t ype, as ident ified by t he class m ap( s) , should be serviced. Opt ions include m arking/ re- m arking, policing, shaping, low- lat ency or class-based weight ed fair queuing, select ive dropping, and header com pression.

se r vice - policy A st at em ent t hat binds t he policy t o an int erface and specifies direct ion.

Exam ple 1- 1 dem onst rat es a sam ple MQC policy. This is j ust an exam ple of a possible configurat ion; t he significance of t he com m ands used in t his exam ple is explained in subsequent chapt ers.

(42)

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

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

Router(config-cmap)# match protocol citrix

Alt hough MQC was a m aj or st ep in sim plifying QoS feat ures, it addressed only t he user int erface elem ent of QoS deploym ent . Anot her fact or in t he com plexit y of QoS deploym ent is t he inconsist ency of QoS feat ures across specific hardware plat form releases or soft ware releases.

I n 2002, a series of int ernal Cisco init iat ives, dubbed Technology Baselines, was launched t o address t he inconsist ency of which feat ures exist on which plat form s. Specific t o QoS, t he QoS Baseline is a st rat egic int ernal docum ent writ t en by Cisco's m ost qualified QoS expert s, each of whom had cont ribut ed t o m ult iple QoS RFCs and so was best qualified t o int erpret t hese st andards in addit ional det ail. The QoS Baseline was developed wit h t wo prim ary goals:

To docum ent which QoS feat ures are required on plat form s t hat are considered QoS- enabled product s

To provide a gap analysis of which feat ures, deem ed im port ant by t he baseline, exist ed on what plat form s

I n part , t he Cisco QoS Baseline is aim ed at producing higher- qualit y new product s, predict able QoS feat ure set s across product s, and im proved consist ency of QoS feat ures across plat form s. To t hat end, it provides engineers who are developing new product s wit h a reference list of QoS feat ures t hat t hey m ust include and t est . For exist ing plat form s, it provides a gap analysis t hat is used t o st eer product roadm aps t o achieve QoS baseline com pliance.

Beyond it s engineering influence, t he overall obj ect ive of t he QoS Baseline is t o unify QoS wit hin Cisco: from service provider t o ent erprise, from engineering t o m arket ing. For exam ple, t he concept of t raffic classificat ion inevit ably begs t he quest ion of how m any classes of t raffic t here should be. MQC support s up t o 256 different t raffic classes wit hin a policy m ap. Alt hough adept QoS adm inist rat ors m ight see t his as desirable, t hose who are new t o QoS and have no idea how m any classes of t raffic t hey need in t heir net works m ight view it as daunt ing.

To address t he needs of t he bot h expert and casual QoS users, t he QoS Baseline defines a set of class t em plat e recom m endat ions t hat can be eit her be im plem ent ed " as is" or cust om ized t o individual needs. I t gives a st art ing point for net work design and im plem ent at ion, and it provides a basis for com parable product t est ing and perform ance report ingbot h of which significant ly sim plify t he im plem ent at ion of QoS in a net work.

Gambar

Figure 1 -1 . QoS Evolution
Figure 1 -2 . I ntServ and DiffServ
Figure 1 -3 . Enabling QoS in an Enterprise Netw ork
Figure 1 -6 . QoS Toolset
+7

Referensi

Dokumen terkait

Hal ini sesuai dengan nilai TI yang telah dibahas pada bagian sebelumnya yaitu TI digunakan untuk menciptakan nilai agar meningkatkan pertumbuhan bisnis dan

Forward looking statements, by their nature, involve risk and uncertainty that could cause actual results and development to differ materially from those expressed or implied in

Reaksi hidrolisis dengan perbandingan selulosa/aquades 1:25 (w/v) dilakukan dalam autoklaf pada suhu 130 o C selama 3 jam. Hasil penelitian menunjukan konsentrasi asam sulfonat

Although CO 2 concentration gradients were greater in the Picea mariana stands, less light penetrated to the understory than in the Pinus banksiana stand, thus limiting

Main and interactive effects of photoperiod extension (PP), sowing date (SD) and cultivar (CV) on the chronological time (days), thermal time ( 8 C day) and accumulated solar

The ironstone facies occurs as matrix to diamictites and as massive to laminated ironstones and comprises abundant Fe oxides (hematite, magnetite) and quartz, minor

Terbentuknya Politeknik Kesehatan di lingkungan Kementerian Kesehatan, menuntut adanya penyelenggaraan pendidikan, penelitian dan pengabdian kepada masyarakat,

Untuk itu perlu diketahui faktor apa yang dapat memunculkan komitmen organisasi tersebut.Dalam hal ini, berdasarkan berbagai literatur, pemimpin, dalam hal ini