Diffserv Working Group Dan Grossman Internet Draft Motorola, Inc.
Expires: April 2000 draft-ietf-diffserv-new-terms-00.txtOctober, 1999 New Terminology for Diffserv Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at 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 This memo captures Diffserv working group agreements concerning new and improved terminology. It is intended as a living document for use by the Diffserv working group, and especially for use of authors of Diffserv drafts. It is expected that the terminology in this memo will be incorporated into the existing Diffserv RFCs when they are updated. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 1. Introduction As the Diffserv work has evolved, there have been several cases where terminology has needed to be created or the definitions in  and  have needed to be refined. This memo was created to capture and test group agreements on terminology, rather than attempting to revise the base RFCs and recycle them at proposed standard. Diffserv authors are encouraged to use the new terminology whereever appropriate. [Author's note: the following represents in part the Author's 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 Architecture  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 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, 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 Specfication (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 classfier 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. 2. Usage of PHB Group RFC 2475 deinesdefines a 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 management policy. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities). A single PHB is a special case of a PHB group." The first standards track PHB Group is defined in RFC 2497  is entitled, "Assured Forwarding PHB Group",Group". Assured Forwarding (AF) is a type of forwarding behavior with some assigned level of queuing resources and uses the termthree drop precedences. An AF PHB group consistently in discussing the setGroup consists of three PHBs, and uses three DSCPs. RFC 2497 defines twelve DSCPs, corresponding to four independent AF PHBs. However, this usageclasses. The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x (where 'x' is not consistent with RFC 2475.1, 2, or 3 to represent drop precedence). Each AF class is one instance of an AF PHB Group. There has been confusion expressed that RFC 2497 refers to all four AF classes with their three drop precedences as being part of a single PHB Group. However, since each AF class operates entirely independently of the others, (and thus there is no common constraint which applies to BAs having different AF classes. Indeed, packets having differentamong AF classes mustas there is among drop precedences within an AF class) this usage is inconsistent with RFC 2475. The inconsistency exists for historical reasons and will be forwarded independently. Therefore, eachremoved in future revisions of the fourAF classes constitutesspecification. It should now be understood that AF is a separate_type_ of PHB group, and each having three PHBs corresponding to three drop precedences. A new definitionAF class is thus neededan _instance_ of the AF type. Authors of new PHB specifications should be careful to describe a setadhere to the RFC 2475 definition of relatedPHB groups.Group. RFC 2475 does not prohibit new PHB Group Family: a setspecifications from assigning enough DSCPs to represent multiple independent instances of two or more PHB groups which are specified together and have similar relationships amongtheir constituent PHBs, but which lack any common constraint. APHB group family provides a service building block that allowsGroup. However, such a set of related PHB groups toDSCPs must not be specified together (e.g., three classes ofreferred to as a single PHB groups).Group. 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. 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. The DS Field has a six bit Diffserv Codepoint and two "currently unused bits". Several participants in the Diffserv working group haveIt has been pointed out that this leads to inconsistencies.inconsistencies and ambiguities. In particular, the CU bits of the DS Field have not been assigned to Diffserv (and in fact are being used by RFC 2481 Diffserv, and have been assigned an experimental use for an explicit congestion notification). Anotification scheme . In the current text, a DSCP is, depending on context, either an encoding which selects a PHB or a sub- fieldsub-field in the DS field which contains that encoding. [Author's note: there was noThe present text is also inconsistent with the IANA allocation guidelines draft . In that draft, the IPV4 TOS field and the IPV6 traffic class field are superceded by the 6 bit DS field and a 2 bit CU field. The IANA alloctes values in the DE field following the IANA considerations section in RFC 2474. Experimental uses of the CU field are assigned after IESG approval processes. Permanent values in the CU field are allocated following a Standards Action process. The consensus of the DiffServ working group consensus on this subject. Thisis my attempt at an intellectually satisfying solution, albeit onethat will require readers to switch between two sets correctly restates the structure of terminology until RFC 2474 can be updated] Forthe 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 significant bits of eitherthe (former) IPV4 TOS octet or the (former) IPV6 Traffic Class octet. - the Differentiated Services Codepoint (DSCP) is a value which is 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 two least significant bits of the IPV4 TOS octet and the IPV6 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 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 with a common ordering constraint. This 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 class. This would, for example, 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 the same AF class but different drop precedence over different LSPs. The following new terms are defined. PHB Scheduling Class: A PHB group for which a common constraint is that ordering of packets must be preserved Ordered Aggregate (OA): A set of Behavior Aggregates that share an ordering constraint. All of the packets of an OA are members of the same PHB scheduling class. 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. Acknowledgements References  RFC 2474.  Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture for Differentiated Services", RFC 2475, December 1998.  Heinanen and Guerin, "Assured Forwarding PHB Group", RFC 2497  RFC 2481  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 Dan Grossman Motorola, Inc. 20 Cabot Blvd. Mansfield, MA 02048 Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain itor assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.