draft-ietf-diffserv-new-terms-05.txt   draft-ietf-diffserv-new-terms-06.txt 
Diffserv Working Group Dan Grossman Diffserv Working Group Dan Grossman
Internet Draft Motorola, Inc. Internet Draft Motorola, Inc.
Expires: Sepetember 2001
draft-ietf-diffserv-new-terms-05.txt November, 2001
August, 2001
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
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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 To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). 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, and also provides minor technical and improved terminology, and also provides minor technical
clarifications. It is intended to update RFC 2474, RFC 2475 and RFC clarifications. It is intended to update RFC 2474, RFC 2475 and RFC
2597. When RFCs 2474 and 2475 advance on the standards track, and 2597. When RFCs 2474 and 2597 advance on the standards track, and
RFC 2475 is updated, it is anticipated that the revisions in this RFC 2475 is updated, it is intended that the revisions in this memo
memo will be incorporated, and that this memo will be obsoleted by will be incorporated, and that this memo will be obsoleted by the new
the new RFCs. RFCs.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999, 2001). All Rights Copyright (C) The Internet Society (1999, 2001). All Rights
Reserved. Reserved.
1. Introduction 1. Introduction
As the Diffserv work has evolved, there have been several cases where As the Diffserv work has evolved, there have been several cases where
terminology has needed to be created or the definitions in Diffserv terminology has needed to be created or the definitions in Diffserv
standards track RFCs have needed to be refined. Some minor technical standards track RFCs have needed to be refined. Some minor technical
skipping to change at page 2, line 51 skipping to change at page 2, line 51
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 Note that the definition of "Traffic stream" is unchanged from RFC
2475. A traffic stream can be an individual microflow or a group of 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 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 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 domain to a single microflow or group of microflows, as well as to a
BA in any DS domain. 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 currently used by the POLICY working group, 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 define the parameters and range of values that may be
in the former.
3. Usage of PHB Group 3. Usage of PHB Group
RFC 2475 defines a Per-hop behavior (PHB) group to be: RFC 2475 defines a Per-hop behavior (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."
skipping to change at page 4, line 4 skipping to change at page 4, line 18
Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv
Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the
TOS octet of the IPV4 header, and Traffic Class octet of the IPV6 TOS octet of the IPV4 header, and Traffic Class octet of the IPV6
header, respectively, to the DS field. The DS Field has a six bit header, respectively, to the DS field. The DS Field has a six bit
Diffserv Codepoint and two "currently unused bits". Diffserv Codepoint and two "currently unused bits".
It has been pointed out that this leads to inconsistencies and It has been pointed out that this leads to inconsistencies and
ambiguities. In particular, the "Currently Unused" (CU) bits of the DS ambiguities. In particular, the "Currently Unused" (CU) bits of the DS
Field have not been assigned to Diffserv, and have been assigned an Field have not been assigned to Diffserv, and have been assigned an
experimental use for an explicit congestion notification scheme [4]. In
experimental use for an explicit congestion notification scheme [4]. the current text, a DSCP is, depending on context, either an encoding
In the current text, a DSCP is, depending on context, either an encoding
which selects a PHB or a sub-field in the DS field which contains that which selects a PHB or a sub-field in the DS field which contains that
encoding. encoding.
The present text is also inconsistent with the IANA allocation The present text is also inconsistent with the IANA allocation
guidelines [5]. The IPV4 Type-of-Service (TOS) field and the IPV6 guidelines [5]. The IPV4 Type-of-Service (TOS) field and the IPV6
traffic class field are superceded by the 6 bit DS field and a 2 bit CU traffic class field are superceded by the 6 bit DS field and a 2 bit CU
field. The IANA allocates values in the DS field following the IANA field. The IANA allocates values in the DS field following the IANA
considerations section in RFC 2474. Experimental uses of the CU field considerations section in RFC 2474. Experimental uses of the CU field
are assigned after IESG approval processes. Permanent values in the CU are assigned after IESG approval processes. Permanent values in the CU
field are allocated following a Standards Action process. field are allocated following a Standards Action process.
skipping to change at page 6, line 26 skipping to change at page 6, line 41
The problem arose in the case of misconfiguration or routing The problem arose in the case of misconfiguration or routing
problems. An egress DS-node at the edge of one DS-domain forwards problems. An egress DS-node at the edge of one DS-domain forwards
packets an ingress DS-node at the edge of another DS domain. These packets an ingress DS-node at the edge of another DS domain. These
packets are marked with a DSCP that the egress node understands to packets are marked with a DSCP that the egress node understands to
map to EF, but which the ingress node does not recognize. The map to EF, but which the ingress node does not recognize. The
statement in RFC 2475 would appear to apply to this case. RFC XXXX statement in RFC 2475 would appear to apply to this case. RFC XXXX
(draft-ietf-diffserv-rfc2598bis) clarifies this point. (draft-ietf-diffserv-rfc2598bis) clarifies this point.
7. No Backward Compatibility With RFC 1349 7. No Backward Compatibility With RFC 1349
It has been pointed out that that RFC 2474 should have stated a bit At least one implementor has expressed confusion about the
more explicitly that the TOS bit usage described in RFC 1349 is relationship of the DSField defined in RFC 2474 to the use of the TOS
obsoleted. This useage was intended to interact with OSPF extensions bits described in RFC 1349. This useage was intended to interact
in RFC 1247, which were never widely deployed. The processing of the with OSPF extensions in RFC 1247, which were never widely deployed.
TOS bits is described as a requirement in RFC 1812. Although this is The processing of the TOS bits is described as a requirement in RFC
a direct implication of the following sentence in RFC 2474: 1812. RFC 2474 states:
"No attempt is made to maintain backwards compatibility with "No attempt is made to maintain backwards compatibility with
the "DTR" the "DTR"
or TOS bits of the IPv4 TOS octet, as defined in [RFC791]." or TOS bits of the IPv4 TOS octet, as defined in [RFC791].",
Further clarification is needed. The previous sentence should be In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For
augmented as follows when RFC 2474 is updated: completeness, when RFC 2474 is updated, the sentence should read:
"No attempt is made to maintain backwards compatibility with the "No attempt is made to maintain backwards compatibility with the
"DTR/MBZ" "DTR/MBZ"
or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and
[RFC1349]. This implies that TOS bit processing as described in [RFC1349]. This implies that TOS bit processing as described in
sections 5.2.4.3 and 5.3.2 of [RFC1812] is also obsoleted by this sections 5.2.4.3 and 5.3.2 of [RFC1812] is also obsoleted by this
memo. Also see [RFC2780]." memo. Also see [RFC2780]."
8. Summary of Pending Changes 8. Summary of Pending Changes
The following standards track and informational RFCs are expected to The following standards track and informational RFCs are expected to
 End of changes. 11 change blocks. 
20 lines changed or deleted 31 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/