in section 6.7 that in order for a network to provide QoS guarantees, there
must be a signaling protocol that allows applications running in hosts
to reserve resources in the Internet. RSVP [RFC
1993], is such a signaling protocol for the Internet.
talk about resources in the Internet context, they usually mean
link bandwidth and router buffers. To keep the discussion concrete and
focused, however, we shall assume that the word resource is synonymous
with bandwidth. For our pedagogic purposes, RSVP stands for bandwidth
6.8.1: The Essence
The RSVP protocol
allows applications to reserve bandwidth for their data flows. It is used
by a host, on the behalf of an application data flow, to request a specific
amount of bandwidth from the network. RSVP is also used by the routers
to forward bandwidth reservation requests. To implement RSVP, RSVP software
must be present in the receivers, senders, and routers. The two principal
characteristics of RSVP are:
These two characteristics
are illustrated in Figure 6.33. The diagram shows a multicast tree with
data flowing from the top of the tree to hosts at the bottom of the tree.
Although data originates from the sender, the reservation messages originate
from the receivers. When a router forwards a reservation message upstream
toward the sender, the router may merge the reservation message with other
reservation messages arriving from downstream.
It provides reservations
for bandwidth in multicast trees (unicast is handled as a degenerate
case of multicast).
It is receiver-oriented,
that is, the receiver of a data flow initiates and maintains the resource
reservation used for that flow.
RSVP: Multicast- and receiver-oriented
RSVP in greater detail, we need to consider the notion of a session.
As with RTP, a session can consist of multiple multicast data flows. Each
sender in a session is the source of one or more data flows; for example,
a sender might be the source of a video data flow and an audio data flow.
Each data flow in a session has the same multicast address. To keep the
discussion concrete, we assume that routers and hosts identify the session
to which a packet belongs by the packet's multicast address. This assumption
is somewhat restrictive; the actual RSVP specification allows for more
general methods to identify a session. Within a session, the data flow
to which a packet belongs also needs to be identified. This could be done,
for example, with the flow identifier field in IPv6.
that the RSVP standard [RFC
2205] does not specify how the network provides the reserved bandwidth
to the data flows. It is merely a protocol that allows the applications
to reserve the necessary link bandwidth. Once the reservations are in place,
it is up to the routers in the Internet to actually provide the reserved
bandwidth to the data flows. This provisioning would likely be done with
the scheduling mechanisms (priority scheduling, weighted fair queuing,
etc.) discussed in Section 6.6.
It is also important
to understand that RSVP is not a routing protocol--it does not determine
the links in which the reservations are to be made. Instead it depends
on an underlying routing protocol (unicast or multicast) to determine the
routes for the flows. Once the routes are in place, RSVP can reserve bandwidth
in the links along these routes. (We shall see shortly that when a route
changes, RSVP re-reserves resources.) Once the reservations are in place,
the routers' packet schedulers must actually provide the reserved bandwidth
to the data flows. Thus, RSVP is only one piece--albeit an important piece--in
the QoS guarantee puzzle.
RSVP is sometimes
referred to as a signaling protocol. By this it is meant that RSVP
is a protocol that allows hosts to establish and tear down reservations
for data flows. The term "signaling protocol" comes from the jargon of
the circuit-switched telephony community.
can receive a flow at 28.8 Kbps, others at 128 Kbps, and yet others at
10 Mbps or higher. This heterogeneity of the receivers poses an interesting
question. If a sender is multicasting a video to a group of heterogeneous
receivers, should the sender encode the video for low quality at 28.8 Kbps,
for medium quality at 128 Kbps, or for high quality at 10 Mbps? If the
video is encoded at 10 Mbps, then only the users with 10 Mbps access will
be able to watch the video. On the other hand, if the video is encoded
at 28.8 Kbps, then the 10 Mbps users will have to see a low-quality image
when they know they can see something much better.
To resolve this
dilemma it is often suggested that video and audio be encoded in layers.
For example, a video might be encoded into two layers: a base layer and
an enhancement layer. The base layer could have a rate of 20 Kbps whereas
the enhancement layer could have a rate of 100 Kbps; in this manner receivers
with 28.8 Kbps access could receive the low-quality base-layer image, and
receivers with 128 Kbps could receive both layers to construct a high-quality
We note that
the sender does not need to know the receiving rates of all the receivers.
It only needs to know the maximum rate of all its receivers. The sender
encodes the video or audio into multiple layers and sends all the layers
up to the maximum rate into multicast tree. The receivers pick out the
layers that are appropriate for their receiving rates. In order to not
excessively waste bandwidth in the network's links, the heterogeneous receivers
must communicate to the network the rates they can handle. We shall see
that RSVP gives foremost attention to the issue of reserving resources
for heterogeneous receivers.
6.8.2: A Few Simple
Let us first describe
RSVP in the context of a concrete one-to-many multicast example. Suppose
there is a source that is transmitting the video of a major sporting event
into the Internet. This session has been assigned a multicast address,
and the source stamps all of its outgoing packets with this multicast address.
Also suppose that an underlying multicast routing protocol has established
a multicast tree from the sender to four receivers as shown below; the
numbers next to the receivers are the rates at which the receivers want
to receive data. Let us also assume that the video is layered and encoded
to accommodate this heterogeneity of receiver rates.
RSVP operates as follows for this example. Each receiver sends a reservation
message upstream into the multicast tree. This reservation message
specifies the rate at which the receiver would like to receive the data
from the source. When the reservation message reaches a router, the router
adjusts its packet scheduler to accommodate the reservation. It then sends
a reservation upstream. The amount of bandwidth reserved upstream from
the router depends on the bandwidths reserved downstream. In the example
in Figure 6.34, receivers R1, R2, R3, and R4 reserve 20 Kbps, 100 Kbps,
3 Mbps, and 3 Mbps, respectively. Thus router D's downstream receivers
request a maximum of 3 Mbps. For this one-to-many transmission, Router
D sends a reservation message to Router B requesting that Router B reserve
3 Mbps on the link between the two routers. Note that only 3 Mbps are reserved
and not 3+3=6 Mbps; this is because receivers R3 and R4 are watching the
same sporting event, so their reservations may be merged. Similarly, Router
C requests that Router B reserve 100 Kbps on the link between routers B
and C; the layered encoding ensures that receiver R1's 20 Kbps stream is
included in the 100 Kbps stream. Once Router B receives the reservation
message from its downstream routers and passes the reservations to its
schedulers, it sends a new reservation message to its upstream router,
Router A. This message reserves 3 Mbps of bandwidth on the link from Router
A to Router B, which is again the maximum of the downstream reservations.
An RSVP example
We see from
this first example that RSVP is receiver-oriented, that is, the
receiver of a data flow initiates and maintains the resource reservation
used for that flow. Note that each router receives a reservation message
from each of its downstream links in the multicast tree and sends only
one reservation message into its upstream link.
As another example,
suppose that four persons are participating in a video conference, as shown
in Figure 6.35. Each person has three windows open on her computer to look
at the other three persons. Suppose that the underlying routing protocol
has established the multicast tree among the four hosts as shown in the
diagram below. Finally, suppose each person wants to see each of the videos
at 3 Mbps. Then on each of the links in this multicast tree, RSVP would
reserve 9 Mbps in one direction and 3 Mbps in the other direction. Note
that RSVP does not merge reservations in this example, as each person wants
to receive three distinct streams.
An RSVP video conference example
an audio conference among the same four persons over the same multicast
tree. Suppose b bps are needed for an isolated audio stream. Because
in an audio conference it is rare that more than two persons speak at the
same time, it is not necessary to reserve 3 · b bps into
each receiver; 2 · b should suffice. Thus, in this last application
we can conserve bandwidth by merging reservations.
Just as the
manager of a restaurant should not accept reservations for more tables
than the restaurant has, the amount of bandwidth on a link that a router
reserves should not exceed the link's capacity. Thus whenever a router
receives a new reservation message, it must first determine if its downstream
links on the multicast tree can accommodate the reservation. This admission
test is performed whenever a router receives a reservation message.
If the admission test fails, the router rejects the reservation and returns
an error message to the appropriate receiver(s).
RSVP does not
define the admission test, but it assumes that the routers perform such
a test and that RSVP can interact with the test.
6.8.3: Path Messages
So far we have
only discussed the RSVP reservation messages. These messages originate
at the receivers and flow upstream toward the senders. Path messages
are another important RSVP message type; they originate at the senders
and flow downstream toward the receivers.
purpose of the path messages is to let the routers know the links on which
they should forward the reservation messages. Specifically, a path message
sent within the multicast tree from a Router A to a Router B contains Router
A's unicast IP address. Router B puts this address in a path-state table,
and when it receives a reservation message from a downstream node it accesses
the table and learns that it should send a reservation message up the multicast
tree to Router A. In the future some routing protocols may supply reverse
path forwarding information directly, replacing the reverse-routing function
of the path state.
Along with some
other information, the path messages also contain a sender Tspec,
which defines the traffic characteristics of the data stream that the sender
will generate (see Section 6.7). This Tspec can be used to prevent over-reservation.
Through its reservation
style, a reservation message specifies whether merging of reservations
from the same session is permissible. A reservation style also specifies
the session senders from which a receiver desires to receive data. Recall
that a router can identify the sender of a datagram from the datagram's
source IP address.
There are currently
three reservation styles defined: wildcard-filter style, fixed-filter
style, and shared-explicit style.
created by the wildcard filter and the shared-explicit styles, are appropriate
for a multicast session whose sources are unlikely to transmit simultaneously.
Packetized audio is an example of an application suitable for shared reservations;
because a limited number of people talk at once, each receiver might issue
a wildcard-filter or a shared-explicit reservation request for twice the
bandwidth required for one sender (to allow for overspeaking). On the other
hand, the fixed-filter reservation, which creates distinct reservations
for the flows from different senders, is appropriate for video teleconferencing.
style. When a receiver uses the wildcard-filter style in its reservation
message, it is telling the network that it wants to receive all flows from
all upstream senders in the session and that its bandwidth reservation
is to be shared among the senders.
style. When a receiver uses the fixed-filter style in its reservation
message, it specifies a list of senders from which it wants to receive
a data flow along with a bandwidth reservation for each of these senders.
These reservations are distinct, that is, they are not to be shared.
style. When a receiver uses the shared-explicit style in its reservation
message, it specifies a list of senders from which it wants to receive
a data flow along with a single bandwidth reservation. This reservation
is to be shared among all the senders in the list.
of Reservation Styles
RSVP Internet RFC, let's next consider a few examples of the three reservation
styles. In Figure 6.36, a router has two incoming interfaces, labeled A
and B, and two outgoing interfaces, labeled C and D. The many-to-many multicast
session has three senders--S1, S2, and S3--and three receivers--R1, R2,
and R3. Figure 6.36 also shows that interface D is connected to a LAN.
Sample scenario for RSVP reservation styles
all of the receivers use the wildcard-filter reservation. As shown in the
Figure 6.37, receivers R1, R2, and R3 want to reserve 4b, 3b,
and 2b, respectively, where b is a given bit rate. In
this case, the router reserves 4b on interface C and 3b on interface
D. Because of the wildcard-filter reservation, the two reservations from
R2 and R3 are merged for interface D. The larger of the two reservations
is used rather than the sum of reservations. The router then sends a reservation
message upstream to interface A and another to interface B; each of these
reservation message requests is 4b, which is the larger of 3b
Wildcard filter reservations
that all of the receivers use the fixed-filter reservation. As shown in
Figure 6.38, receiver R1 wants to reserve 4b for source S1 and 5b for source
S2; also shown in the figure are the reservation requests from R2 and R3.
Because of the fixed-filter style, the router reserves two disjoint chunks
of bandwidth on interface C: one chunk of 4b for S1 and another
chunk of 5b for S2. Similarly, the router reserves two disjoint
chunks of bandwidth on interface D: one chunk of 3b for S1 (the
maximum of b and 3b) and one chunk of b for S3. On
interface A, the router sends a message with a reservation for S1 of 4b
(the maximum of 3b and 4b). On interface B, the router sends
a message with a reservation of 5b for S2 and b for S3.
Fixed filter reservations
that each of the receivers use the shared-explicit reservation. As shown
in Figure 6.39, receiver R1 desires a pipe of 1b, which is to be
shared between sources S1 and S2; receiver R2 desires a pipe of 3b
to be shared between sources S1 and S3; and receiver R3 wants a pipe of
2b for source S2. Because of the shared-explicit style, the reservations
from R2 and R3 are merged for interface D. Only one pipe is reserved on
interface D, although it is reserved at the maximum of the reservation
rates. RSVP will reserve on interface B a pipe of 3b to be shared
by S2 and S3; note that 3b is the maximum of the downstream reservations
for S2 and S3.
In each of the
above examples the three receivers used the same reservation style. Because
receivers make independent decisions, the receivers participating in a
session could use different styles. RSVP does not permit, however, reservations
of different styles to be merged.
The Principle of Soft State
The reservations in the routers and hosts are maintained
with soft states. By this it is meant that each reservation for bandwidth
stored in a router has an associated timer. If a reservation's timer expires,
then the reservation is removed. If a receiver desires to maintain a reservation,
it must periodically refresh the reservation by sending reservation messages.
This soft-state principle is also used by other protocols in computer networking.
As we learned in Chapter 5, for the routing tables in transparent bridges,
the entries are refreshed by data packets that arrive to the bridge; entries
that are not refreshed are timed-out. On the other hand, if a protocol
takes explicit actions to modify or release state, then the protocol makes
use of hard state. Hard state is employed in virtual circuit networks (VC),
in which explicit actions must be taken to adjust VC tables in switching
nodes to establish and tear down VCs.
of Reservation Messages
RSVP messages are
sent hop-by-hop directly over IP. Thus the RSVP message is placed in the
information field of the IP datagram; the protocol number in the IP datagram
is set to 46. Because IP is unreliable, RSVP messages can be lost. If an
RSVP path or reservation message is lost, a replacement refresh message
should arrive soon.
An RSVP reservation
message that originates in a host will have the host's IP address in the
source address field of the encapsulating IP datagram. It will have the
IP address of the first router along the reserve path in the multicast
tree in the destination address in the encapsulating IP datagram. When
the IP datagram arrives at the first router, the router strips off the
IP fields and passes the reservation message to the router's RSVP module.
The RSVP module examines the message's multicast address (that is, session
identifier) and style type, examines its current state, and then acts appropriately;
for example, the RSVP module may merge the reservation with a reservation
originating from another interface and then send a new reservation message
to the next router upstream in the multicast tree.
Because a reservation
request that fails an admission test may embody a number of requests merged
together, a reservation error must be reported to all the concerned receivers.
These reservation errors are reported within ResvError messages.
The receivers can then reduce the amount of resource that they request
and try reserving again. The RSVP standard provides mechanisms to allow
the backtracking of the reservations when insufficient resources are available;
unfortunately, these mechanisms add significant complexity to the RSVP
protocol. Furthermore, RSVP suffers from the so-called killer-reservation
problem, whereby a receiver requests a large reservation over and over
again, each time getting its reservation rejected due to lack of sufficient
resources. Because this large reservation may have been merged with smaller
reservations downstream, the large reservation may be excluding smaller
reservations from being established. To solve this thorny problem, RSVP
uses the ResvError messages to establish additional state in routers, called
blockade state. Blockade state in a router modifies the merging procedure
to omit the offending reservation from the merge, allowing a smaller request
to be forwarded and established. The blockade state adds yet further complexity
to the RSVP protocol and its implementation.