Subject: I-D ACTION:draft-ietf-diffserv-rsvp-01.txt

From: [email-masked]
Date: Mon, 23 Nov 1998 17:58:08 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Differentiated Services Working Group of the IETF.

	Title		: A Framework for Use of RSVP with Diff-serv Networks
	Author(s)	: Y. Bernet, R. Yavatkar, P. Ford,  F. Baker,
                          L. Zhang, K. Nichols, M. Speer 
	Filename	: draft-ietf-diffserv-rsvp-01.txt
	Pages		: 21
	Date		: 20-Nov-98
	
  In the past several years, work on QoS enabled networks led to the
  development of the Integrated Services (Intserv) architecture [12] and
  the RSVP signaling protocol [1]. RSVP, as specified, enables applica-
  tions to signal per-flow requirements to the network. Intserv parame-
  ters are used to quantify these requirements for the purpose of admis-
  sion control. However, as work on RSVP and Intserv has proceeded, we
  have recognized the following basic limitations, which impede deploy-
  ment of these mechanisms in the Internet at large:
 
  1) The reliance of RSVP on per-flow state and per-flow processing
  raises scalability concerns in large networks.
  2) Today, only a small number of hosts generate RSVP signaling.
  While this number is expected to grow dramatically, many
  applications may never generate RSVP signaling.
  3) Many applications require a form of QoS, but are unable to
  express these requirements using the intserv model.
 
  At present, the market is pushing for immediate deployment of a QoS
  solution that addresses the needs of the Internet as well as enter-
  prise networks. This push has led to the development of Differentiated
  services (diff-serv). In contrast to RSVP's per-flow orientation,
  diff-serv networks classify packets to one of a small number of aggre-
  gated flows, based on the setting of bits in the TOS field of each
  packet's IP header. Thus, in addition to eliminating the reliance on
  per-flow state, diff-serv QoS can initially be deployed using top-down
  provisioning, with no requirement for end-to-end signaling.
 
  At the same time however, it is important to assure that the diff-serv
  mechanisms deployed, interoperate effectively with hosts and networks
  that provide per-flow QoS in response to end-to-end signaling. This is
  important, as we believe that in the coming years, there will be a
  proliferation of applications that depend on QoS and of hosts which
  will signal end-to-end on their behalf.
 
  This draft proposes a framework in which diff-serv capable networks
  provide aggregate QoS services, and they co-exist and inter-operate
  with RSVP/Intserv capable hosts and stub networks, which use end-to-
  end signaling.
 
  For instance, in one example of such a model, diff-serv mechanisms are
  used within transit networks and at the boundaries between them, while
  either diff-serv or RSVP/Intserv mechanisms are used within stub net-
  works and at the boundaries between stub networks and transit diff-
  serv networks. Managers of the transit networks will provision a pool
  of network resources to be available in response to end-to-end signal-
  ing. The remaining resources will be allotted using traditional 'top-
  down' provisioning methods.
 
  However, our model does not preclude other possibilities: use of
  diff-serv mechanisms and top-down provisioning in both stub and tran-
  sit networks to support applications that do not use any explicit sig-
  naling, or use of RSVP signaling for admission control in conjunction
  with diff-serv mechanisms in transit networks. In particular, the pro-
  posed framework will allow for a scenario in which RSVP signaling is
  used for dynamic provisioning and admission control in the diffserv
  region of the network. In such a case, routers in the diff-serv region
  will continue use the DSCP value in the IP datagram to identify and
  offer services to flow aggregates. However, some of these services
  will use dynamic provisioning and require admission control using
  explicit signaling when a new flow is to be added to the aggregate.
  Under such a scenario, one can envision use of RSVP signaling to com-
  municate the flow specification and desired DSCP (flow aggregate) to
  the routers in the diff-serv region of the network.
 
  Our framework allows the deployment of diff-serv networks and
  RSVP/Intserv networks to proceed at their own pace, providing immedi-
  ate incremental benefits in areas of the network in which one or the
  other is deployed and additional benefits where both are deployed.
  This framework builds upon current work in the IETF including diff-
  serv [10] and RSVP aggregation [8].
 
  Many of the ideas in this document have been previously discussed in
  the original intserv architecture document [12].

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-diffserv-rsvp-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-diffserv-rsvp-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-diffserv-rsvp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.