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

At 04:16 PM 2/9/2004, [email protected] wrote:
>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.

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

-----BEGIN PGP MESSAGE-----
Version: PGP 7.0.1

iQA/AwUBQCg6424xHWxyLJtDEQKlHwCg7hKDosnjxIg1i3sSgVMY7//ERJoAn0jn
LAr00EFwfL+jup7HNYroJKmA
=50q5
-----END PGP MESSAGE-----