Browse Prior Art Database

Specification of the Null Service Type (RFC2997)

IP.com Disclosure Number: IPCOM000005191D
Original Publication Date: 2000-Nov-01
Included in the Prior Art Database: 2001-Aug-17
Document File: 13 page(s) / 25K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

Y. Bernet: AUTHOR [+3]

Abstract

In the typical Resource Reservation Protocol (RSVP)/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, ERP applications are often mission critical and require some form of prioritized service, but cannot readily specify their resource requirements. To serve such applications, we introduce the notion of the 'Null Service'. The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling [intdiff]. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 15% of the total text.

Network Working Group Y. Bernet Request for Comments: 2997 Microsoft Category: Standards Track A. Smith Allegro Networks

B. Davie Cisco Systems November 2000

Specification of the Null Service Type

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.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

In the typical Resource Reservation Protocol (RSVP)/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, ERP applications are often mission critical and require some form of prioritized service, but cannot readily specify their resource requirements. To serve such applications, we introduce the notion of the 'Null Service'. The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling [intdiff]. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service.

Bernet, et al. Standards Track [Page 1]

RFC 2997 Specification of Null Service Type November 2000

1. Motivation

Using standard RSVP/Intserv signaling, applications running on hosts issue requests for network resources by communicating the following information to network devices:

1. A requested service level (Guaranteed or Controlled Load). 2. The quantity of resources required at that service level. 3. Classification information by which the network can recognize

specific traffic (filterspec). 4. Policy/identity information indicating the user and/or the

application for which resources are required.

In response, standard RSVP aware network nodes choose to admit or deny a resource request. The decision is based on the availability of resources along the relevant path and on policies. Policies define the resources that may be granted to specific users and/or applications. When a resource request is admitted, network nodes install classifiers that are used to recognize the admitted traffic and policers that are used to assure that the traffic remains within the limits of the resources requested.

The Guaranteed and Controlled Load Intserv services are not suitable for certain applications that ...