Tải bản đầy đủ - 0 (trang)
Chapter 9.  Call Admission Control (CAC)

Chapter 9.  Call Admission Control (CAC)

Tải bản đầy đủ - 0trang

otherareasbeyondthescopeofthisbook,suchascall-routing

algorithms(dialingplans)andcallpriorityandpreemption

capabilities,whichtypicallyinvolvemoreend-userknowledge

thantheinfrastructureofthenetworkhas.Acallagentorcall

servertypicallymakesthesetypesofdecisions.Ontheother

hand,thenetworkinfrastructureistheonlypartofthenetwork

thathastheknowledgeofexactresourceavailability,suchas

linkstatus,bandwidthavailability,andtrafficcongestionpoints,

sotheinfrastructureistherightplaceforthebasicCAC(admit

ordeny)decisions.Whenacallisnotadmitted,thecallagent

orcallservercanmakealternativeroutingdecisionsinother

words,thecallcanberedirectedtothePSTN.

ThescopeoftheCACdiscussioninthischapteristoprovidean

overviewofthebasicCACmechanismsandtounderscoretheir

importanceinQoSdesignforconvergednetworks.Thischapter

examinesthethreemostcommonmethodsRSVP,CallManager

locations,andH.323gatekeeperCACandprovidesabrief

overviewofotherCiscoIOSbasedtechniquesthatcanbeused

foraspectsofCAC.



CACOverview

AsdiscussedinChapter5,"Congestion-ManagementTools,"

andChapter6,"Congestion-AvoidanceTools,"dataapplications

arecontrolledbyresolvingcongestioninthenetworkinsteadof

applyingadmissionpolicies.Ifdataapplicationsencounter

congestion,packetstypicallyaredropped.Protocolssuchas

TCPhaveinherentdetection,recovery,andretransmissionlogic,

whichensuresthatthesessionisrecoveredfortheenduser.

Congestion-managementpoliciescannotbeappliedtoreal-time

applications,suchasvoiceandvideo-conferencing,andstill

maintainpredictablequality.Whenthepacketsthatbelongto

theseapplicationsareadmittedontothenetwork,theycannot

bedropped.TraditionalTDMapplicationssuchasvoice,modem,

fax,andvideocallsassumethatbandwidthisavailableanddo

notrecoverfromlostinformation.Becauseinformationarrivalis

sotimesensitive,thereisnopointinbuildingerror-detection

andrecoverymechanisms,suchasretransmissionlogic,into

thesereal-timeprotocols.Ifthepacketcannotbedelivered

withinasmallwindowoftime,itmightaswellneverarrive.

"Betterlatethannever"doesnotapplytoreal-timeflows.



CACDefined

Bydefinition,networkbandwidthisfinite,andpointsof

congestiondooccur.Bothreal-timeandnon-real-timetraffic

typesencounterthiscongestion.Ifpacketscannotbedropped

toresolvecongestion,packetflowsthatcausecongestion

shouldnotbeallowedontothenetwork.Thismakesthecase

forthedeploymentofCACtoolstheseare,inessence,the

congestion-avoidancemechanismsforreal-timeapplications.

Afteritisadmitted,areal-timeflowsuchasavoicecallmust

becarried;iftherearen'tsufficientbandwidthresourcesto

carrytheflowwithinthedelayandlossboundsofthe

application,theflowmustberejectedorredirectedbeforeitis

admittedintothenetwork.

AnotherwaytolookatCACisthatmostoftheQoStools

discussedthusfarinthisbookstrivetoprotectvoicetraffic

fromdatatraffic.CACtoolsprotectvoicetrafficfromothervoice

traffic(andinteractivevideofrominteractivevideo).For

example,ifthereissufficientbandwidthprovisionedthrough

LLQtocarryonlytwocallsacrossalink,admittingathirdcall

willcausepacketdropsandwillimpairthevoicequalityofall

threecallsinprogress.Suchscenariosnecessitatetheuseof

CACtoensurethatnomorereal-timeflowsareadmittedinto

thenetworkbeyondwhattheQoSengineeringofthenodes

allows.ThisisillustratedinFigure9-1.



Figure9-1.ProtectingVoicefromVoice



[Viewfullsizeimage]



Formallydefined,CACisadeterministicdecisionbeforecall

establishmentonwhetherthenetworkresourcesareavailable

toprovidetherequiredQoStothenewcall.CACfeaturesallow

VoIPsystemstomakeaninformeddecisionbeforeadmittinga

newcall,basedontheconditionofthenetwork.Ifthecallis

notadmitted,thecallcanbegiventhereorder(oroverflow)

toneorarecordedannouncementcaninformthecallerthatthe

networkistoobusytocompletethecallattempt.Thecaller

musttryagainlater,orthecallcanberedirectedtoanother

VoIProute,orthecallcanberedirectedthroughthePSTN.



CACToolCategories

ThreebroadcategoriesofCACtoolsexist:

