draft-ietf-diffserv-new-terms-04.txt   draft-ietf-diffserv-new-terms-05.txt 
Diffserv Working Group Dan Grossman Diffserv Working Group Dan Grossman
Internet Draft Motorola, Inc. Internet Draft Motorola, Inc.
Expires: September 2001 Expires: Sepetember 2001
draft-ietf-diffserv-new-terms-04.txt draft-ietf-diffserv-new-terms-05.txt
March, 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/ietf/1id-abstracts.txt 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. It is intended as a living document for and improved terminology, and also provides minor technical
use by the Diffserv working group, and especially for use of authors clarifications. It is intended to update RFC 2474, RFC 2475 and RFC
of Diffserv drafts. It is expected that the terminology in this memo 2597. When RFCs 2474 and 2475 advance on the standards track, and
will be incorporated into the existing Diffserv RFCs when they are RFC 2475 is updated, it is anticipated that the revisions in this
updated. memo will be incorporated, and that this memo will be obsoleted by
the new RFCs.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999, 2001). All Rights
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. This memo was standards track RFCs have needed to be refined. Some minor technical
created to capture and test group agreements on terminology, rather clarifications were also found to be needed. This memo was created
than attempting to revise the base RFCs and recycle them at proposed to capture group agreements, rather than attempting to revise the
standard. Diffserv authors are encouraged to use the new terminology base RFCs and recycle them at proposed standard. It updates in part
whereever appropriate. RFC 2474, RFC 2475 and RFC 2597. RFC 2598 has been updated by RFC
XXXX (draft-ietf-diffserv-rfc2598bis), and clarifications agreed by
the group were incorporated in that update.
2. Terminology Related to Service Level Agreements (SLAs) 2. Terminology Related to Service Level Agreements (SLAs)
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
skipping to change at page 6, line 5 skipping to change at page 6, line 6
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
case. case.
There is a similar issue, which manifests itself with Expedited There was a similar issue, which manifested itself with the first
Forwarding (EF). RFC 2598 states: incarnation of Expedited Forwarding (EF). RFC 2598 states:
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 arises 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. This is statement in RFC 2475 would appear to apply to this case. RFC XXXX
being covered in the (draft) update to RFC2598. (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 It has been pointed out that that RFC 2474 should have stated a bit
more explicitly that the TOS bit usage described in RFC 1349 is more explicitly that the TOS bit usage described in RFC 1349 is
obsoleted. This useage was intended to interact with OSPF extensions obsoleted. This useage was intended to interact with OSPF extensions
in RFC 1247, which were never widely deployed. The processing of the in RFC 1247, which were never widely deployed. The processing of the
TOS bits is described as a requirement in RFC 1812. Although this is TOS bits is described as a requirement in RFC 1812. Although this is
a direct implication of the following sentence in RFC 2474: a direct implication of the following sentence in RFC 2474:
"No attempt is made to maintain backwards compatibility with "No attempt is made to maintain backwards compatibility with
skipping to change at page 6, line 46 skipping to change at page 6, line 47
augmented as follows when RFC 2474 is updated: augmented as follows when RFC 2474 is updated:
"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 RFCs are expected to be updated to The following standards track and informational RFCs are expected to
reflect the agreements captured in this memo. It is intended that be updated to reflect the agreements captured in this memo. It is
these updates occur when each specification progresses to Draft (or intended that these updates occur when each standards track RFC
if some issue arises that forces recycling at Proposed). 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
as RFC 2474. These 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.
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.
RFC 2598: put reference to RFC 2475 in security considerations to In addition, RFCXXXX (draft-ietf-diffserv-rfc2598bis) put a reference to
cover the case of a DS egress node receiving an unrecognized DSCP RFC 2475 in the security considerations section to cover the case of a
which maps to EF in the DS ingress node. (done) DS egress node receiving an unrecognized DSCP which maps to EF in the DS
ingress node.
7. Security Considerations 7. Security Considerations
Security considerations are addressed in RFC 2475. Security considerations are addressed in RFC 2475.
Acknowledgements Acknowledgements This memo captures agreements of the Diffserv working
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
Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John
Schnizlein, Francois Le Faucheur, and Fred Baker [Author's note: who
have I forgotten? Please respond privately]. Mike Ayers provided
valuable editorial comments.
References 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.
skipping to change at page 8, line 4 skipping to change at page 8, line 18
[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
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, 2001). All Rights
Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
itor assist in its implementation may be prepared, copied, published itor assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 15 change blocks. 
31 lines changed or deleted 45 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/