This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ‘‘work in progress.’’ To learn the current status of any Internet-Draft, please check the ‘‘1id-abstracts.txt’ ’ listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). yavatkar, Ed., et. draft-ietf-issll-is802-sbm-07.txt [Page 1]

Network delivery services providing “better-than-best-effort ” service over the Internet are being studied, and are particularly necessary for multimedia applications. The selection and use of a specific delivery service involves negotiation between the user and the network; they agree upon specifications such as the type of service user packets will receive, the constraints the user traffic must adhere to, and the price to be charged for the service. In this paper, we describe a protocol through which the user and the network (or two network domains) can negotiate network services. We refer to the protocol as a Resource Negotiation and Pricing protocol (RNAP). Through RNAP, the network service provider communicates availability of services and delivers price quotations and charging information to the user, and the user requests or re-negotiates services with desired specifications for one or more flows. RNAP protocol mechanisms are flexible enough to support multiple delivery service models, and allow dynamic re-negotiation of services during a session. Two different network architectures are defined to support RNAP, a centralized architecture with a Network Resource Negotiator (NRN) administering each network domain, and a distributed architecture without any centralized controlling entity. Mechanisms are proposed for local price and charge computation, formulation of end-to-end prices and charges across multiple domains, and communication of this information through RNAP messages. Results of a prototype implementation are briefly described. 1

This memo describes a set of extensions for supporting generic policy based admission control in RSVP. 1 This document does not advocate particular policy control mechanisms; however, a recommendation for a mechanism built on top of these extensions can be found in [LPM]. 1 This memo could be conceived as an extension to the RSVP functional specifications [RSVPSP]. Internet Draft RSVP Extensions for Policy Control November 1996 Contents 1 Introduction 3 2 Policy Data Object Format 3 2.1 Base Format : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3 2.2 Policy Data Options : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 2.2.1 RSVP Objects : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 2.2.2 Policy Options : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 2.2.3 Options Constraints : : : : : : : : : : : : : : : : : : : : : : : : : : : 6 3 RSVP/Policy Control Interface 6 3.1 Policy Control Services : : : : : : : : : : :...

This document describes a protocol for exchanging policy information and decisions between an RSVP-capable router (client) and a policy server. The OOPS protocol supports a wide range of router configurations and RSVP implementations, and is compatible with the RSVP Extensions for Policy Control [Ext]. Internet Draft OOPS: Policy Protocol for RSVP Contents 1 Overview 4 1.1 Representative OOPS Scenarios : : : : : : : : : : : : : : : : : : : : : : : : : 4 2 Query-Response Protocol 6 2.1 Division of Labor between Client and Server : : : : : : : : : : : : : : : : : : 6 2.1.1 Error Reporting : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 7 2.2 State Management : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 2.2.1 Client State Information Cached at Server : : : : : : : : : : : : : : : 9 2.2.2 Server State Information Cached at Client : : : : : : : : : : : : : : : 9 2.2.3 State Change Notification : : : : : : : : : : : : : : : : : : : : : : : : 10 3 Client-S...

This document is an Internet-Draft and is in full conformance with all

Contents 1 Project: Support of Integrated Services in IPS 5 1.1 Project Title and Leaders : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 1.2 Chronological Summary and Date of Last Update : : : : : : : : : : : : : : : : : 5 1.3 Executive Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 1.4 Problem Description : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6 1.4.1 The Effort to Evolve the IPS into the ISPSN : : : : : : : : : : : : : : : 6 1.4.1.1 The Players and The Process : : : : : : : : : : : : : : : : : : 7 1.4.1.2 The Goals and Assumptions : : : : : : : : : : : : : : : : : : 7 1.4.1.3 The General Outlook : : : : : : : : : : : : : : : : : : : : : : 8 1.4.2 Core Elements of the ISPSN and Identified Technical Barriers : : : : : : 9 1.4.2.1 Packet Level Scheduling, Admission Control, and Traffic Co

this article, the multicast infrastructure is emphasized and only CBT and PIM are examined.

This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This document accompanies the first submission of RSVP and integrated services specifications onto the Internet standards track.

This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. The RSVP protocol defines several data objects which carry resource reservation information but are opaque to RSVP itself. The usage and data format of those objects is given here.

This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt " listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This memo describes version 1 of RSVP, a resource reservation setup