Specification of the Null Service Type
RFC 2997

Document Type RFC - Proposed Standard (November 2000; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2997 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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 are unable to (or choose not to)specify
   the resources they require from the network.  Diffserv services are
   better suited for this type of application.  Nodes in a diffserv
   network are typically provisioned to classify arriving packets to
   some small number of behavior aggregates (BAs) [diffarch].  Traffic
   is handled on a per-BA basis.  This provisioning tends to be 'top-
   down' with respect to end-user traffic flows in the sense that there
   is no signaling between hosts and the network.  Instead, the network
   administrator uses a combination of heuristics, measurement and
   experience to provision the network devices to handle aggregated
   traffic, with no deterministic knowledge of the volume of traffic
   that will arrive at any specific node.

   In applying diffserv mechanisms to manage application traffic,
   network administrators are faced with two challenges:

   1. Provisioning - network administrators need to anticipate the
      volume of traffic likely to arrive at each network node for each
      diffserv BA.  If the volume of traffic arriving is likely to
      exceed the capacity available for the BA claimed, the network
      administrator has the choice of increasing the capacity for the
      BA, reducing the volume of traffic claiming the BA, or
      compromising service to all traffic arriving for the BA.

Show full document text