RSVP reservations

[thegrave2000]

Hi,

I'm a little confused, hope you can help. I'm playing with MPLS TE these days and here is what I read in the "Traffic Engineering with MPLS book" by Cisco Press:

After a downstream router receives a Path message, it does a few things. It checks the message's format to make sure everything is OK, and then it checks the amount of bandwidth the received Path message is asking for. This process is known as admission control.

If admission control is successful and the Path message is allowed to reserve the bandwidth it wants, the downstream router creates a new Path message and sends it to the next hop in the Explicit Route Object (ERO), which is covered later in this chapter. Path messages follow this chain until they reach the last node in the ERO-the MPLS TE tunnel tail.

The tunnel tail performs admission control on the Path message, just like any other downstream router. When the tail realizes that it is the destination of the Path message, it replies with a Resv message.

Well, when I test this my observations are like this:

1) Bandwidth is reserved only on tailend-facing interfaces, not on headend-facing ones.

2) If the tailend has no ip rsvp bandwidth command on the headend-facing interface it still replies with a correct RESV message and the tunnel comes up. Traffic is forwarded as supposed.

3) If you do not enter the ip rsvp bandwidth command on headend-facing interfaces in the path the tunnel still comes up and everything works fine.

These things, however, do not match those written in the book. It seems like that the tailend does not care about the required by the headend tunnel parameters and as long as the message format is correct it always returns a RESV message. I assume this is a simple principle which cannot have changed over the years so either these guys are wrong (however unlikely this is), or I'm missing something. Any help will be appreciated.

Kind Regards,

Stefan

P.S. I'm testing this on a 7206 VXR running ADVIPSERVICES 12.2(33)SRD but I don't think it matters at all.

[Giuseppe Larosa]

Hello Stefan,

MPLS TE tunnels are strictly unidirectional and so this explains why bandwidth reservations are done in a single direction.

This is normal and it should be expected.

So in your tests having no ip rsvp bandwidth in the other direction doesn't block the setup of the MPLS Te tunnel in the intended direction.

This is different from what you can see for example on a GRE tunnel.

So I would say all you see is correct.

By the way I think also classic RSVP reservations are undirectional.

Each router should check if in the direction to the destination it has enough rsvp BW resources to allocate taking in account already existing reservations made by other tunnels (if any) the bandwidth to the headend is checked only when you create a tunnel from the current destination node to the current source node

Hope to help

Giuseppe

[thegrave2000]

Hi Guiseppe,

Sure thing they are unidirectional. I just can't agree with the sentences written in this book as the only type of admission control performed by the tailend actually seem to be on stuff like the tunnel endpoint, correct message format, etc. but not on the actual parameters involved in CSPF computations (bandwidth, affinity, priority, whatever).

Thanks,

Stefan

[Giuseppe Larosa]

Hello Stefan,

I agree with you:

it is the penultimate hop to the destination node that makes the last real check on rsvp resources.

the last node actually has to perform some basic checks:

the most important of them is that the MPLS TE router-id ip address = tunnel destination ip address

Hope to help

Giuseppe