The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <49A5CB458910D411B73700508B676C5C05A8F40A@BZ0017EXCH002U>, "Farias, 
Lavoisier Jose Leite (Lavoisier)" writes:
> Hi Experts,
> 
> I have a question regarding MPLS technology, and how an MPLS Network can
> allows QoS. Maybe my question is basic...
> 
> The question is if MPLS LSR or LER has CAC (Call Admission Control) to
> guarantee QoS when LSPs  when a CR-LDP or RSVP-TE RESV requested is
> received.

CAC is supported but it may be the worst of the available ways to
implement QoS.  In the diffserv WG AF and EF services have been
defined, though metering and priority queueing seems to do fine (and
is very similar to EF).  Preferred services are given preferential
queueing treatment and the amount of preferred service is limited so
as not to completely stomp on the less preferred services (worst
effort service is not an acceptable service offering).  The means to
limit service can be "voluntary" on the part of the ingress.  In that
case some high limit is set (but usually not full bandwidth) and a
lower voluntary limit is enforced by having the ingress avoid hot
spots in the network, trying to spread its own load around.

If all is configured well, except for occassional too fast attempts at
recovery from a fault preemption or CAC limits should never take
effect.  The need to even attempt a very fast recovery is avoided
using standby LSP at numerically higher setup/hold priorities, or
doing the same with FRR.  With standby or FRR, the initial recovery of
primary LSPs after a fault can occur more slowly (since they are
backed up) allowing better feedback to the set of ingress to acheive
better initial layout.  This avoids preemption of CAC.

Backup LSP may not be an option if bandwidth is provisioned tightly,
but overbooking of most traffic and temporary congestion is preferable
to a mess where LSPs are rerouting too rapidly and CAC is causing
failure of LSPs to come up until after numerous attempts.  The circuit
emulation LSPs have to be more strictly limited but LSPs carrying TCP
would be better served being brought up quickly with some congestion
followed by a period in which the layout is optimized and congestion
is reduced or eliminated.

Unlike in ATM the practical reality in MPLS networks is that in the
face of catastrophy, congestion is something to be avoided but not
bringing up some of the LSPs is not an option if one wants to stay in
business.  So CAC is to be avoided.  A good example is the San Diego
earthquake in the mid to late 1990s which affected the majority of
fiber capacity to the area.  Internet connections were congested but
for all but emergency services and very high paying customers POTS and
most swithced services was seen as "just plain broken" for a few days.
(Somehow the phone carriers still claim 5 9s of reliability and the
Chicago fire in the late 1980s didn't affect the 5 9s rating either).

> I am familiar with ATM technology, so ...

That's obvious and its half your problem.  You can't just read a few
MPLS documents and then assume that MPLS is just like ATM only the
control plane and framing is different.

> Thank you in advance,
> 
> Best Regards
> Lavoisier J.L.Farias

Curtis

ps - there is an FAQ at http://www.mplsrc.com/mplsfaq.shtml but it is
brief and doesn't specifically address CAC.  There could be an entire
section on misconceptions about MPLS drawn from familiarity with ATM.