New Terminology and Clarifications for Diffserv
RFC 3260

Document Type RFC - Informational (April 2002; Errata)
Author Daniel Grossman 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3260 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        D. Grossman
Request for Comments: 3260                                Motorola, Inc.
Updates: 2474, 2475, 2597                                     April 2002
Category: Informational

            New Terminology and Clarifications for Diffserv

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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


   This memo captures Diffserv working group agreements concerning new
   and improved terminology, and provides minor technical
   clarifications.  It is intended to update RFC 2474, RFC 2475 and RFC
   2597.  When RFCs 2474 and 2597 advance on the standards track, and
   RFC 2475 is updated, it is intended that the revisions in this memo
   will be incorporated, and that this memo will be obsoleted by the new

1.  Introduction

   As the Diffserv work has evolved, there have been several cases where
   terminology has needed to be created or the definitions in Diffserv
   standards track RFCs have needed to be refined.  Some minor technical
   clarifications were also found to be needed.  This memo was created
   to capture group agreements, rather than attempting to revise the
   base RFCs and recycle them at proposed standard.  It updates in part
   RFC 2474, RFC 2475 and RFC 2597.  RFC 2598 has been obsoleted by RFC
   3246, and clarifications agreed by the group were incorporated in
   that revision.

2. Terminology Related to Service Level Agreements (SLAs)

   The Diffserv Architecture [2] uses the term "Service Level Agreement"
   (SLA) to describe the "service contract... that specifies the
   forwarding service a customer should receive".  The SLA may include
   traffic conditioning rules which (at least in part) constitute a
   Traffic Conditioning Agreement (TCA).  A TCA is "an agreement

Grossman                     Informational                      [Page 1]
RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

   specifying classifier rules and any corresponding traffic profiles
   and metering, marking, discarding and/or shaping rules which are to

   As work progressed in Diffserv (as well as in the Policy WG [6]), it
   came to be believed that the notion of an "agreement" implied
   considerations that were of a pricing, contractual or other business
   nature, as well as those that were strictly technical.  There also
   could be other technical considerations in such an agreement (e.g.,
   service availability) which are not addressed by Diffserv.  It was
   therefore agreed that the notions of SLAs and TCAs would be taken to
   represent the broader context, and that new terminology would be used
   to describe those elements of service and traffic conditioning that
   are addressed by Diffserv.

      -  A Service Level Specification (SLS) is a set of parameters and
         their values which together define the service offered to a
         traffic stream by a DS domain.

      -  A Traffic Conditioning Specification (TCS) is a set of
         parameters and their values which together specify a set of
         classifier rules and a traffic profile.  A TCS is an integral
         element of an SLS.

   Note that the definition of "Traffic stream" is unchanged from RFC
   2475.  A traffic stream can be an individual microflow or a group of
   microflows (i.e., in a source or destination DS domain) or it can be
   a BA.  Thus, an SLS may apply in the source or destination DS domain
   to a single microflow or group of microflows, as well as to a BA in
   any DS domain.

   Also note that the definition of a "Service Provisioning Policy" is
   unchanged from RFC 2475.  RFC 2475 defines a "Service Provisioning
   Policy as "a policy which defines how traffic conditioners are
   configured on DS boundary nodes and how traffic streams are mapped to
   DS behavior aggregates to achieve a range of services."  According to
   one definition given in RFC 3198 [6], a policy is "...a set of rules
   to administer, manage, and control access to network resources".
   Therefore, the relationship between an SLS and a service provisioning
   policy is that the latter is, in part, the set of rules that express
   the parameters and range of values that may be in the former.

   Further note that this definition is more restrictive than that in
   RFC 3198.

Grossman                     Informational                      [Page 2]
RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

3. Usage of PHB Group

   RFC 2475 defines a Per-hop behavior (PHB) group to be:

      "a set of one or more PHBs that can only be meaningfully specified
      and implemented simultaneously, due to a common constraint
      applying to all PHBs in the set such as a queue servicing or queue
Show full document text