The MPLS WG Archive

[Aimin Sang <sang@ece.utexas.edu>]

Thanks for the answer. I think it maybe better to have the re-routing
for link failure separated from the flow's QoS violation for overbooked
CAC. Of course if link failure is defined as a seriously violated QoS,
then they have to co-work together.

I am expecting someone to give me more insights
about overbooking implementation in CAC, especially for controlled load
service, or CBR/VBR in ATM.

Thanks.

Sincerely,

Aimin
****************************************************************
                Aimin Sang, Ph.D Candidate
                Telecommunication Networks
                ENS 106, ECE Department
                Univ. of Texas at Austin
		
                Mailing/Home Address: 
                1515 Rio Grand Dr., Apt. 723, Plano, TX 75075
		
                Fax:   (214)-291-2280 
                Phone: (972)-943-3285 (Home)
                       (214)-291-2375 (Office)
                URL:   http://www.ece.utexas.edu/~sang

"You can never be too rich, too thin, or have too much bandwidth"
*****************************************************************

On Tue, 29 Aug 2000, David Charlap wrote:

> Aimin Sang wrote:
> > 
> > Could you please give us a more detailed example (when "this is OK")
> > to set overbooking factor? Say: The overbooked reservation is
> > temporary because of the re-routing, but who set the overbooking
> > factor and how? It is set by the network operator from time to time,
> > or the CAC algorithm automatically?
> 
> I would hope that every implementation would require the operator to set
> this factor.
> 
> > Further, I guess you mean that the CAC's decision of overbooking can
> > be balanced by traffic engineering. If that is right, are these two
> > control at the same time-scale?
> 
> The idea here is not that you want the switch to remain overbooked, but
> that temporary overbooking is better than lost connections.
> 
> If a link fails, a fast-reroute algorithm may shunt the LSP onto another
> router.  Later on, when the routing tables stabilize, the ingress router
> (perhaps in response to an operator command) may choose to reroute that
> LSP again, onto a less-heavily trafficked switch.
> 
> If a lot of LSPs get shunted onto a single fallback router, this router
> may not have enough resources to maintain all of their original QoS
> levels.  At this point, the failover switch has one of two choices.  It
> can refuse to accept those LSPs that it can't satisfy, or it can
> overbook them.
> 
> If it refuses to accept the LSPs, then those connections will go down
> until the ingress router can re-signal with a new path.  The LSPs that
> did get rerouted will continue to operate at their former QoS levels.
> 
> If it overbooks, then none of the connections will go down, but the QoS
> on all of them will suffer until the ingress node can reroute them
> elsewhere.
> 
> There are advantages to either scenario.  For some networks, it is
> better that all connections remain up, at reduced quality.  For some
> networks, it is better that some connections go down, so that the rest
> remain at their normal quality levels.
> 
> As for how to actually implement overbooking, I'll leave that part of
> the answer to someone with more experience in this area.
> 
> -- David
>