This section describes configuration of RSVP on three Cisco 4500 routers for a multicast session.
For information on how to configure RSVP, see the How to Configure RSVP.
The three devices form the network between an RSVP sender application running on an upstream (end system) host and an RSVP receiver application running on a downstream (end system) host--neither host is shown in this example.
The network includes three devices: Router A, Router B, and Router C. The example presumes that the upstream High-Speed Serial Interface (HSSI) interface 0 of Router A links to the upstream host. Router A and Router B are connected by the downstream Ethernet interface1 of Router A, which links to the upstream interface Ethernet 1 of Router B. Router B and Router C are connected by the downstream HSSI interface 0 of Router B, which links to the upstream HSSI interface 0 of Router C. The example presumes that the downstream Ethernet interface 2 of Router C links to the downstream host.
Typically, an RSVP-capable application running on an end system host on one side of a network sends either unicast or multicast RSVP PATH (Set Up) messages to the destination end system or host on the other side of the network with which it wants to communicate. The initiating application is referred to as the sender; the target or destination application is called the receiver. In this example, the sender runs on the host upstream from Router A and the receiver runs on the host downstream from Router C. The network delivers the RSVP PATH messages from the sender to the receiver. The receiver replies with RSVP RESV messages in an attempt to reserve across the network the requested resources that are required between itself and the sender. The RSVP RESV messages specify the parameters for the requisite QoS that the network connecting the systems should attempt to offer.
This example does not show the host that would run the sender application and the host that would run the receiver application. Normally, the first device downstream from the sender in the network--in this case, Router A--would receive the RSVP PATH message from the sender. Normally, the last router in the network--that is, the next hop upstream from the host running the receiver application, in this case, Router C--would receive an RSVP RESV message from the receiver.
Because this example does not explicitly include the hosts on which the sender and receiver applications run, the devices have been configured to act as if they were receiving PATH messages from a sender and RESV messages from a receiver. The commands used for this purpose, allowing RSVP to be more fully illustrated in the example, are the ip rsvp sender command and the ip rsvp reservation command. On Router A, the following command has been issued:
ip rsvp sender 225.1.1.1 10.1.2.1 UDP 7001 7000 10.1.2.1 Hs0 20 1
This command causes the device to act as if it were receiving PATH messages destined to multicast address 225.1.1.1 from a source 10.1.2.1. The previous hop of the PATH message is 10.1.2.1, and the message was received on HSSI interface 0.
On Router C, the following command has been issued:
ip rsvp reservation 225.1.1.1 10.1.2.1 UDP 7001 7000 10.1.3.1 Et2 FF LOAD 8 1
This command causes the device to act as if it were receiving RESV messages for the session with multicast destination 225.1.1.1. The messages request a Fixed Filter reservation to source 10.1.2.1, and act as if they had arrived from a receiver on Ethernet interface 2 with address 10.1.3.1.
In the example, the RSVP PATH messages flow in one direction: downstream from the sender, which in this example is Router A. (If the host were to initiate the RSVP PATH message, the message would flow from the host to Router A.) Router A sends the message downstream to Router B, and Router B sends it downstream to Router C. (If the downstream host were the actual receiver, Router C would send the RSVP PATH message downstream to the receiver host.) Each device in the network must process the RSVP PATH message and route it to the next downstream hop.
The RSVP RESV messages flow in one direction: upstream from the receiver (in this example, Router C), upstream from Router C to Router B, and upstream from Router B to Router A. If the downstream host were the receiver, the message would originate with the host, which would send it to Router C. If the upstream host were the sender, the final destination of the RSVP RESV message would be the upstream host. At each hop, the device receiving the RSVP RESV message must determine whether it can honor the reservation request.
The ip rsvp bandwidth command both enables RSVP on an interface and specifies the amount of bandwidth on the interface that can be reserved (and the amount of bandwidth that can be allocated to a single flow). To ensure QoS for the RSVP reservation, WFQ is configured on the interfaces enabled for the reservation.
If the network is capable of offering the specified (QoS) level of service, then an end-to-end reserved path is established. If not, the reservation attempt is rejected and a RESV ERROR message is sent to the receiver. The ability of each device in the network to honor the requested level of service is verified, link by link, as the RSVP RESV messages are sent across the network to the sender. However, the data itself for which the bandwidth is reserved travels one way only: from the sender to receiver across an established PATH. Therefore, the QoS is effective in only one direction. This is the common case for one-to-many multicast data flows.
After the three devices in the example are configured, the show ip rsvp sender and show ip rsvp reservation commands will make visible the PATH and RESV state.