New Terminology and Clarifications for Diffserv
RFC 3260
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.
Abstract
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
RFCs.
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
apply...."
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