07-08-2012, 02:43 PM
Resource Reservation Protocol
rsvp[1].pdf (Size: 45.66 KB / Downloads: 22)
RSVP Data Flows
In RSVP, a data flow is a sequence of messages that have the same source, destination (one or more),
and quality of service. QoS requirements are communicated through a network via a flow
specification, which is a data structure used by internetwork hosts to request special services from
the internetwork. A flow specification often guarantees how the internetwork will handle some of its
host traffic.
RSVP supports three traffic types: best-effort, rate-sensitive, and the delay-sensitive. The type of
data-flow service used to support these traffic types depends on QoS implemented. The following
sections address these traffic types and associated services. For information regarding QoS, refer to
the appropriate section later in this chapter.
Best-effort traffic is traditional IP traffic. Applications include file transfer, such as mail
transmissions, disk mounts, interactive logins, and transaction traffic. The service supporting
best-effort traffic is called best-effort service.
Rate-sensitive traffic is willing to give up timeliness for guaranteed rate. Rate-sensitive traffic, for
example, might request 100 kbps of bandwidth. If it actually sends 200 kbps for an extended period,
a router can delay traffic. Rate-sensitive traffic is not intended to be run over a circuit-switched
network; however, it usually is associated with an application that has been ported from a
circuit-switched network (such as ISDN) and is running on a datagram network (IP).
RSVP Data Flows Process
RSVP data flows are generally characterized by sessions, over which data packets flow. A session is
a set of data flows with the same unicast or multicast destination, and RSVP treats each session
independently. RSVP supports both unicast and multicast sessions (where a session is some number
of senders talking to some number of receivers), whereas a flow always originates with a single
sender. Data packets in a particular session are directed to the same IP destination address or a
generalized destination port. The IP destination address can be the group address for multicast
delivery or the unicast address of a single receiver. A generalized destination port can be defined by
a UDP/TCP destination port field, an equivalent field in another transport protocol, or some
application-specific information.
RSVP Quality of Service (QoS)
In the context of RSVP, quality of service (QoS) is an attribute specified in flow specifications that
is used to determine the way in which data interchanges are handled by participating entities
(routers, receivers, and senders). RSVP is used to specify the QoS 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.
RSVP Session Start-up
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). In the case of a
unicast session, unicast routing serves the function that IGMP, coupled with Protocol-Independent
Multicast (PIM), serves in the multicast case. 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.
RSVP Reservation Style
Reservation style refers to a set of control options that specify a number of supported parameters.
RSVP supports two major classes of reservation: distinct reservations and shared reservations.
Distinct reservations install a flow for each relevant sender in each session. A shared reservation is
used by a set of senders that are known not to interfere with each other. Figure 43-2 illustrates
distinct and shared RSVP reservation-style types in the context of their scope. Each supported
reservation style/scope combination is described following the illustration.