LocalThenodemakesanadmissiondecisionbasedonlocal

informationorconditionsatthenode.

Measurement-basedAdecisiononadmittinganewflowis

reachedbasedonacombinationofconfiguration

informationandreportedinformationofotherentities(such

ascalls,sessions,flows,bandwidth,memoryuse,andtime

slots).

Reservation-basedReservationofresourcesisperformed

beforeadmittingthenewflow.

Eachofthesecategoriesoftoolsisdiscussedinthefollowing

sections.



LocalCACTools

LocalCACmechanismsperformavoicegatewayrouterfunction

andtypicallyfunctionattheoutgoinggateway.TheCAC

decisionisbasedonnodalinformationsuchasthestateofthe

outgoingLAN/WANlinkthatthevoicecallwouldtraverseifit

wereallowedtoproceed.Clearly,ifthelocalpacketnetworklink

isdown,thereisnopointinexecutingcomplexdecisionlogic

basedonthestateoftherestofthenetwork(becausethat

networkisunreachable).Otherlocalmechanismsinclude

configurationitemstodisallowmorethanafixednumberof

calls.Ifthenetworkdesigneralreadyknowsthatnomorethan

fivecallswillfitacrosstheoutgoingWANlink'sLLQ

configurationbecauseofbandwidthlimitations,itwouldbean



obviouschoicetoconfigurethelocalgatewaynodetonotallow

morethanfivesimultaneouscalls.ThefollowingCiscoIOS

featuresornetworkdesigntechniquesfallinthelocalCAC

mechanismscategory:

PhysicalDS0limitation

Max-connections

Voice-bandwidth

Trunkconditioning

Localvoicebusyout(LVBO)



Measurement-BasedCACTools

Measurement-basedCACtechniqueslookaheadintothepacket

networktogaugethestateofthenetworktodetermine

whethertoallowanewcall.Thisusuallyimpliessendingprobes

tothedestinationIPaddress(whichcouldbetheterminating

gatewayorendpoint,oranotherdeviceinbetween).Theprobe

returnssomemeasuredinformationontheconditionsthatit

foundwhiletraversingthenetworktotheoutgoing(sending)

gatewayorendpoint.Typically,lossanddelaycharacteristics

aretheinterestingelementsofinformationforvoiceCAC

decisions.Theoutgoingdevicethenusesthisinformationin

combinationwithconfiguredinformationtodecidewhetherthe

networkconditionsexceedagivenorconfiguredthreshold.The

followingCiscoIOSfeaturesornetworkdesigntechniquesfallin

themeasurement-basedCACmechanismscategory,andboth

useServiceAssuranceAgent(SAA)probes:

Advancedvoicebusyout(AVBO)



PSTNfallback



Resource-BasedCACTools

Twotypesofresource-basedmechanismsexist:thosethat

calculateneededoravailableresources,andthosethatreserve

resourcesforthecall.Resourcesofinterestincludelink

bandwidth,DSPavailabilityandDS0timeslotsonthe

connectingTDMtrunkstoavoicegateway,CPUpower,and

memory.Severaloftheseresourcescouldbeconstrainedatany

nodesormultiplenodesthatthecalltraversestoits

destination.Thefollowingfeaturesornetworkdesign

techniquesfallinthiscategory:

Gatekeeperresourceactivityindicator(RAI)

Gatekeeperzonebandwidth

CiscoCallManagerLocationsCAC

RSVP



CallManagerLocationsCAC

MostofthefeaturesmentionedintheprevioussectionareCisco

IOSfeaturesandpertaintoemployingCACwhenCiscoIOS

voicegatewayroutersconnecttraditionaltelephonyequipment

intoanIPnetwork.MuchofthevoicetrafficinVoIPnetworks,

however,originatesfromIPphones,notfromgateways,and

noneofthesefeatures(otherthanpotentiallyRSVP)appliesto

trafficfromthesedevices.

Therefore,CiscoCallManagerhasadditionalCACfeaturesto

coverthemanagementofIPphonenetworkdeployments.

Thesefeaturesarenotmutuallyexclusive.Although

CallManagerLocationsCACisdeployedintheoverallnetworkto

manageVoIPbandwidthavailabilityforbothIPphonesand

voicegateways,afeaturesuchaslocaloradvancedvoice

busyoutcanbedeployedatthesametimeonthevoice

gatewaytopushbackcallsintothePBXorreroutethoughthe

PSTNifIPnetworkconditionsdonotallowtheirentryintothe

VoIPnetwork.

CallManagerLocationsCACisusedinacentralizeddeployment

model(centralizedCall-Managermanagingphonesinboth

centralandremotelocations)andisbasedonthepremisethat

bandwidthisconstrainedbetweenlocationsorsitesinthe

network.Therefore,onlyacertainnumberofcalls,regardless

oftheiroriginationonanIPphoneorgateway,canbeallowed

