2.7.2 Differentiated Services (diffserv)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98


Brian Carpenter <brian@hursley.ibm.com>
Kathleen Nichols <knichols@baynetworks.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:diff-serv@baynetworks.com
To Subscribe: majordomo@baynetworks.com
In Body: subscribe diff-serv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

Description of Working Group:

There is a clear need for relatively simple and coarse methods of providing differentiated classes of service for Internet traffic, to support various types of applications, and specific business requirements. The differentiated services approach to providing quality of service in networks employs a small, well- defined set of building blocks from which a variety of services may be built. A small bit-pattern in each packet, in the IPv4 TOS octet or the IPv6 Traffic Class octet, is used to mark a packet to receive a particular forwarding treatment, or per-hop behavior, at each network node. A common understanding about the use and interpretation of this bit-pattern is required for inter-domain use, multi-vendor interoperability, and consistent reasoning about expected service behaviors in a network. Thus, the Working Group will standardize a common layout to be used for both octets, called the 'DS byte'. A standards-track document will be produced that will define the general use of fields within the DS byte (superseding the IPv4 TOS octet definitions of RFC 1349). The Working Group will also assign specific per-hop behaviors to a small number of particular patterns or 'code-points' of the DS byte. The standardized code-points will only apply to per-hop behaviors already in widespread common usage within the global internet, e.g, the forwarding treatment received by best-effort traffic.

In addition to the standards-track specification document, an informational framework document will be produced. The framework document will define the differentiated services architecture and a common language for differentiated services. Example uses and services will be described.

Another goal of the WG is to experiment with other per-hop behaviors that can be used to produce additional services. These will be documented in internet drafts. It will be decided whether these additional code-points and per-hop behaviors should be specified in experimental RFCs or should become standardized. The WG will also investigate the additional components necessary to support differentiated services, including such traffic conditioners as traffic shapers and packet markers that could be used at the boundaries of networks. The WG may also define mechanisms such as LDAP schemata to map user service profiles into differentiated services at the network boundary. Later documents will cover these issues.

The group will analyze related security threats, especially theft of service or denial of service attacks, and suggest counter-measures.

The group will not work on mechanisms for the identification of individual traffic flows within the network, or on signaling mechanisms to support the marking of packets.

Goals and Milestones:

Apr 98


Meet at LA IETF to review strawman spec

Apr 98


Initial discussions and outline for framework doc (FYI)

Apr 98


Revised drafts of spec and framework

Jun 98


Interim meeting to review spec and framework docs

Jul 98


Submit drafts to IESG for consideration as RFCs

Aug 98


Meet at Chicago IETF to discuss boundary mechanisms and traffic conditioners

Oct 98


Publish drafts on boundary mechanisms and traffic conditioners

Dec 98


Meet at IETF to finalize boundary mechanisms and traffic conditioners documents


No Request For Comments

Current Meeting Report

Minutes of the Differentiated Services (diffserv) Working Group

Co-chairs: Brian Carpenter and Kathleen Nichols
Area Director: Scott Bradner

Minutes courtesy of Eric Crawley


I. Review Charter: Brian Carpenter
II. Clarifications and issues on draft-nichols-dsopdef-00.txt: Kathie Nichols
III. Outline of framework doc, collect topics: Steve Blake
IV. Short Statements on topics missed or contested in draft-nichols
V. Allocation of work items

Brian Carpenter set out some rules of the meeting: stick to the agenda and charter, be brief

Brian introduced Scott Bradner for a brief comment about the working group. Scott talked about the straw proposal that was put out and said that the "tag team" that made the draft was put together to jump start the process and get to a reasonable starting point but it was not the final word for the WG. Complaints about the charter should go to Scott.

