Browse Prior Art Database

The Use of RSVP with IETF Integrated Services (RFC2210)

IP.com Disclosure Number: IPCOM000002768D
Original Publication Date: 1997-Sep-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 25 page(s) / 72K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Wroclawski: AUTHOR

Abstract

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 text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 4% of the total text.

Network Working Group J. Wroclawski

Request for Comments: 2210 MIT LCS

Category: Standards Track September 1997

The Use of RSVP with IETF Integrated Services

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Abstract

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.

1. Introduction

The Internet integrated services framework provides the ability for

applications to choose among multiple, controlled levels of delivery

service for their data packets. To support this capability, two

things are required:

- Individual network elements (subnets and IP routers) along the

path followed by an application's data packets must support

mechanisms to control the quality of service delivered to those

packets.

- A way to communicate the application's requirements to network

elements along the path and to convey QoS management information

between network elements and the application must be provided.

In the integrated services framework the first function is provided

by QoS control services such as Controlled-Load [RFC 2211] and

Guaranteed [RFC 2212]. The second function may be provided in a

number of ways, but is frequently implemented by a resource

reservation setup protocol such as RSVP [RFC 2205].

Because RSVP is designed to be used with a variety of QoS control

services, and because the QoS control services are designed to be

used with a variety of setup mechanisms, a logical separation exists

between the two specifications. The RSVP specification does not

define the internal format of those RSVP protocol fields, or objects,

which are related to invoking QoS control services. Rather, RSVP

treats these objects as opaque. The objects can carry different

information to meet different application and QoS control service

requirements.

Similarly, interfaces to the QoS control services are defined in a

general format, so that the services can be used with a variety of

setup mechanisms.

This RFC provides the information required to use RSVP and the

integrated service framework's QoS control services together. It

defines the usage and contents of three RSVP protocol objects, the

FLOWSPEC, ADSPEC, and SENDER_TSPEC, in an environment supporting the

Controlled-Load and/or Guaranteed QoS con...