draft-ietf-diffserv-new-terms-06.txt   draft-ietf-diffserv-new-terms-07.txt 
Diffserv Working Group Dan Grossman Diffserv Working Group Dan Grossman
Internet Draft Motorola, Inc. Internet Draft Motorola, Inc.
Expires: June, 2002
November, 2001 draft-ietf-diffserv-new-terms-07.txt
December, 2001
New Terminology for Diffserv New Terminology and Clarifications 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
``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, 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 2597 advance on the standards track, and 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 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 will be incorporated, and that this memo will be obsoleted by the new
RFCs. RFCs.
skipping to change at page 2, line 25 skipping to change at line 68
The Diffserv Architecture [2] uses the term "Service Level Agreement" The Diffserv Architecture [2] uses the term "Service Level Agreement"
(SLA) to describe the "service contract... that specifies the (SLA) to describe the "service contract... that specifies the
forwarding service a customer should receive". The SLA may include forwarding service a customer should receive". The SLA may include
traffic conditioning rules which (at least in part) constitute a traffic conditioning rules which (at least in part) constitute a
Traffic Conditioning Agreement (TCA). A TCA is "an agreement Traffic Conditioning Agreement (TCA). A TCA is "an agreement
specifying classifier rules and any corresponding traffic profiles specifying classifier rules and any corresponding traffic profiles
and metering, marking, discarding and/or shaping rules which are to and metering, 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 (as well as in the Policy WG [6]), it
notion of an "agreement" implied considerations that were of a came to be believed that the notion of an "agreement" implied
pricing, contractual or other business nature, as well as those that considerations that were of a pricing, contractual or other business
were strictly technical. There also could be other technical nature, as well as those that were strictly technical. There also
considerations in such an agreement (e.g., service availability) could be other technical considerations in such an agreement (e.g.,
which are not addressed by Diffserv. It was therefore agreed that service availability) which are not addressed by Diffserv. It was
the notions of SLAs and TCAs would be taken to represent the broader therefore agreed that the notions of SLAs and TCAs would be taken to
context, and that new terminology would be used to describe those represent the broader context, and that new terminology would be used
elements of service and traffic conditioning that are addressed by to describe those elements of service and traffic conditioning that
Diffserv. are addressed by Diffserv.
- A Service Level Specification (SLS) is a set of parameters and - A Service Level Specification (SLS) is a set of parameters and
their values which together define the service offered to a traffic their values which together define the service offered to a traffic
stream by a DS domain. stream by a DS domain.
- 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 Note that the definition of "Traffic stream" is unchanged from RFC
skipping to change at page 3, line 8 skipping to change at line 99
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 Also note that the definition of a "Service Provisioning Policy" is
unchanged from RFC 2475. RFC 2475 defines a "Service Provisioning unchanged from RFC 2475. RFC 2475 defines a "Service Provisioning
Policy as "a policy which defines how traffic conditioners are Policy as "a policy which defines how traffic conditioners are
configured on DS boundary nodes and how traffic streams are mapped to configured on DS boundary nodes and how traffic streams are mapped to
DS behavior aggregates to achieve a range of services." According to DS behavior aggregates to achieve a range of services." According to
one definition currently used by the POLICY working group, a policy one definition given in RFC 3198 [6], a policy is "...a set of rules
is "...a set of rules to administer, manage, and control access to to administer, manage, and control access to network resources".
network resources". Therefore, the relationship between an SLS and a Therefore, the relationship between an SLS and a service provisioning
service provisioning policy is that the latter is, in part, the set policy is that the latter is, in part, the set of rules that express
of rules that define the parameters and range of values that may be the parameters and range of values that may be in the former.
in the former.
Further note that this definition is more restrictive than that in
RFC 3198.
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
skipping to change at page 4, line 18 skipping to change at line 158
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 BCP0037, IANA Allocation
guidelines [5]. The IPV4 Type-of-Service (TOS) field and the IPV6 Guidelines for Values in the Internet Protocol and Related Headers [5].
traffic class field are superceded by the 6 bit DS field and a 2 bit CU The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class field
field. The IANA allocates values in the DS field following the IANA are superceded by the 6 bit DS field and a 2 bit CU field. The IANA
considerations section in RFC 2474. Experimental uses of the CU field allocates values in the DS field following the IANA considerations
are assigned after IESG approval processes. Permanent values in the CU section in RFC 2474. Experimental uses of the CU field are assigned
field are allocated following a Standards Action process. after IESG approval processes. Permanent values in the CU field are
allocated following a Standards Action process.
The consensus of the DiffServ working group is that [5] correctly The consensus of the DiffServ working group is that [5] correctly
restates the structure of the former TOS and traffic class fields. restates the structure of the former TOS and traffic class fields.
Therefore, for use in future drafts, including the next update to RFC Therefore, for use in future drafts, including the next update to RFC
2474, the following definitions should apply: 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 the (former) IPV4 TOS octet or the (former) significant bits of the (former) IPV4 TOS octet or the (former)
IPV6 Traffic 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, The update should also reference BCP0037.
assuming that they are published as an RFC.
5. Ordered Aggregates and PHB Scheduling Classes 5. Ordered Aggregates and PHB Scheduling Classes
Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to
the realization that a concept was needed in Diffserv to capture the the realization that a concept was needed in Diffserv to capture the
notion of a set of BAs with a common ordering constraint. This notion of a set of BAs with a common ordering constraint. This
presently applies to AF behavior aggregates, since a DS node may not presently applies to AF behavior aggregates, since a DS node may not
reorder packets of the same microflow if they belong to the same AF reorder packets of the same microflow if they belong to the same AF
class. This would, for example, prevent an MPLS LSR which was also a class. This would, for example, prevent an MPLS LSR which was also a
DS node from discriminating between packets of an AF Behavior DS node from discriminating between packets of an AF Behavior
skipping to change at page 6, line 8 skipping to change at line 243
AFTER the traffic conditioning required by RFC 2475 (in which case, AFTER the traffic conditioning required by RFC 2475 (in which case,
an unrecognized DSCP would occur only in the case of an unrecognized DSCP would occur only in the case of
misconfiguration). If a packet arrives with a DSCP that hadn't been misconfiguration). If a packet arrives with a DSCP that hadn't been
explicitly mapped to a particular PHB, it should be treated the same explicitly mapped to a particular PHB, it should be treated the same
way as a packet marked for Default. The alternatives were to assign way as a packet marked for Default. The alternatives were to assign
it another PHB, which could result in misallocation of provisioned it another PHB, which could result in misallocation of provisioned
resources, or to drop it. Those are the only alternatives within the resources, or to drop it. Those are the only alternatives within the
framework of 2474. Neither alternative was considered desirable. framework of 2474. Neither alternative was considered desirable.
There has been discussion of a PHB which receives worse service than There has been discussion of a PHB which receives worse service than
the default; this might be a better alternative. Hence the the default; this might be a better alternative. Hence the
imperitive was"SHOULD" rather than "SHALL". imperative was "SHOULD" rather than "SHALL".
The intent in RFC 2475 clearly concerns DS-ingress nodes, or to be The intent in RFC 2475 clearly concerns DS-ingress nodes, or to be
more precise, the ingress traffic conditioning function. This is more precise, the ingress traffic conditioning function. This is
another context where the "SHOULD" in RFC 2474 gives the flexibility another context where the "SHOULD" in RFC 2474 gives the flexibility
to do what the group intended. Such tortured readings are not to do what the group intended. Such tortured readings are not
desirable. desirable.
Therefore, the statement in RFC 2474 will be clarified to indicate Therefore, the statement in RFC 2474 will be clarified to indicate
that it is not intended to apply at the ingress traffic conditioning that it is not intended to apply at the ingress traffic conditioning
function at a DS-ingress node, and cross reference RFC 2475 for that function at a DS-ingress node, and cross reference RFC 2475 for that
skipping to change at page 6, line 33 skipping to change at line 268
To protect itself against denial of service attacks, the edge of a To protect itself against denial of service attacks, the edge of a
DS domain MUST strictly police all EF marked packets to a rate DS domain MUST strictly police all EF marked packets to a rate
negotiated with the adjacent upstream domain. (This rate must be negotiated with the adjacent upstream domain. (This rate must be
<= the EF PHB configured rate.) Packets in excess of the <= the EF PHB configured rate.) Packets in excess of the
negotiated rate MUST be dropped. If two adjacent domains have not negotiated rate MUST be dropped. If two adjacent domains have not
negotiated an EF rate, the downstream domain MUST use 0 as the rate negotiated an EF rate, the downstream domain MUST use 0 as the rate
(i.e., drop all EF marked packets). (i.e., drop all EF marked packets).
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 to an ingress DS-node at the edge of another DS domain.
packets are marked with a DSCP that the egress node understands to These packets are marked with a DSCP that the egress node understands
map to EF, but which the ingress node does not recognize. The to 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. [7] (draft-ietf-diffserv-rfc2598bis) clarifies this point.
7. No Backward Compatibility With RFC 1349 7. No Backward Compatibility With RFC 1349
At least one implementor has expressed confusion about the At least one implementor has expressed confusion about the
relationship of the DSField defined in RFC 2474 to the use of the TOS relationship of the DSField, as defined in RFC 2474, to the use of
bits described in RFC 1349. This useage was intended to interact the TOS bits, as described in RFC 1349. The RFC 1349 useage was
with OSPF extensions in RFC 1247, which were never widely deployed. intended to interact with OSPF extensions in RFC 1247, which were
The processing of the TOS bits is described as a requirement in RFC never widely deployed. The processing of the TOS bits is described
1812. RFC 2474 states: as a requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123 [10].
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].",
In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For
completeness, when RFC 2474 is updated, the sentence should read: 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
or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and [RFC791] and [RFC1349]. This implies that TOS bit processing as
[RFC1349]. This implies that TOS bit processing as described in described in [RFC1812], [RFC1122] and [RFC1123] is also obsoleted
sections 5.2.4.3 and 5.3.2 of [RFC1812] is also obsoleted by this by this memo. Also see [RFC2780]."
memo. Also see [RFC2780]."
8. Summary of Pending Changes 8. IANA Considerations
IANA has requested clarification of a point in RFC 2474, concerning
registration of experimental/local use DSCPs. When RFC 2474 is
revised, the following should be added to Section 6:
IANA is requested to maintain a registry of RECOMMENDED DSCP
values assigned by standards action. EXP/LU values are not to be
registered.
9. Summary of Pending Changes
The following standards track and informational RFCs are expected to The following standards track and informational RFCs are expected to
be updated to reflect the agreements captured in this memo. It is be updated to reflect the agreements captured in this memo. It is
intended that these updates occur when each standards track RFC intended that these updates occur when each standards track RFC
progresses to Draft (or if some issue arises that forces recycling at progresses to Draft (or if some issue arises that forces recycling at
Proposed). RFC 2475 is expected to be updated at about the same time Proposed). RFC 2475 is expected to be updated at about the same time
as RFC 2474. These updates will also obsolete this memo. as RFC 2474. Those updates will also obsolete this memo.
RFC 2474: revise definition of DS field. Clarify that the RFC 2474: revise definition of DS field. Clarify that the
suggested default forwarding in the event of an unrecognized DSCP suggested default forwarding in the event of an unrecognized DSCP
is not intended to apply to ingress conditioning in DS-ingress is not intended to apply to ingress conditioning in DS-ingress
nodes. Clarify effects on RFC1349 and RFC1812. nodes. Clarify effects on RFC1349 and RFC1812. Clarify that only
RECOMMENDED DSCPs assigned by standards action are to be registered
by IANA.
RFC 2475: revise definition of DS field. Add SLS and TCS RFC 2475: revise definition of DS field. Add SLS and TCS
definitions. Update body of document to use SLS and TCS definitions. Update body of document to use SLS and TCS
appropriately. Add definitions of PHB scheduling class and ordered appropriately. Add definitions of PHB scheduling class and ordered
aggregate. aggregate.
RFC 2497: revise to reflect understanding that AF classes are RFC 2497: revise to reflect understanding that AF classes are
instances of the AF PHB group, and are not collectively a PHB instances of the AF PHB group, and are not collectively a PHB
group. group.
In addition, RFCXXXX (draft-ietf-diffserv-rfc2598bis) put a reference to In addition, RFCXXXX [7] (draft-ietf-diffserv-rfc2598bis) put a
RFC 2475 in the security considerations section to cover the case of a reference to RFC 2475 in the security considerations section to cover
DS egress node receiving an unrecognized DSCP which maps to EF in the DS the case of a DS egress node receiving an unrecognized DSCP which maps
ingress node. to EF in the DS ingress node.
7. Security Considerations 10. Security Considerations
Security considerations are addressed in RFC 2475. Security considerations are addressed in RFC 2475.
Acknowledgements This memo captures agreements of the Diffserv working Acknowledgements
group. Many individuals contributed to the discussions on the Diffserv
list and in the meetings. The Diffserv chairs were Brian Carpenter and
Kathie Nichols. Among many who participated actively in these
discussions were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott This memo captures agreements of the Diffserv working group. Many
Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John individuals contributed to the discussions on the Diffserv list and in
Schnizlein, Francois Le Faucheur, and Fred Baker [Author's note: who the meetings. The Diffserv chairs were Brian Carpenter and Kathie
have I forgotten? Please respond privately]. Mike Ayers provided Nichols. Among many who participated actively in these discussions
valuable editorial comments. were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam
Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein,
Francois Le Faucheur, and Fred Baker. Mike Ayers, Mike Heard and Andrea
Westerinen provided valuable editorial comments.
References Normative References
[1] Nichols, Blake, Baker, Black, "Defintion of the Differentiated [1] Nichols, Blake, Baker, Black, "Defintion of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers" RFC Services Field (DS Field) in the IPv4 and IPv6 Headers" RFC
2474, December 1998. 2474, December 1998.
[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, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB [3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB
Group", RFC 2597 Group", RFC 2597
[4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion [4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion
Notification (ECN)" to IP, RFC 2481, January 1999 Notification (ECN)" to IP, RFC 2481, January 1999
[5] Bradner and Paxon, "IANA Allocation Guidelines for Values in the [5] Bradner and Paxon, "IANA Allocation Guidelines for Values in the
Internet Protocol and Related Headers", BCP0037/RFC2780, March
2000
[6] Westerinen et al, "Terminology for Policy Based Management", RFC
3198
[7] Davie et al, "An Expedited Forwarding PHB", RFC XXXX (ex-draft-
ietf-rfc2598bis-02.txt)
[8] Baker, "Requirements for IP Version 4 Routers", RFC 1812
[9] Braden, "Requirements for Internet Hosts -- Communications
Layers", RFC1122/STD003
[10] Braden, "Requirements for Internet Hosts -- Application and
Support", RFC1123/STD003
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
 End of changes. 24 change blocks. 
69 lines changed or deleted 94 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/