particular flow and what forwarding treatment to
provide. RSVP is a network control protocol that enables
applications to obtain prescriptive QoS for the application
data flows. Such a capability recognizes that different
applications have different network performance requirements.
Some applications, including the more traditional interactive
and batch applications, require reliable delivery of data but
do not impose any stringent requirements for the timeliness of
delivery. Newer application types, including videoconferencing,
IP telephony, and other forms of multimedia communication
require the opposite: Data delivery must be timely but not
necessarily reliable. Thus, RSVP was intended to provide IP
networks with the ability to support the divergent performance
requirements of differing application types. Figure lists the
characteristics of RSVP. RSVP is an IP protocol that uses IP
protocol ID 46 and TCP and UDP port 3455. It is important to
note that RSVP is not a routing protocol. RSVP works in
conjunction with routing protocols and installs the equivalent
of dynamic access control lists (ACLs) along the routes that
routing protocols calculate. Thus, implementing RSVP in an
existing network does not require migration to a new routing
protocol. In RSVP, a data flow is a sequence of datagrams that
have the same source, destination (regardless of whether that
destination is one or more physical machines), and QoS
requirements. QoS requirements are communicated through a
network via a flow specification, which is a data structure
that is used by internetwork hosts to request special services
from the internetwork. A flow specification describes the level
of service that is required for that data flow. RSVP focuses on
the following two main traffic types:
- Rate-sensitive traffic: Traffic that requires a
guaranteed and constant (or nearly constant) transmission rate
from its source to its destination. An example of such an
application is H.323 videoconferencing. RSVP enables
constant-bit-rate service in packet-switched networks via its
rate-sensitive level of service. This service is sometimes
referred to as guaranteed-bit-rate service.
-
Delay-sensitive traffic: Traffic that requires timeliness
of delivery and that varies its rate accordingly. MPEG-II
video, for example, averages about 3 to 7 Mbps, depending on
the rate at which the picture is changing. RSVP services
supporting delay-sensitive traffic are referred to as
controlled-delay service (non-real-time service) and predictive
service (real-time service).
Content
3.3 Selecting an Appropriate QoS
Policy Model 3.3.5 RSVP Operation Unlike
routing protocols, RSVP manages flows of data rather than
making decisions for individual datagrams. Data flows consist
of discrete sessions between specific source and destination
machines. The definition of a session is a simplex flow of
datagrams to a particular destination and transport layer
protocol. The following data identifies the sessions:
destination address, protocol ID, and destination port. RSVP
supports both unicast and multicast simplex sessions. In the
context of RSVP, QoS is an attribute specified in flow
specifications that determine how participating entities
(routers, receivers, and senders) handle data interchanges.
RSVP specifies the QoS used by both hosts and routers. Hosts
use RSVP to request a QoS level from the network on behalf of
an application data stream. Routers use RSVP to deliver QoS
requests to other routers along the path(s) of the data stream.
In doing so, RSVP maintains the router and host state to
provide the requested service. To initiate an RSVP multicast
session, a receiver first joins the multicast group specified
by an IP destination address by using the Internet Group
Membership Protocol (IGMP). After the receiver joins a group, a
potential sender starts sending RSVP path messages to the IP
destination address. The receiver application receives a path
message and starts sending appropriate reservation-request
messages specifying the desired flow descriptors using RSVP.
After the sender application receives a reservation-request
message, the sender starts sending data packets. How does
RSVP work?
Figure illustrates the RSVP daemon found in
each node capable of resource reservation. Each node that uses
RSVP has two local decision modules: - Admission
control: Admission control keeps track of the system
resources and determines whether the node has sufficient
resources to supply the requested QoS. The RSVP daemon monitors
both of these checking actions. If either check fails, the RSVP
program returns an error message to the application that
originated the request. If both checks succeed, the RSVP daemon
sets parameters in the packet classifier and packet scheduler
to obtain the requested QoS.
- Policy control:
Policy control determines whether the user has administrative
permission to make the reservation.
If both
Admission control and Policy control succeed, the daemon then
sets parameters in two entities, packet classifier and packet
scheduler. - Packet classifier: The RSVP packet
classifier determines the route and QoS class for each
packet.
- Packet scheduler: The RSVP packet
scheduler orders packet transmission to achieve the promised
QoS for each stream. The scheduler allocates resources for
transmission on the particular data link layer medium used by
each interface.
- Routing Process: The RSVP
daemon also communicates with the routing process to determine
the path to send its reservation requests and to handle
changing memberships and routes. Each router participating in
resource reservation passes incoming data packets to a packet
classifier and then queues the packets as necessary in a packet
scheduler.
Once the packet classifier determines
the route and QoS class for each packet, and the scheduler
allocates resources for transmission, RSVP passes the request
to all the nodes (routers and hosts) along the reverse data
paths to the data sources. At each node, the RSVP program
applies a local decision procedure called admission control to
determine whether that node can supply the requested QoS. If
admission control succeeds in providing the required QoS, the
RSVP program sets the parameters of the packet classifier and
scheduler to obtain the desired QoS. If admission control fails
at any node, the RSVP program returns an error indication to
the application that originated the request. Routers along the
reverse data stream path repeat this reservation until the
reservation merges with another reservation for the same source
stream. RSVP is not a routing protocol, but rather an internet
control protocol. RSVP relies on the underlying routing
protocols to find where it should deliver reservation requests.
When an RSVP-managed flow changes its path, the routing module
will notify the RSVP module of the route changes. In this way,
RSVP can quickly adjust the resource reservation to new
routes. Reservation Merging
When a potential
receiver initiates a reservation request, the request does not
need to travel all the way to the source of the sender.
Instead, it travels upstream until it meets another reservation
request for the same source stream. The request then merges
with that reservation. Figure shows how the reservation
requests merge as they progress up the multicast tree.
Reservation merging leads to the primary advantage of RSVP,
scalability. This allows a large number of users to join a
multicast group without significantly increasing the data
traffic. RSVP scales to large multicast groups. The average
protocol overhead decreases as the number of participants
increases. Note
Practical issues of latency and
propagation make it impossible to deploy RSVP or any new
protocol at the same moment to all points throughout the entire
Internet. Indeed, RSVP can never be deployed everywhere. To
support the connection of RSVP networks through non-RSVP
networks, RSVP supports tunneling, which occurs automatically