RSVP and Weighted Fair Queuing
Just as RSVP is a signaling protocol that does not transport data for a session, RSVP itself is not responsible for queuing and dispatching packets for a session after the reservation is made. RSVP in a Cisco router depends on weighted fair queuing (WFQ), as discussed in Chapter 4, to carry out the queuing and dispatching of packets at the link layer (Layer 2) that ultimately delivers the QoS for a session.
NOTE You can think of RSVP as the decision-maker for reservations and WFQ as the workhorse that processes the packets for those reservations.
Inside a Cisco router, RSVP communicates with WFQ and informs WFQ of the reservations and the QoS promised in those reservations. Recall from Chapter 4 that in WFQ terminology, session's application flows (TCP/UDP flows, for instance) are called conversations. RSVP reservations for sessions have a direct one-for-one relationship to WFQ conversations. RSVP also informs WFQ of a conversation queue number (which uniquely identifies a WFQ queue to use for RSVP) and the weight to use on that queue when it establishes a reservation, as illustrated in Figure 5-6.
NOTE The communication between RSVP and WFQ happens within a router (not over the network).
It's a dialog between two software processes within the router, so although you cannot easily observe the exchange, you can verify that it is enabled (see "Configuring RSVP" later in this chapter).
Figure 5-6 After RSVP Establishes a Reservation, It Forwards QoS Information to WFQ
- RSVP
Admission control, manages state
Weight
Conversation #
Weighted
Fair Queuing
Weighted
Fair Queuing
Applies weights, manages conversation queues
Dispatch out interface
Applies weights, manages conversation queues
Dispatch out interface
When a reservation is established along a path of routers, WFQ (under the instruction of RSVP) ensures that session data is delivered with the service promised by RSVP This is done on the output interfaces of the routers when the data is flowing downstream from the sender to the receiver, as shown in Figure 5-7.
NOTE The actual mechanics of WFQ with RSVP are the same as described in Chapter 4; that is, each conversation has its own queue, and the weight determines QoS for the queue. The difference here is that RSVP, rather than IP prcccdcnce, determines the weight for a queue.
Post a comment