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]