Network Working Group
Request for Comments: 2205
Category: Standards Track
R. Braden, Ed.
Univ. of Michigan
Resource ReSerVation Protocol (RSVP) -
Version 1 Functional Specification
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or
unicast data flows, with good scaling and robustness properties.
Table of Contents
This revision contains the following very minor changes from the ID14
For clarity, each message type is now defined separately in
We added more precise and complete rules for accepting Path
messages for unicast and multicast destinations (Section
We added more precise and complete rules for processing and
forwarding PathTear messages (Section 3.1.5).
A note was added that a SCOPE object will be ignored if it
appears in a ResvTear message (Section 3.1.6).
A note was added that a SENDER_TSPEC or ADSPEC object will be
ignored if it appears in a PathTear message (Section 3.1.5).
The obsolete error code Ambiguous Filter Spec (09) was
removed, and a new (and more consistent) name was given to
error code 08 (Appendix B).
In the generic interface to traffic control, the Adspec was
added as a parameter to the AddFlow and ModFlow calls
(3.11.2). This is needed to accommodate a node that updates
the slack term (S) of Guaranteed service.
An error subtype was added for an Adspec error (Appendix B).
Additional explanation was added for handling a CONFIRM
object (Section 3.1.4).
The rules for forwarding objects with unknown class type were
Additional discussion was added to the Introduction and to
Section 3.11.2 about the relationship of RSVP to the link
layer. (Section 3.10).
Section 2.7 on Policy and Security was split into two
sections, and some additional discussion of security was