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

In a message dated 2/10/2004 11:56:45 AM Eastern Standard Time, 
[email protected] writes:


> Yes, I think it would be worthwhile to have a "definition" of CAC as a
> stand-alone posting on the list.   But I don't think we need to have a
> "discussion" about it.
> 

Well, it's hard to have a "definition" without some discussion, since it 
should be something that is agreed.

I think our "discussion" and the need is for a definition of "Call Admission 
Control", which I had used in my draft on preferential treatement examples, 
with the belief that there was a uniform understanding of what it meant. I 
believe it is an old term from the telephony environment, and what we are talking 
about here is "telephony". The application layer functions (call setup) haven't 
changed.

We should clearly separate the transport layer (e.g., RSVP, packet flows) 
from the application layer (call setup, preemption, release) with our terms. 
Unfortunately, RFC3181 uses the term "Capacity Admission Control (CAC)" in 
referring to packet transport.

Fred and James' comments related to RSVP, but RSVP never talked about 
"calls". As RSVP defines "Admission Control", I don't see the term
including "preemption", although RSVP clearly does.

In a message dated 2/10/2004 3:28:34 PM Eastern Standard Time, 
[email protected] writes:


>  define CAC in IP as:
> 
>          - set-up of the call at the endpoints (SIP does this), and
> 
>          - the ongoing monitoring process to keep the flow "functional"
> 
> this second bullet deals with packet admission, per packet to meet an 
> agreed upon bandwidth guarantee promised to all other nodes for that flow.
> 

Yes, I think this is fine, except that the first bullet is the application 
layer (call) and the second is the packet transport layer. So "CAC" would then 
be "Call/Capacity Admission Control".

CAC affects the initial setup of the call as well as the continuation of the 
call (packet flow). That's fine. I just think that the specific function of 
preemption of one call (packet flow) by another should be called something else 
for sake of clarity in descriptions, etc.

Mike Pierce