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

From: [email-masked]
Date: Mon, 9 Feb 2004 19:16:43 EST

In a message dated 2/9/2004 5:23:37 PM Eastern Standard Time, 
[email-masked] 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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 09 Feb 2004 18:39:06 -0600

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-masked] wrote:
>>at the START of a call- that once a call had been admitted in the first 
>>place, there was no further CAC involvement.
>>
>>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.
>
>
>
>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

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Fred Baker <[email-masked]>
Date: Mon, 09 Feb 2004 17:59:00 -0800

>to decide whether to preempt a call or terminate a packet flow.

perhaps.

As James noted, there are a variety of procedures that are called CAC: 
these are generally call counters in SIP Proxies or H.323 Gatekeepers, and 
MOSAIC defines something based on Bandwidth Broker research. These, as you 
say, these procedures look at the call when it is being negotiated and 
never look at it again.

RSVP, as defined in RFC 2205, is continuous. It maintains a continuous 
knowledge of what sessions are up and what sessions are going away, 
reinstalls them if the routing path changes, and is quite capable of 
preempting a call if need be. This is discussed in some detail in
     http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-01.txt

which will be posted later on this week. The -00 version touches on it, but 
not in as great detail.

To assert that a bandwidth-and-routing aware protocol such as RSVP is not 
"call admission control" does some violence to the English language, IMHO. 
If it is not admitting calls, I'm not sure what it is doing. Yes, in 
addition is performs preemption; to RSVP, those are different outcomes of 
the same process.

I have a list of the relevant IETF standards at
     ftp://ftpeng.cisco.com/fred/mlpp/rsvp.html

if you're interested, you might want to review how preemption works in RSVP
      ftp://ftp.rfc-editor.org/in-notes/rfc3181.txt