draft-ietf-diffserv-new-terms-00.txt   draft-ietf-diffserv-new-terms-01.txt 
Diffserv Working Group Dan Grossman Diffserv Working Group Dan Grossman
Internet Draft Motorola, Inc. Internet Draft Motorola, Inc.
Expires: April 2000 draft-ietf-diffserv-new-terms-00.txt
October, 1999 October, 1999
New Terminology for Diffserv New Terminology for Diffserv
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of RFC2026. Internet-Drafts are working all provisions of section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
skipping to change at page 1, line 28 skipping to change at page 1, line 28
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract Abstract
This memo captures Diffserv working group agreements concerning new This memo captures Diffserv working group agreements concerning new
and improved terminology. It is intended as a living document for and improved terminology. It is intended as a living document for use
use by the Diffserv working group, and especially for use of authors by the Diffserv working group, and especially for use of authors of
of Diffserv drafts. It is expected that the terminology in this memo Diffserv drafts. It is expected that the terminology in this memo
will be incorporated into the existing Diffserv RFCs when they are will be incorporated into the existing Diffserv RFCs when they are
updated. updated.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
1. Introduction As the Diffserv work has evolved, there have been 1. Introduction
As the Diffserv work has evolved, there have been
several cases where terminology has needed to be created or the several cases where terminology has needed to be created or the
definitions in [1] and [2] have needed to be refined. This memo was definitions in [1] and [2] have needed to be refined. This memo was
created to capture and test group agreements on terminology, rather created to capture and test group agreements on terminology, rather
than attempting to revise the base RFCs and recycle them at proposed than attempting to revise the base RFCs and recycle them at proposed
standard. Diffserv authors are encouraged to use the new terminology standard. Diffserv authors are encouraged to use the new terminology
whereever appropriate. whereever appropriate.
[Author's note: the following represents in part the Author's 2. Terminology related to Service Level Agreements (SLAs)
understanding of the agreements. However, in some cases, the Author
found it necessary to elaborate or expand. The Author has also
polled the Diffserv chairs and incorporated their recollection into
this memo. Every attempt will be made to refine this memo based on
comments from the group. No claim is made that the 00 version of
this memo represents a group consensus.)
2. Terminology related to Service Level Agreements (SLAs) The Diffserv The Diffserv Architecture [2] uses the term "Service Level Agreement"
Architecture [2] uses the term "Service Level Agreement" (SLA) to (SLA) to describe the "service contract... that specifies the
describe the "service contract... that specifies the forwarding forwarding service a customer should receive". The SLA may include
service a customer should receive". The SLA may include traffic traffic conditioning rules which (at least in part) constitute a
conditioning rules which (at least in part) constitute a Traffic Traffic Conditioning Agreement (TCA). A TCA is "an agreement
Conditioning Agreement (TCA). A TCA is "an agreement specifying specifying classifier rules and any corresponding traffic profiles
classifier rules and any corresponding traffic profiles and metering, and metering, marking, discarding and/or shaping rules which are to
marking, discarding and/or shaping rules which are to apply...." apply...."
As work progressed in Diffserv, it came to be believed that the As work progressed in Diffserv, it came to be believed that the
notion of an "agreement" implied considerations that were of a notion of an "agreement" implied considerations that were of a
pricing, contractual or other business nature, as well as those that pricing, contractual or other business nature, as well as those that
were strictly technical. There also could be other technical were strictly technical. There also could be other technical
considerations in such an agreement (e.g., service availability) considerations in such an agreement (e.g., service availability)
which are not addressed by Diffserv. It was therefore agreed that which are not addressed by Diffserv. It was therefore agreed that
the notions of SLAs and TCAs would be taken to represent the broader the notions of SLAs and TCAs would be taken to represent the broader
context, and that new terminology would be used to describe those context, and that new terminology would be used to describe those
elements of service and traffic conditioning that are addressed by elements of service and traffic conditioning that are addressed by
skipping to change at page 2, line 48 skipping to change at page 2, line 42
- A Traffic Conditioning Specification (TCS) is a set of parameters - A Traffic Conditioning Specification (TCS) is a set of parameters
and their values which together specify a set of classfier rules and their values which together specify a set of classfier rules
and a traffic profile. A TCS is an integral element of an SLS. 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. 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 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, (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 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. microflow or group of microflows, as well as to a BA in any DS domain.
2. PHB Group RFC 2475 deines a PHB group to be: 2. Usage of PHB Group
RFC 2475 defines a PHB group to be:
"a set of one or more PHBs that can only be meaningfully specified "a set of one or more PHBs that can only be meaningfully specified
and implemented simultaneously, due to a common constraint applying and implemented simultaneously, due to a common constraint applying
to all PHBs in the set such as a queue servicing or queue to all PHBs in the set such as a queue servicing or queue
management policy. A PHB group provides a service building block management policy. A PHB group provides a service building block
that allows a set of related forwarding behaviors to be specified that allows a set of related forwarding behaviors to be specified
together (e.g., four dropping priorities). A single PHB is a together (e.g., four dropping priorities). A single PHB is a
special case of a PHB group." special case of a PHB group."
RFC 2497 [3] is entitled "Assured Forwarding PHB Group", and uses the The first standards track PHB Group is defined in RFC 2497 [3], "Assured
term AF PHB group consistently in discussing the set of twelve AF PHBs. Forwarding PHB Group". Assured Forwarding (AF) is a type of forwarding
However, this usage is not consistent with RFC 2475. There is no common behavior with some assigned level of queuing resources and three drop
constraint which applies to BAs having different AF classes. Indeed, precedences. An AF PHB Group consists of three PHBs, and uses three
packets having different AF classes must be forwarded independently. DSCPs.
Therefore, each of the four AF classes constitutes a separate PHB
group, each having three PHBs corresponding to three drop precedences.
A new definition is thus needed to describe a set of related PHB groups. RFC 2497 defines twelve DSCPs, corresponding to four independent AF
classes. The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x
(where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class
is one instance of an AF PHB Group.
PHB Group Family: a set of two or more PHB groups which are There has been confusion expressed that RFC 2497 refers to all four AF
specified together and have similar relationships among their classes with their three drop precedences as being part of a single PHB
constituent PHBs, but which lack any common constraint. A PHB Group. However, since each AF class operates entirely independently of
group family provides a service building block that allows a set of the others, (and thus there is no common constraint among AF classes as
related PHB groups to be specified together (e.g., three classes of there is among drop precedences within an AF class) this usage is
PHB groups). inconsistent with RFC 2475. The inconsistency exists for historical
reasons and will be removed in future revisions of the AF specification.
It should now be understood that AF is a _type_ of PHB group, and each
AF class is an _instance_ of the AF type.
Authors of new PHB specifications should be careful to adhere to the RFC
2475 definition of PHB Group. RFC 2475 does not prohibit new PHB
specifications from assigning enough DSCPs to represent multiple
independent instances of their PHB Group. However, such a set of DSCPs
must not be referred to as a single PHB Group.
3. Definition of the DS Field Diffserv uses six bits of the IPV4 or IPV6 3. Definition of the DS Field Diffserv uses six bits of the IPV4 or IPV6
header to convey the Diffserv Codepoint (DSCP), which selects a PHB. header to convey the Diffserv Codepoint (DSCP), which selects a PHB.
RFC 2474 attempts to rename the TOS octet of the IPV4 header, and RFC 2474 attempts to rename the TOS octet of the IPV4 header, and
Traffic Class octet of the IPV6 header, respectively, to the DS field. Traffic Class octet of the IPV6 header, respectively, to the DS field.
The DS Field has a six bit Diffserv Codepoint and two "currently unused The DS Field has a six bit Diffserv Codepoint and two "currently unused
bits". bits".
Several participants in the Diffserv working group have pointed out that It has been pointed out that this leads to inconsistencies and
this leads to inconsistencies. In particular, the CU bits of the DS ambiguities. In particular, the CU bits of the DS Field have not been
Field have not been assigned to Diffserv (and in fact are being used by assigned to Diffserv, and have been assigned an experimental use for an
RFC 2481 [] for explicit congestion notification). A DSCP is, explicit congestion notification scheme [4]. In the current text, a
depending on context, either an encoding which selects a PHB or a sub- DSCP is, depending on context, either an encoding which selects a PHB or
field in the DS field which contains that encoding. a sub-field in the DS field which contains that encoding.
[Author's note: there was no working group consensus on this subject. The present text is also inconsistent with the IANA allocation
This is my attempt at an intellectually satisfying solution, albeit one guidelines draft [5]. In that draft, the IPV4 TOS field and the IPV6
that will require readers to switch between two sets of terminology traffic class field are superceded by the 6 bit DS field and a 2 bit CU
until RFC 2474 can be updated] field. The IANA alloctes values in the DE field following the IANA
considerations section in RFC 2474. Experimental uses of the CU field
For use in future drafts, including the next update to RFC 2474, the are assigned after IESG approval processes. Permanent values in the CU
following definitions should apply: field are allocated following a Standards Action process.
The consensus of the DiffServ working group is that [5] correctly
restates the structure of the former TOS and traffic class fields.
Therefore, for use in future drafts, including the next update to RFC
2474, the following definitions should apply:
- the Differentiated Services Field (DSField) is the six most - the Differentiated Services Field (DSField) is the six most
significant bits of either the IPV4 TOS octet or the IPV6 Traffic significant bits of the (former) IPV4 TOS octet or the (former)
Class octet. IPV6 Traffic Class octet.
- the Differentiated Services Codepoint (DSCP) is a value which is - the Differentiated Services Codepoint (DSCP) is a value which is
encoded in the DS field, and which each DS Node MUST use to select encoded in the DS field, and which each DS Node MUST use to select
the PHB which is to be experienced by each packet it forwards. the PHB which is to be experienced by each packet it forwards.
The two least significant bits of the IPV4 TOS octet and the IPV6 The two least significant bits of the IPV4 TOS octet and the IPV6
Traffic Class octet are not presently used by Diffserv. Traffic Class octet are not presently used by Diffserv.
The update should also reference the IANA Allocation Guidelines,
assuming that they are published as an RFC.
4. Ordered aggregates and PHB scheduling classes 4. Ordered aggregates and PHB scheduling classes
Work on Diffserv support by MPLS LSRs led to the realization that a Work on Diffserv support by MPLS LSRs led to the realization that a
concept was needed in Diffserv to capture the notion of a set of BAs concept was needed in Diffserv to capture the notion of a set of BAs
with a common ordering constraint. This presently applies to AF with a common ordering constraint. This presently applies to AF
behavior aggregates, since a DS node may not reorder packets of the same behavior aggregates, since a DS node may not reorder packets of the same
microflow if they belong to the same AF class. This would, for example, microflow if they belong to the same AF class. This would, for example,
prevent an MPLS LSR which was also a DS node from discriminating between prevent an MPLS LSR which was also a DS node from discriminating between
packets of an AF BA based on drop precedence and forwarding packets of packets of an AF BA based on drop precedence and forwarding packets of
the same AF class but different drop precedence over different LSPs. the same AF class but different drop precedence over different LSPs.
The following new terms are defined. The following new terms are defined.
PHB Scheduling Class: A PHB group for which a common constraint is PHB Scheduling Class: A PHB group for which a common constraint is
that ordering of packets must be preserved that ordering of packets must be preserved
Ordered Aggregate (OA): A set of Behavior Aggregates that share an Ordered Aggregate (OA): A set of Behavior Aggregates that share an
ordering constraint. All of the packets of an OA are members of the ordering constraint. All of the packets of an OA are members of the
same PHB scheduling class. same PHB scheduling class.
5. Security Considerations Security considerations are addressed in RFC 5. Summary of pending changes The following standards track RFCs are
expected to be updated to reflect the agreements captured in this memo.
It is intended that these updates occur when each specification
progresses to Draft (or if some issue arises that forces recycling at
Proposed).
RFC 2474: revise definition of DS field
RFC 2475: revise definition of DS field. Add SLS and TCS
definitions. Update body of document to use SLS and TCS
appropriately. Add definitions of PHB scheduling class and ordered
aggregate.
RFC 2497: revise to reflect understanding that AF classes are
instances of the AF PHB group, and are not collectively a PHB
group.
6. Security Considerations Security considerations are addressed in RFC
2475. 2475.
Acknowledgements Acknowledgements
References References
[1] RFC 2474. [1] RFC 2474.
[2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture [2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture
for Differentiated Services", RFC 2475, December 1998. for Differentiated Services", RFC 2475, December 1998.
[3] Heinanen and Guerin, "Assured Forwarding PHB Group", RFC 2497 [3] Heinanen and Guerin, "Assured Forwarding PHB Group", RFC 2497
[4] RFC 2481
[5] Bradner and Paxon, IANA Allocation Guidelines for Values in the
Internet Protocol and Related Headers, draft-bradner-iana-
allocation-02.txt, October 1999, work in progress
Author's Address Author's Address
Dan Grossman Dan Grossman
Motorola, Inc. Motorola, Inc.
20 Cabot Blvd. 20 Cabot Blvd.
Mansfield, MA 02048 Mansfield, MA 02048
Email: dan@dma.isg.mot.com Email: dan@dma.isg.mot.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
 End of changes. 18 change blocks. 
56 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/