Aggregating RSVP Reservations

Problem

You want to aggregate several RSVP reservations so that the core of your network doesn't need to keep track of them all separately.

Solution

This feature requires the creation of a boundary between the edge region of the network, where RSVP runs normally, and the core of the network where packets are classified purely using DSCP:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#interface FastEthernet0/0
Router2(config-if)#ip address 192.168.101.1 255.255.255.0
Router2(config-if)#ip rsvp bandwidth 128 56
Router2(config-if)#ip rsvp data-packet classification none
Router2(config-if)#ip rsvp resource-provider none
Router2(config-if)#exit
Router2(config)#interface Serial0/0.1 point-to-point
Router2(config-subif)#ip address 192.168.55.10 255.255.255.252
Router2(config-subif)#frame-relay interface-dlci 409
Router2(config-fr-dlci)#ip rsvp bandwidth 128 56
Router2(config-subif)#ip rsvp data-packet classification none
Router2(config-subif)#ip rsvp resource-provider none
Router2(config-subif)#exit
Router2(config)#end
Router2#

 

Discussion

The biggest problem with RSVP is that it doesn't scale well when you have a large number of reservations. This is a good model at the edge of the network, but in the middle of the network, where there could be a huge number of flows to keep track of, it would be preferable to use traditional DSCP-based packet marking and queuing.

However, it is not sufficient to just run RSVP at the edges of the network and use a pure DSCP model in the core. Consider a model in which traffic must cross from one RSVP network region through the traditional DSCP core to another RSVP region. A reservation request originating in the first RSVP region will not reach the second region if the core doesn't support RSVP. Consequently, it is not possible to guarantee end-to-end quality of service.

Cisco introduced a new feature to get around this problem in IOS Version 12.2(2)T. The key is to configure RSVP on the core routers so that they can relay RSVP requests back and forth between the edge regions, but to instruct them not to actually use the RSVP information when queuing packets.

There are two commands required to do this, and they must be configured on every interface that will be forwarding RSVP packets through the core network region:

Router2(config)#interface FastEthernet0/0
Router2(config-if)#ip rsvp data-packet classification none
Router2(config-if)#ip rsvp resource-provider none

For example, in an MPLS network, you might want to use this type of configuration on the PE routers. This would allow all of the routers on the customer premises to support traditional RSVP, while the MPLS network core would prioritize based on its own internal classes of service.

See Also

Recipe 11.10; Recipe 11.11