The MPLS WG Archive

["C. Chen" <cchen@asl.dl.nec.com>]

I agree with Mr. Charlap with few additional comments which will be marked
with ">>"

Best Regards,


Cheng C. Chen


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.

>> It seems to me that for LSP set up using LDP is almost like ATM PVC and
hence overbooking is almost a necessity and has to be implemented in
conjunction with CAC and routing algorithm due to:
1. Inaccuracy of traffic descriptor supplied by customeror operator of
initial LSP setup
2. Traffic non-coincidence effect due to different time zone
3. Dynamic traffic changes
4. Not all traffic are in active busrst state simultaneously (This used to
call concentration ratio in voice switch) even during busy hour.


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

>
> >> OVerbooking can also be effective in increasing network utilization
> efficiency even during normal operations. In our experiences with our
> customer  network overbooking is aiming mostly on normal operation.

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