I-D ACTION:draft-ietf-diffserv-rsvp-01.txt
Internet-Drafts@ietf.org Tue, 24 November 1998 01:05 UTC
Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id UAA10271 for ietf-123-outbound.10@ietf.org; Mon, 23 Nov 1998 20:05:02 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04563; Mon, 23 Nov 1998 17:58:09 -0500 (EST)
Message-Id: <199811232258.RAA04563@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: diff-serv@baynetworks.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-diffserv-rsvp-01.txt
Date: Mon, 23 Nov 1998 17:58:08 -0500
Sender: cclark@ns.cnri.reston.va.us
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: mailserv@ietf.org. 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.
- I-D ACTION:draft-ietf-diffserv-rsvp-01.txt Internet-Drafts