Re: CAC RE: I-D ACTION:draft-ietf-ieprep-domain-req-00.txt
"James M. Polk" <[email protected]> Mon, 09 Feb 2004 18:39:06 -0600
| Newsgroups | gmane.ietf.ieprep |
|---|---|
| Message-ID | <4.3.2.7.2.20040209183201.03ed7c88@localhost> |
I'm sorry Mike, but that is the functionality RSVP does and has done for many many years.... I'm not going to change it. Further, the maintenance CAC function (what you would call the part after initial admission) is what RSVP does. When referring to CAC and RSVP, this is the definition that is used in the IETF for voice and video flows. When in Rome, you do what the Roman's do.... At 07:16 PM 2/9/2004 -0500, [email protected] wrote: >In a message dated 2/9/2004 5:23:37 PM Eastern Standard Time, >[email protected] writes: > > >>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. > > > >This is a term which needs consistent definition before we continue. It's >being used in different ways, including as you noted above. > >Since the term is "Admission", I believe it only makes sense to use "CAC" >it to refer to the control that is placed on deciding whether or not to >admit a new call (i.e., packet flow), not on anything that is done later >to decide whether to preempt a call or terminate a packet flow. > >Mike cheers, James ******************* Truth is not to be argued... it is to be presented