Why Do I Need RSVP on My Network?
RSVP is used primarily to guarantee QoS to real-time applications such as voice
and video, which makes it a natural part of any discussion about AVVID solutions.
www.syngress.com
Subnetwork Bandwidth Manager
We have seen that RSVP is largely independent of the media it is running
on with respect to the QoS mechanisms used to implement a particular
reservation. With serial links, WFQ and WRED can be used to provide
either a controlled-load or a guaranteed-rate to an application. These
mechanisms are not appropriate on a shared medium like Ethernet that
has multiple participants competing for the bandwidth. Because of its
end-to-end signaling nature, without a common node to keep track of
active reservations, a RSVP client on a shared medium would have no
way of knowing if there are resources available for the new reservation.
Subnetwork Bandwidth Manager (SBM) was created to implement
RSVP on IEEE 802-based networks (Ethernet/Token Ring). SBM acts very
much like RSVP. On a shared medium, all SBM-enabled nodes elect a
Designated SBM to manage the resources for that network. All RSVP
requests by clients on this network are sent to the DSBM for verification.
If the resources are available, the request is sent on to the destination
address. If the resources are not available, the request is denied.
When using SBM, in order to guarantee that RSVP sessions are not
overwhelmed by non-RSVP traffic, you must ensure that all nodes connected
to the shared media are RSVP-compliant. This might be difficult
to put into practice.
Depending on the topology, SBM will not always be necessary to
provide good end-to-end performance for critical applications. Just
because part of the journey that a packet takes includes a non-RSVP
shared medium such as Ethernet, does not mean that QoS will be impossible.
Consider the case of a switched 100BaseTX network connected to
a wide area network (WAN) via a T1 on a serial interface of a local router.
If it can be assumed that all RSVP requests are destined across the WAN,
the bottleneck is clearly the T1. If there are available resources on the T1,
it is probable that there are available resources on the Ethernet segment,
assuming that non-RSVP flows do not overwhelm the RSVP sessions.
Designing & Planning…
Advanced QoS for AVVID Environments • Chapter 8 235
RSVP-aware clients can make a reservation and be guaranteed a good QoS across
the network for the length of the reservation, however long or short.
Because RSVP takes the Intserv approach to QoS, all traffic in the network
does not need to be classified in order to give proper QoS to RSVP sessions. On
the other hand, for the same reason, a multi-field classification must be performed
on each packet at each node in the network to discover if it is part of the RSVP
session for which resources have been reserved.This can lead to a consumption of
network resources like memory and CPU cycles.
RSVP’s open architecture and transparency allow for deployment on many
platforms, and even tunneling across non-RSVP aware nodes. Despite this, RSVP
has some distinct scaling issues that make it doubtful it will ever be implemented
successfully on a very large network, or the Internet for that matter, in its current
revision.These advantages and disadvantages, as well as others previously discussed,
are summarized here.