intooroutofasiteatanyonetime,asshowninFigure9-2.

Thepremiseofthistoolincludesanassumptionthatthe

bandwidthwithinalocationisunlimitedandthatconstraints

existonlybetweendifferentlocations.



Figure9-2.CallManagerLocationsCAC



[Viewfullsizeimage]



LookingattheconfigurationgiveninFigure9-2,Location2has

WANbandwidthof128kbpsavailableforvoicetraffic.Thisdoes

notindicatethetotalbandwidthintothatsite,butjustthe

bandwidthavailableforvoice,asconfiguredintothe

CallManageratLocation1.Itcanrepresent50percentofthe

totalbandwidthintothesiteandshouldbecorrelatedtothe

amountofbandwidthsetasideintheLLQpriorityclassfor

Location2.

Thetermcorrelatedisusedinsteadofmatchedbecause

CallManagertakesintoaccountonlytheuncompressedLayer3

bandwidthofacallintoitscall-countingCACalgorithm.Onthe

otherhand,LLQ,asdiscussedinChapter5,alsomustaccount

forvariousotherfactors,suchascRTP,thataffectthe

bandwidthrequiredforavoicecallandmustmakeprovisionfor

thecall-signalingbandwidth.

TheCallManagerLocationsCACfeatureworksinconjunction

withCallManagerregions(afeaturethatcontrolscodec

selectionbetweendevicesthatwanttocommunicate),so

bandwidth-constrainedlinksbetweensitestypicallyare

configuredtousetheG.729codecandacountingmechanism



withinCallManagerlimitsthenumberofcallsintooroutofeach

site.IPphonesandvoicegatewaysareassociatedwithbotha

region(forcodecselection)andalocation(forCACpurposes)in

theCallManagerconfiguration.Foreverycallsetup,

CallManagerlooksatthesourceanddestinationlocationsofthe

callandmakesaCACdecisiontoallowordenythenewcall,

basedonhowmanycallsarealreadyactivebetweenthesame

twolocationsandthecodecsinvolvedinthecalls.Callsconfined

withinalocationarenotsubjecttoCAC;asdeterminedbythe

regionsfeature,thesecallstypicallyusetheG.711codec.

ExaminingtheexampleconfigurationinFigure9-2oncemore,

Location2has128kbpsofbandwidthavailableforvoice.Ifthe

CallManagerregionsfeatureisconfiguredsothatanycallinto

oroutofLocation2usestheG.729codec,24kbpsof

bandwidtharerequiredpercall,andCallManager'slocations

CACalgorithmwillallowamaximumof5(128/24)

simultaneouscallstoLocation2.

CallManagerLocationsCACisaheavilydeployedfeatureandis

essentialforacentralizeddeploymentinwhichsomeIPphones

orgatewaysareseparatedfromeachotherbyWANsegments

oflimitedbandwidth.CallManagerlocationsshouldbe

configuredsothatcallsbetweensitesdonotoversubscribethe

bandwidthallocatedtotheVoIPLLQintheWANrouters.

CallManagerLocationsCACisasimplecall-countingmechanism

andisunawareofthetopologyorstateofthenetwork

connections.Itallowsaconfiguredamountofbandwidth(for

example,200kbps)betweentwosites.Foreverycall,it

subtractsafixedamountbasedonthecodecselectedbythe

regionsfeature.Thus,locationsCACworkswellonlyforhuband-spoketopologies.ItisalsounawareofL2protocol

overheads(itcalculatespurelyL3bandwidthrequired)and

bandwidth-alteringfeatures,suchascRTPandtunneling

technologiessuchasGREandIPSec.



GatekeeperCAC

Gatekeepers(GK)oftenareusedtoarbitratebandwidthinboth

CallManagerandtraditionaltoll-bypassnetworks.Aswith

CallManagerLocationsCAC,gatekeepersemployacall-counting

mechanism(basedoncodecpercall)betweensites(zones),

trackbandwidthatanL3level,andarealsounawareofthe

networktopology.Thus,gatekeepercalladmissioncontrol(GK

CAC)generallysolvesthesameproblemasCallManager

LocationsCACandsuffersfromthesamedrawbacks.GKCACis

applicabletoawidersetofdevicesthanCall-ManagerLocations

CAC,though:GKCACcanbeusedtoarbitratebandwidth

betweenanytwodevicesthatregisterwiththeGK,whereas

CallManagerLocationsCACcanbeusedonlybetweenIPphones

andvoicegatewayswithinCallManager'smanagementarea.GK

CACinCallManagernetworksisusedprimarilyindistributed

deploymentmodelstoprovideCAContheinterclustertrunksor

theconnectionsbetweentheCallManagerclusters,asshownin

Figure9-3.



Figure9-3.GatekeeperCACinCallManager

Networks



[Viewfullsizeimage]



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 9.  Call Admission Control (CAC)

Tải bản đầy đủ ngay(0 tr)

×