Why RSVP Has Scalability Issues
A signaling protocol can be either in-band or out-of-band, depending on
whether the signaling data flows over the same medium as the bulk
data. In the telephony world, Integrated Services Digital Network (ISDN)
would be considered an out-of-band signaling protocol, because all
information for setting up a call passes over a separate D-channel (data),
Designing & Planning…
Continued
Advanced QoS for AVVID Environments • Chapter 8 225
NOTE
Improved scalability may be realized by not enabling RSVP on every
router end-to-end. While we mentioned that true, end-to-end resource
reservation can only be accomplished by using RSVP on every router endto-
end, it is not mandatory that RSVP be enabled everywhere on a network.
RSVP has the built-in capability to tunnel over non-RSVP aware
nodes (see the discussion later on the setup process). Though a truly
guaranteed QoS will not be possible in this case, provided that the non-
RSVP network has sufficient bandwidth (for example, tunneling over a
Gigabit Ethernet or ATM core), the solution might be feasible for most
applications. In the case of voice in an AVVID environment, this solution
should be tested thoroughly before considering it for production environment
deployment. In addition, it is not necessary for the clients to be
RSVP-capable. Cisco routers provide RSVP functionality for Voice over IP
(VoIP) dial peers. This is accomplished by using RSVP proxy—a function
that emulates clients sending RSVP Path and Resv messages.
RSVP is not a routing protocol, it is an Internet Control Protocol that resides
at Layer 4 of the Open Systems Interconnect (OSI) reference model, the transport
layer. It is similar to other control protocols, such as Internet Control
www.syngress.com
whereas the actual telephone conversation flows over the B-channel
(bearer). In a way, RSVP could be considered an in-band signaling protocol,
since it flows over the same physical media, the same data-link
layer, and even the same network as the bulk data. However, it is usually
referred to as out-of-band because the packets are separate from the
bulk data. A flow that was set up by RSVP would have nothing in its
packets to indicate that it is participating in RSVP. The state of active
reservations is stored in each routed node.
As we indicated earlier, RSVP has some scalability issues. To accomplish
truly guaranteed resource reservation end-to-end, the state of
active reservations must be stored in every router along the path of the
packets, in which case a single reservation takes up resources on every
router in the end-to-end path. Even worse, the reservations are unidirectional,
so a reservation must also be stored in every router end-to-end
for the return path of the packets in a bi-directional transmission (such
as a phone call).
NOTE
Improved scalability may be realized by not enabling RSVP on every
router end-to-end. While we mentioned that true, end-to-end resource
reservation can only be accomplished by using RSVP on every router endto-
end, it is not mandatory that RSVP be enabled everywhere on a network.
RSVP has the built-in capability to tunnel over non-RSVP aware
nodes (see the discussion later on the setup process). Though a truly
guaranteed QoS will not be possible in this case, provided that the non-
RSVP network has sufficient bandwidth (for example, tunneling over a
Gigabit Ethernet or ATM core), the solution might be feasible for most
applications. In the case of voice in an AVVID environment, this solution
should be tested thoroughly before considering it for production environment
deployment. In addition, it is not necessary for the clients to be
RSVP-capable. Cisco routers provide RSVP functionality for Voice over IP
(VoIP) dial peers. This is accomplished by using RSVP proxy—a function
that emulates clients sending RSVP Path and Resv messages.
RSVP is not a routing protocol, it is an Internet Control Protocol that resides
at Layer 4 of the Open Systems Interconnect (OSI) reference model, the transport
layer. It is similar to other control protocols, such as Internet Control
www.syngress.com
whereas the actual telephone conversation flows over the B-channel
(bearer). In a way, RSVP could be considered an in-band signaling protocol,
since it flows over the same physical media, the same data-link
layer, and even the same network as the bulk data. However, it is usually
referred to as out-of-band because the packets are separate from the
bulk data. A flow that was set up by RSVP would have nothing in its
packets to indicate that it is participating in RSVP. The state of active
reservations is stored in each routed node.
As we indicated earlier, RSVP has some scalability issues. To accomplish
truly guaranteed resource reservation end-to-end, the state of
active reservations must be stored in every router along the path of the
packets, in which case a single reservation takes up resources on every
router in the end-to-end path. Even worse, the reservations are unidirectional,
so a reservation must also be stored in every router end-to-end
for the return path of the packets in a bi-directional transmission (such
as a phone call).
226 Chapter 8 • Advanced QoS for AVVID Environments
Message Protocol (ICMP) and Internet Group Management Protocol (IGMP). It
is fully compliant with Internet Protocol version 4 (IPv4) and the emerging
Internet Protocol version 6 (IPv6).The path that it takes across the network is
the same as other IP packets and is determined by the underlying routing protocol
(Open Shortest Path First [OSPF], Enhanced Interior Gateway Routing
Protocol [EIGRP], Border Gateway Protocol [BGP], and so on).
Besides interoperating with routing protocols, RSVP also works with QoS
implementation mechanisms.These are the mechanisms that provide QoS
directly, such as weighted fair queuing (WFQ), weighted random early detection
(WRED), and the like.What implementation mechanisms are used is not the
direct concern of RSVP. It is up to the routers to determine how QoS will be
implemented, based on their own particular capabilities. RSVP only makes the
request and leaves it up to the intermediary nodes to deliver QoS.
Both unicast and multicast traffic are supported by RSVP. Support for multicast
is fortuitous, since RSVP is currently used the most prevalently for voice and
video traffic, much of which is characterized by multicast flows.We will see later
how RSVP interoperates with the IGMP and Protocol Independent Multicast
(PIM) to reserve resources for multicast flows.