[c-nsp] MPLS Traffic Engineering , RSVP and QoS

[Oliver Boehmer (oboehmer)]

> I though if CBWFQ was applyed to an interface reserving 60Mbps for a
> specific traffic (precedence 5 in the test), RSVP would have less then
> 40Mbps left on the interface to reserve bandwidth for new tunnel, and
> new tunnel requiring 70Mbps would fail.
>
> But test shows that the tunnel goes up. Am I missing the point, and
> the interface bandwidth reserved using CBWFQ does not account on the
> bandwidth reserved using RSVP?

TE is a pure control-plane protocol and does not account for any QoS
DiffServer Per-Hop-Behaviour (i.e. for example bandwidth reserved for a
certain class via MQC/CBWFQ). 

If you want your TE to be somewhat diffserv-aware, you need to use DS-TE
and work with a subpool, i.e. if you want to allow 70 Mbps overall
reservations on your link, but you only want 60 Mbps for voice/llq
traffic because this is what you have provisioned using PHB, you
configure

  ip rsvp bandwidth 70000 sub-pool 60000

on the link and tell your TE tunnel to request bandwidth from the
sub-pool

  tunnel mpls traffic-eng bandwidth sub-pool 70000

If you do this, you will see that your tunnel won't come up as CSPF
won't find a path satisfying the contraints in your topology.

Currently IOS supports only a single subpool, as Voice/LLQ is the only
type of application where you might need this as you don't want
voice/LLQ to consume more than 50% of your link as this would degregate
performance.

	oli