Re: CAC RE: I-D ACTION:draft-ietf-ieprep-domain-req-00.txt

At 02:20 PM 2/9/2004 -0800, Janet Gunn wrote:
>I have finally had a chance to do some more reading, and I think I fianlly 
>understand the source of my confusion (and probably some others).
>
>I had assumed that the term "Call Admission Control" was active only only 
>at the START of a call- that once a call had been admitted in the first 
>place, there was no further CAC involvement.
>
>However, reading between the lines in several posts, and relating that to 
>some of the reference documents, it appears that the term CAC is being 
>applied to a mechanism which remains involved throught the live of the 
>call, and can "rescind" the admission during the course of the call, if 
>necessary.

What you were believing was the case is called "Locations based CAC" (done 
once at start-up, and not again). This is a hack, but kinda sorta works in 
very limited links between 2 locations (not daisy-chained mind you, the 
complexity and topology knowledge is just not really possible then).

What you have realized about RSVP is that the CAC functionality is from 
call inception, makes sure there is enough resources to complete a call at 
a known bandwidth (errors the set-up if there isn't enough), and the 
routers in between remain in a "soft state" condition for all the RSVP 
"flows" that have been accepted through that interface for the duration of 
all the flows (or calls) until their end, which is either by a normal end 
of a call (user hang-up) or a preemption event at a congested router 
interface (to make room for another flow/call).


>Is this right, or am I just barking up a different wrong tree?

the crowd applauds!!


>Janet
>
>-----Original Message-----
>From: Scott Bradner <[email protected]>
>Sent: Feb 3, 2004 5:31 AM
>To: [email protected], [email protected]
>Cc: [email protected], [email protected], [email protected]
>Subject: Re: CAC RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt
>
> > [jpg] It is not clear to me how CAC says "sorry, but there was another call
> > with higher priority, and I have to shut your call down now" once the call
> > has been established.  I was under the impression that, once the call was
> > established, the router did not distinguish between individual calls.  I
> > would be glad to be enlightened on that point.
>
>note that the router is not involved in establishing the call - its all
>packets to the router
>
>but if the call QoS is maintained by RSVP (as Fred suggested) there is
>less of an issue - a router can reject RSVP sessions even after they
>have started
>
>Scott
>
>_______________________________________________
>Ieprep mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ieprep


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented