Re: CAC definition

[email protected] Tue, 10 Feb 2004 11:47:16 EST
Newsgroups gmane.ietf.ieprep
Message-ID <[email protected]>
In a message dated 2/9/2004 8:59:41 PM Eastern Standard Time, [email protected] 
writes:


> 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.
> 



To all,

The issue that Janet raised and that I responded to had nothing to do with 
the functionality of RSVP. I am well aware that RSVP includes the notion of 
preempting existing flows, and I think we can make good use of that. I did not 
assert that RSVP is not "call admisison control". I said nothing about RSVP.

The issue raised by Janet is simply the definition of the term "Call 
Admission Control" or "CAC" and whether or not the term includes "preemption".

Since you're mentioned RSVP, looking through existing RSVP RFCs, there are 
references to "Admission Control" and RFC3181 mentions "Capacity Admission 
Control (CAC)". (Of course, RSVP does not refer to "Call Admission Control".)

RFC 2205 defines:

   o    Traffic control

        The entire set of machinery in the node that supplies requested
        QoS to data streams.  Traffic control includes packet
        classifier, packet scheduler, and admission control functions.

   o    Admission control

        A traffic control function that decides whether the packet
        scheduler in the node can supply the requested QoS while
        continuing to provide the QoS requested by previously-admitted
        requests.  See also "policy control" and "traffic control".

I would claim that the above definition of "Admission Control" does not 
include the function of preemption, although RSVP does include preemption.

I would suggest that as we talk more about preemption (of calls or packet 
flows), we need better definitions. It seems that "Traffic Control" should be 
extended to include a fourth component: preemption of packet flows. The 
definition of "Admisison Control" would remain as it is above in RFC 2205. As noted, 
CAC may cause preemption to occur, but I think it's better to define them as 
separate functions (and terms).

Mike Pierce