Subject: Protocol Action: The Use of RSVP to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 25 Aug 1997 16:48:03 -0400

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-04.txt>

 o RSVP Management Information Base
	<draft-ietf-rsvp-mib-09.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.

e 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.