Brian went over the charter (see full charter at http://www.ietf.org/html.charters/diffserv-charter.html ) - Need for simple and coarse methods of providing differentiated classes of service.
· diffserv approach: small, well-defined set of building blocks to build variety of services
· Small bit pattern used to encode these building blocks (PHBs, per hop behaviors).
· Common understanding about the use and interpretation is required for inter-domain use, interoperability and for consistent reasoning
· WG will assign specific code points to a small number of particular PHBs already in widespread use.

Comment from Paul Ferguson that the existing "bits or patterns" are somewhat a topic for debate. This was noted as something already on the issues list.

Other goals were also listed:

· *Will* analyze security threats
· *Will not* work on mechanisms for identification of individual traffic flows or on signaling mechanisms to support the marking of packets.

Milestones were listed: New drafts in April, Interim meeting in June, Revised drafts to IESG in July, Discuss boundary methods in August, etc. Question about further definition of boundary mechanisms. This is expected to be listed in the topics for the framework.

Kathie Nichols next talked about the issues related to the dsopdef draft.

· Fast overview of the draft

· Issues culled from mailing list
· Preparation for June and August meetings

Quick overview:

What can you build?

· End2End services

· Intradomain services (see slides)

Draft defines "forwarding treatment". Packets can be marked "anywhere," though it is expected this will happen at boundaries. Services are built by applying rules about marking and treatment of packets. e2e and intradomain services to be built from basics with agreements at boundaries Elements of a DiffServ Arch: PHBs, classifiers, markers, and policy Using the same spirit of RFC791 but built out of packet schedulers and queue managers. Traffic conditioners enforce rules of services, generally at network boundaries. Classifiers, policers, markers, and shapers Policy agents: (not part of WG)

· Apply policy within domain and communicate with agents in other domains. Current WG focus: Standardize DS Byte (DiffServ byte, i.e., IPv4 Type of Service byte or IPv6 Traffic Class byte).
· Basic idea (but not bits) is from Clark's "mechanism" now called PHB
· Forwarding treatment a packet gets is a function of its marking
· Marking is an index/codepoint
· Spec'd in terms of input/output behavior
· only coupling between different PHBs is through their effect on output BW

Question about the origin of the "indexing" behavior of the PHB. This seemed to be the consensus of the document authors in order to have any efficient use of the bits. Proposed DS byte layout (see slides and draft)

Issues List:

· Concerning the DE PHB
· Allocating the codepoints
· Rewriting the DS byte
· Backwards compatibility
· In/Out bit field
· Wording for DE reordering
· Wording for In-field reordering
· Host marking wording
· Other byte layouts
· Others?

Question about the number of IN/Out bits (put off until the issue was discussed)

Why pick 0 for DE (default) PHB?

· Can we have "worse than DE"?
· This is far from well-understood or universally desired,
· Consensus is that 0 is fine.

Allocating Codepoints:

· Resolve the need for local codepoints and experimental codepoints
· Two rules:

Lots of discussion on this topic. There is a conflict between reserving "bits" and reserving codepoints. Discussion of what is really meant by "end2end". Note that the In/Out bit is really part of the "PHB Index". More questions about the location and conflict of the bits and how PHBs map to "profiles". It was pointed out that a decision on this issue was in conflict with putting "parameters" in the DS byte and whether any of them were pre-allocated such as the IN/OUT bit. This issue was deferred to the June interim meeting with discussion to take place on the mailing list.

Proposal on rewriting the DS byte:

EXP/LU field rewrite potentially affects EXP/LU allocation mechanism Some comments were that the DS byte has little meaning across boundaries. Move proposed action off list and on the mailing list. More discussion of DS byte being use for encoding a "service" or a "behavior". This issue was deferred to the June interim meeting with discussion to take place on the mailing list.

Backward Compatibility:

· Use RFC 791 precedence encoding?
· Uses of precedence 110 and 111 are common (only for routing traffic)
· Proposed action: Baker, Renwick, Li, Brim, & Kastenholz will make a draft on the reuse of these code points Consensus of the meeting was to go with the proposed action and review the draft later.

In/Out Field:

· One possibility to get rid of it and assimilate it into the PHB. This was the consensus of the meeting.

Wording issues were moved to the mailing list. These will be discussed and consensus determined from the discussion on the list.

Host Marking:

Wording should be improved to use the "be my guest" principle about marking. Meeting consensus was that those with specific suggestions send them to Steve Blake, document editor.

Other Byte Layouts:

· Encode DP (drop preference) and Delay in other encodings Proposed Action: Wait for reports of experience and consensus on standard PHBs. It was pointed out that this is really a different viewpoint than the current framework. Some felt that the allocation of some "experimental" bits allowed other layouts and uses. Lots of emphasis that we are defining behaviors and not services. The consensus was that some of the other models could be accommodated in the PHB model.

Interim Meeting, June 11 and 12, Boston, MA
Main Business: review specs and framework
Start talking about Shapers, Classifiers, and Policers
Other topics are a possibility.

Steve Blake talked about the proposed outline for a framework document


· Overview, Terminology, Motivation, Requirements, Comparisons with other approaches Differentiated Services Architectural Model:


· Service categorization, Provisioning, and Examples Service Control Mechanisms:

· Inter-domain Considerations and e2e services:

· Interoperability with non-DiffServ devices

· Multicast:

· Appendices:

There was little discussion or comment since the list was very complete.

Brian started in on the assignment of work items:

Alternate Approaches and Other Issues:

Walter Weiss:

Communities interested in DiffServ
· Service Provider space
· Enterprise space
· Really the difference between end2end or intradomain. Need to be able to compose e2e services out of DiffServ and not rule it out. Walter then talked briefly about his draft (draft-weiss-cooperative-drop-00.txt). He had tried to combine ideas from previous drafts.

Kilkki Kalevi: Recommends DP + DI (delay indication) instead of in/out + PHB.

· Much of this was decided in the meeting by removing in/out
· Suggests defining PHBs that provide DP + DI

Borge Ohlman: Access Link Receiver Control in Diffserv

· draft-ohlman-reciever-ctrl-diff-00.txt
· Types of receiver control
· When is access link receiver control needed? (low BW links, wireless, etc.)

Yoram Bernet: A Framework for e2e QoS combining RSVP/IntServ and Differentiate Services draft-ietf-bernet-intdiff-00.txt

· Requirements of a network that provides e2e QoS
· Present a framework that uses intserv as a customer of diffserv to meet these requirements
· Identify dependencies of intserv
· Needed for QoS apps. IP telephone, SAP R3, Games, Video delivery, etc.
· Expect hosts to be RSVP-ready in the next few years.
· E2E QoS can be realized for these apps by running IntServ at the Edge and DiffServ in the middle.


None Received

Attendees List

go to list