Protocol Action: The Use of RSVP to Proposed Standard
The IESG <iesg-secretary@ietf.org> Wed, 03 September 1997 12:38 UTC
Received: from ietf.org by ietf.org id aa05814; 3 Sep 97 8:38 EDT
Received: from ietf.ietf.org by ietf.org id aa05766; 3 Sep 97 8:36 EDT
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: int-serv@isi.edu, rsvp@isi.edu
Sender: ietf-announce-request@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The Use of RSVP to Proposed Standard
Date: Wed, 03 Sep 1997 08:36:30 -0400
X-Orig-Sender: scoya@ietf.org
Message-ID: <9709030836.aa05766@ietf.org>
NOTE: This announcement replaces the previous announcement which
contained references to incorrect versions of some documents.
The IESG has approved of the following the Internet-Drafts as
Proposed Standards:
o Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification
<draft-ietf-rsvp-spec-16.txt>
o RSVP Cryptographic Authentication
<draft-ietf-rsvp-md5-05.txt>
o RSVP Management Information Base
<draft-ietf-rsvp-mib-10.txt>
o RSVP Extensions for IPSEC Data Flows
<draft-berger-rsvp-ext-08.txt>
The IESG also approved publication of the following Internet-Drafts as
Informational RFCs:
o Resource ReSerVation Protocol (RSVP) -- Version 1
Applicability Statement
<draft-ietf-rsvp-intsrv-analysis-01.txt>
o Resource ReSerVation Protocol (RSVP) --
Version 1 Message Processing Rules
<draft-ietf-rsvp-procrules-00.txt >
These documents are products of the Resource Reservation Setup Protocol
Working Group. The IESG contact persons are Scott Bradner and Allyn
Romanow.
Technical Summary
This set of documents describes RSVP, a unicast and multicast
signalling protocol, designed to install and maintain reservation
state information in routers along the path of a stream of data,
along with technology to ensure the security of the signaling
protocol and MIBs to support SNMP management of RSVP systems. Hosts
can use RSVP to request specific qualities of service (QoS) from a
network for particular application data streams or flows. Routers
can use RSVP to forward these requests along the data path and to
maintain the state required to provide the requested QoS.
Quality of service is implemented for a particular data flow by
mechanisms collectively called "traffic control". These mechanisms
include (1) a packet classifier, (2) admission control, and (3) a
"packet scheduler" or some other link-layer-dependent mechanism to
determine when particular packets are forwarded. The "packet
classifier" determines the QoS class (and perhaps the route) for each
packet. For each outgoing interface, the "packet scheduler" or other
link-layer-dependent mechanism achieves the promised QoS. Traffic
control implements QoS service models defined by the Integrated
Services Working Group.
Because RSVP and the integrated services mark a significant change to
the service model of IP networks, RSVP has received considerable
interest and press in advance of its release as a standards track
RFC. At present, many vendors of operating systems and routers are
incorporating RSVP and integrated services into their products for
near-future availability. The goal of the accompanying applicability
statement is to describe those uses of the current RSVP specification
that are known to be feasible, and to identify areas of known
limitations.
Working Group Summary
The documents have been extensively discussed in the rsvp working
group and on various mailing lists. The current set of documents
accurately reflects working group consensus. A few comments were
received during IETF last-call about the clarity of some of the
documents and about the security considerations sections. The
documents have been updated to reflect the comments.
Protocol Quality
The documents were reviewed for the IESG by Scott Bradner and Allison
Mankin.