 RSVP:
Signaling Quality of Service
Ron McCarty
The convergence of voice and data networks has created many efforts
to guarantee adequate bandwidth with minimal delay for voice applications
within IP networks.
This month I'll examine the Resource reSerVation Protocol
(RSVP). RSVP is a signaling protocol designed for IP networks that
allocates quality of service agreements based upon application requirements.
RSVP is defined by RFC 2205, but has various support documents available
from the RSVP IETF working group's web site at:
http://www.ietf.org/html.charters/rsvp-charter.html
Although RSVP at first seems complex, the protocol is relatively simple
when compared to more complex signaling, such as those used by telephone
networks (SS7), the time division multiplexing portion of telephone
networks (Q.931), or ATM. An understanding of RSVP will help determine
where and when the protocol can be deployed in your network. The IETF
RSVP working group provides information concerning the logical architecture
of RSVP routers. Although important, there is more confusion concerning
the protocol than the architecture, so I'll cover it here. Additionally,
because signaling is new to many network administrators, an overview
of RSVP will provide a better understanding of signaling in general,
and the challenges of implementing signaling in IP networks --
networks that have traditionally been best effort.
Why Signal Quality of Service?
By signaling (and agreeing) to the Quality of Service (QoS) requests,
all nodes partaking in the RSVP request are agreeing to the bandwidth
and delay requirements during the application's use. Unlike
typical IP-oriented mechanisms (which rely on the type of service
(ToS)), or DiffServ bits (which rely on traffic shaping and intelligent
queuing, where multiple client requests can still overwhelm the
routers involved), RSVP will not grant additional sessions if the
QoS requirement cannot be met. However, this does not mean that
vendors will not use the same mechanisms because queuing traffic
shaping and drop algorithms are needed for both solutions.
The telephone system is a good analogy for these two types of
solutions. Using ToS and DiffServ is similar to using a party line
-- if everyone speaks at once, not everyone will be understood.
A signal protocol, however, is similar to a dedicated link --
you'll receive a busy signal if someone is using the link when
you are making the call. (For further discussion of Quality of Service,
refer to Gil Held's series of articles, beginning with the
September 2000 issue of Sys Admin.)
A Closer Look
The RSVP sender and receiver signals the network for the path
and QoS features required for the application. This path is referred
to as an RSVP session. The session is identified by the sender's
IP address, the protocol ID (which is 46 for RSVP, as defined by
the Internet Assigned Numbers authority), and the destination port
(with TCP and UDP both being supported). The session is actually
created using two messages: PATH and RESV. The source node sends
a PATH message to the destination, which helps determine the RSVP
nodes involved. As each node inspects the packet, the node determines
its RSVP neighbors. This PATH message takes the same path as other
IP traffic. RSVP nodes set the previous hop (PHOP) bits in the PATH
message to its address, which is used by the next RSVP node to identify
its upstream neighbor, as previously mentioned. The QoS parameters
required by the sender are also carried in the PATH message.
Upon receipt of the PATH message, the destination node (the receiver)
then signals a reservation request with a RESV message. Thus, the
receiver signals the reservation request.
Unlike the PATH message, the RESV message destination IP address
actually contains the address of the RSVP upstream router, which
was determined using the PHOP. Each hop along the way will use the
PHOP to ensure that the same path from source to destination is
also used for the return path for the RESV message. The RSVP node
will then track the session and use the session table to base routing
decisions on, as opposed to the "normal" routing table.
This will not seem intuitive for experienced IP network administrators,
but remember that symmetrical paths and state tables are much easier
to manage and are almost a requirement for signaling.
RFC 2205 defines RSVP message formats, but a closer look within
this context will reinforce the principals of the protocol. Here
is the 32-bit header format:
These 4 bits define the version of RSVP used. Currently the value
is 1, but will change with future versions.
Currently not used.
We've covered the PATH and RESV messages that are defined
as 1 and 2, respectively. Other message types are: PathErr
(3), ResvErr (4), PathTear (5), ResvTear (6),
and ResvConf (7). The PathTear and ResvTear
are covered below.
The checksum is used to ensure the packet has been received intact.
The checksum does not have to be used and has the value 0 if it
isn't used.
QoS Request
The QoS request in the RSVP is not defined by the IETF Working
Group. However, it is defined by the Integrated Services IETF working
group, and more specifically, RFC 2210 ("The Use of RSVP with
IETF Integrated Services"), and RFC 2212, ("Specification
of Guaranteed Quality of Service"). The two are not bundled
together, thus allowing greater flexibility to the Internet community
and network designers.
The signaling that specifies the sender's QoS requirements
for the QoS is made up of two elements that are sent with the PATH
messages: the sender TSPEC (sender traffic specification) and the
ADSPEC. The sender TSPEC describes the amount of traffic. The ADSPEC
specifies the QoS characteristics, such as bit rate, latency, number
of hops, and so on. The receiver's QoS attributes are signaled
much like the sender's, by using a receiver TSPEC and ADSPEC
in much the same way. However, the RESV message contains these QoS
attributes.
Ending Sessions and Soft States
RSVP simulates keep-alive timers used in other networking topologies
through the use of soft states. Should RSVP messages concerning
a session not be received within a predefined interval (the "cleanup
timeout"), then the router will delete the reservation state.
This ensures that resources are returned to the router for further
assignment should a node or network failure cause a new path around
the failure.
Additionally, closure of sessions can also be signaled using tear
messages. If a reservation (RESV) is to be closed, then an RESV
tear down is sent from the destination to the source, hop-by-hop,
once again using the PHOP to ensure the RESV tear down follows the
same path as the RESV.
The PATH tear down is initiated by the sender of the data flow
and travels to the source using the normal routing mechanism based
upon the destination IP address.
Integration with Current Networks
Although RSVP adds functionality to IP, it does not require changes
to the IP protocol. RSVP does ensure the return path or reservation
path based upon the information gained from the PATH determination,
but it is not a routing protocol and can, like any other IP protocol,
take advantage of routing protocols. (With the requirement that
the RESV message uses the IP address of the PHOP as the destination
-- not the ultimate destination, which is the source of the
data stream and the original PATH request.)
Since migration to RSVP cannot be a major migration effort for
many networks, RSVP neighbors do not need to be directly connected.
Additionally, RFC 2746 ("RSVP Operation Over IP Tunnels")
defines RSVP in IP over IP tunnels with support for three distinct
link types for supporting best effort, data flow QoS tunnels, and
QoS tunnels with individual data flow QoS agreements.
Since many applications do not know the QoS requirements and are
not RSVP aware, the RSVP working group is also working on RSVP proxies.
Although the RSVP proxy specification is still in draft, RSVP proxies
will likely play a major role in early implementations and acceptance
of RSVP.
These solutions may not provide complete QoS throughout a network,
but they do provide the network management some added flexibility
to phase in the technology.
Summary
Convergence of voice and data networks creates many solutions
to providing QoS over IP networks. RSVP is receiving wider vendor
support and will be deployed in networks requiring QoS features.
Understood correctly, RSVP can help you integrate services into
your network. I hope this month's column has removed some of
the mystique from RSVP.
Ronald McCarty received his bachelor's degree in Computer
and Information Systems at the University of Maryland's international
campus at Schwaebisch Gmuend, Germany. After completing his degree,
Ronald McCarty started his network career as network administrator
at the Schwaebisch Gmuend campus. Ronald McCarty works for Lucent
Technologies as a senior systems engineer on a customer team responsible
for a major telecommunications carrier. He spends his free time
with his two best friends in the world: his daughter, Janice, and
his wife, Claudia. Ron can be reached at: ronald.mccarty@gte.net.
| 
