I-D ACTION:draft-ietf-rap-framework-01.txt

Internet-Drafts@ietf.org Tue, 24 November 1998 00:15 UTC

Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id TAA07921 for ietf-123-outbound.10@ietf.org; Mon, 23 Nov 1998 19:15: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 RAA04592; Mon, 23 Nov 1998 17:58:16 -0500 (EST)
Message-Id: <199811232258.RAA04592@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: rap@iphighway.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rap-framework-01.txt
Date: Mon, 23 Nov 1998 17:58:15 -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 RSVP Admission Policy Working Group of the IETF.

	Title		: A Framework for Policy-based Admission Control
	Author(s)	: R. Yavatkar, D. Pendarakis, R. Guerin
	Filename	: draft-ietf-rap-framework-01.txt
	Pages		: 24
	Date		: 20-Nov-98
	
  The IETF working groups such as Integrated Services (called 'int-serv')
  and RSVP [1] have developed extensions to the IP architecture and the
  best-effort service model so that applications or end users can request
  specific quality (or levels) of service from an internetwork in addition
  to the current IP best-effort service. Recent efforts in the Differen-
  tiated Services Working Group are also directed at definition of mechan-
  isms that support aggregate QoS services. The int-serv model for these new
  services requires explicit signaling of the QoS (Quality of Service)
  requirements from the end points and provision of admission and traffic
  control at Integrated Services routers. The proposed standards for RSVP
  [RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples of a
  new reservation setup protocol and new service definitions respectively.
  Under the int-serv model, certain data flows receive preferential treat-
  ment over other flows; the admission control component only takes into
  account the requester's  resource reservation request and available capa-
  city to determine whether or not to accept a QoS request. However, the
  int-serv mechanisms do not include  an important aspect of admission con-
  trol: network managers and service providers must be able to monitor, con-
  trol, and enforce use of network resources and services based on policies
  derived from criteria such as the identity of users and applications,
  traffic/bandwidth requirements, security considerations, and time-of-
  day/week. Similarly, diff-serv mechanisms also need to take into account
  policies that take into account various criteria such as customer iden-
  tity, ingress points, and so on.

  This document is concerned with specifying a framework for providing
  policy-based control over admission control decisions. In particular, it
  focuses on policy-based control over admission control using RSVP as an
  example of the QoS signaling mechanism. Even though the focus of the work
  is on RSVP-based admission control, the document outlines a framework that
  can provide policy-based admission control in other QoS contexts. We argue
  that policy-based control must be applicable to different kinds and quali-
  ties of services offered in the same network and our goal is to consider
  such extensions whenever possible.
 
  We begin with a list of definitions in Section 2. Section 3 lists the
  requirements and goals of the mechanisms capable of controlling and
  enforcing access to better QoS.  We then outline the architectural ele-
  ments of the framework in Section 4 and describe the functionality assumed
  for each component.  Section 5 discusses example policies, possible
  scenarios, and policy support needed for those scenarios. Section 6 speci-
  fies the requirements for a client-serv protocol for communication between
  a policy server (PDP) and its client (PEP) and evaluates suitability of
  some of the existing protocols for this purpose.

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-rap-framework-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-rap-framework-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-rap-framework-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.
ftp://ftp.ietf.org/internet-drafts/draft-ietf-rap-framework-01.txt"><ftp://ftp.ietf.org/internet-drafts/draft-ietf-rap-framework-01.txt>