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