Internet DRAFT - draft-greis-rsvp-analysis
draft-greis-rsvp-analysis
Internet Engineering Task Force Marc Greis
INTERNET-DRAFT Nokia
draft-greis-rsvp-analysis-00.txt
Date: November 2001
Analysis of the RSVP Protocol
<draft-greis-rsvp-analysis-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The purpose of this document is to describe commonly known problems
with RSVP as a basis for future work on RSVP, which may result in an
improved version of RSVP.
Greis [Page i]
INTERNET-DRAFT Analysis of the RSVP Protocol November 2001
1. Introduction
This document summarizes the most commonly discussed problems with
the RSVP protocol as a basis for future work on improving RSVP. Note
that this document deals only with the signaling aspects of RSVP, but
not with the "service provisioning" aspects of the IntServ
architecture. Also note that the issues listed here do not
necessarily reflect the author's opinion, but are meant to provide an
unbiased summary of the most frequently discussed "complaints" about
RSVP. Future versions of this document will have to contain a more
detailed discussion of the different issues to determine which of
these problems need to be solved or which issues have already been
solved or do not need to be solved.
2. List of Issues
Please note that the list below is unsorted and does not imply any
prioritization.
2.1. Lack of Scalability
RSVP is generally not considered to be scalable due to the fact that
QoS signaling with RSVP is performed on a per-flow basis, which can
lead to a large amount of signaling state in the core of the network.
2.2. Complexity
It has been argued that RSVP is complex to implement, and that it may
be too "heavy" especially for low-end terminals. As an example, one
of the features which may lead to a high complexity is the handling
of multicast reservations, which implies the need for proper merging
of multiple reservations in a multicast tree.
2.3. Unidirectionality
RSVP has been designed to set up resources only in one direction
(from a sender to a receiver or a set of receivers). While this is
sufficient for streaming applications, it increases the complexity
for conversational applications, which require resources in both
directions between two end points, as both end points would have to
send Path and Resv messages.
Greis [Page 1]
INTERNET-DRAFT Analysis of the RSVP Protocol November 2001
2.4. Soft State
RSVP is based on a soft state concept, i.e. it is necessary to
refresh RSVP-related state periodically to keep the soft state from
expiring. While this is advantageous especially for networks where
routing changes may occur frequently or for cases where an end-point
loses connectivity without being able to tear down an existing
reservation, this may not be acceptable in environments where
bandwidth is scarce and expensive, e.g. cellular and other wireless
environments.
2.5. Slow Reservation Mechanism
To request QoS with RSVP, at least one round-trip time between sender
and receiver is required, as it is necessary for the sender to send a
Path message before the receiver can respond with a Resv message. It
is not possible to perform "forward reservations" with RSVP.
2.6. End-to-End vs. End-to-Edge/Edge-to-Edge
RSVP is inherently an end-to-end protocol. It is not clearly defined
how or if end nodes can use RSVP to request QoS from edge nodes or
how edge nodes can use RSVP to communicate with each other without
involving end nodes.
2.7. Mobility
RSVP as it is does not interwork well with Mobile IP. One important
point is that RSVP processes would run above IP in the end nodes,
i.e. they would not be aware of Mobile IP. However, the IP addresses
are encapsulated in objects within the RSVP messages, which may cause
discrepancies between the addresses used within the network (which
would be the nodes' care-of addresses) and the addresses used to
identify reservations (which would be the nodes' home addresses).
Furthermore, it is not clear how RSVP can efficiently support handoff
from one access point to another, by both removing the old
reservation immediately and by setting up the new reservation as
quickly as possible.
2.8. Security
While RSVP already contains security features, it may need to be
examined if any location privacy issues may arise from having to
Greis [Page 2]
INTERNET-DRAFT Analysis of the RSVP Protocol November 2001
exchange RSVP messages directly between end-points.
2.9. QoS Parameters
The commonly used QoS parameters in RSVP messages are based on the
IntServ model which is targeted at specifying flow requirements based
mostly on bandwidth requirements as well as queueing delay
requirements (for Guaranteed Service). However, this may not be
sufficient for cases where a host in a wireless network may want to
use RSVP to signal QoS requirements to other devices or network
nodes, as there is no means for deriving wireless-specific
requirements (e.g. acceptable error ratios) from the IntServ-specific
parameters.
3. Possible Solutions
This document is not intended to give a thorough analysis of
potential existing solutions for the different issues discussed here.
However, some of the most important drafts and RFCs which address
some of these issues are listed below (in no particular order). The
intention of this list is simply to acknowledge the fact that there
is an "RSVP extension suite", which will have to be taken into
consideration in future discussions.
- "Aggregation of RSVP for IPv4 and IPv6 Reservations" [1], RFC
3175
- "RSVP Proxy" [2], draft-ietf-rsvp-proxy-02.txt (Work in Progress)
- "RSVP Refresh Overhead Reduction Extensions" [3] RFC 2961
Note that this list is not only incomplete from the IETF point-of-
view, but it also ignores "outside work" (e.g. packet cable additions
to RSVP).
4. References
[1] Baker, F., et al, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001
Greis [Page 3]
INTERNET-DRAFT Analysis of the RSVP Protocol November 2001
[2] Gai, S., et al, "RSVP Proxy", draft-ietf-rsvp-proxy-02.txt,
Work in Progress, July 2001
[3] Berger, L., et al, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001
5. Author's Address
Marc Greis
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 374 0629
Email: marc.greis@nokia.com
Greis [Page 4]
