2.7.2 Differentiated Services (diffserv)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 14-Feb-00


Brian Carpenter <brian@icair.org>
Kathleen Nichols <kmn@cisco.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:diffserv@ietf.org
To Subscribe: diffserv-request@ietf.org
In Body: subscribe your_email_address
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 aggregate behaviors 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 aggregate behaviors in a network. Thus, the Working Group has standardized a common layout for a six-bit field of both octets, called the 'DS field'. RFC 2474 and RFC 2475 define the architecture, and the general use of bits within the DS field (superseding the IPv4 TOS octet definitions of RFC 1349).

The Working Group has standardized a small number of specific per-hop behaviors (PHBs), and recommended a particular bit pattern or 'code-point' of the DS field for each one, in RFC 2474, RFC 2597, and RFC 2598. No more PHBs will be standardized until all the current milestones of the WG have been satisfied and the existing standard PHBs have been promoted at least to Draft Standard status.

The WG has investigated 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. There are many examples of these in the technical literature.

The WG will define a general conceptual model for boundary devices, including traffic conditioning parameters, and configuration and monitoring data. It is expected that a subset of this will apply to all diffserv nodes. The group will also define a MIB and a PIB for diffserv nodes, and an encoding to identify PHBs in protocol messages. It will document issues involving diffserv through tunnels.

The WG will develop a format for precisely describing various Behavior Aggregates (BAs), which were initially defined in RFC 2474 and 2475. A BA is a collection of packets with the same codepoint, thus receiving the same PHB, from edge to edge of a single diffserv network or domain. Associated with each BA are measurable, quantifiable characteristics which can be used to describe what happens to packets of that BA as they cross the network, thus providing an external description of the edge-to-edge quality of service that can be expected by packets of that BA within that network. A BA is formed at the edge of a network by selecting certain packets through use of classifiers and by imposing rules on those packets via traffic conditioners. The description of a BA contains the specific edge rules and PHB type(s) and configurations that should be used in order to achieve specified externally visible characteristics.

In addition to defining a format for BA descriptions, specific descriptions of BAs that can be constructed using the standard PHBs will be developed and reviewed by a design team prior to informational or standards track publication.

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

The group will not work on:

o mechanisms for the identification of individual traffic flows

o new signalling mechanisms to support the marking of packets

o end to end service definitions

o service level agreements

Goals and Milestones:

Feb 00


Publish draft of format for BA descriptions

Feb 00


Finalize model and MIB drafts, submit to IESG

Feb 00


Solicit BA descriptions

Mar 00


Finalize PIB draft, submit to IESG

Mar 00


Finalize BA format draft, submit to IESG

Mar 00


Meet at Adelaide IETF to review tunnels draft, discuss initial BA descriptions

Apr 00


Finalize tunnels draft, submit to IESG

Aug 00


Meet at Pittsburgh IETF to finalize initial BA descriptions, submit to IESG

Dec 00


Meet at San Diego IETF to close any open issues, make WG dormant


Request For Comments:







Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers



An Architecture for Differentiated Services



An Expedited Forwarding PHB



Assured Forwarding PHB Group

Current Meeting Report

Meeting minutes for the DiffServ WG meetings in Adelaide, AU

Co-chairs: Brian Carpenter and Kathie Nichols
Reporter: Walter Weiss

Brian Carpenter (for David Black) presented a draft for Tunnels with DiffServ.

Changes from previous draft. This version is shorter. It also recommended that tunnels be able to require that exiting traffic undergo diffserv traffic conditioning. There was also significant cleanup of the text. The tunnel egress node has to decide whether to use the inner or outer codepoint. There was an earlier proposal to use DSCP 0 as an indicator of whether to use the inner or outer codepoint value. The conclusion was that this was the wrong approach and that this choice should be determined through configuration of the egress node.

Additional issue: Suitably configured/provisioned VPN tunnel makes ingress and egress nodes "virtually contiguous". Currently this concept is described using the term "same diffserv domain" but this may not be the right phrase. This should not require an RFC update because RFC 2475 requires that the ingress and egress be in the same domain.

An additional question was whether to add a list of tunnel types. Tunnels are discussed in numerous RFCs including IPSEC and NGTRANS. Should references to these various RFCs be included in David's draft? This will take a while and involve other WGs.

Current text does not update EF RFC to eliminate EF requirement in outer header, should it?
John Wroclawski pointed out that this was not unique to EF.

This will be input to eventual revision of RFC 2475.

Brian asked whether this draft should be a standards track or informational. Juha suggested that this work should be considered in a larger context (MPLS). John W. argued that if the draft is informational, the SHOULDs and REQUIREDs need to be removed. Fred suggested that the choice of egress header determination is sufficient as a sentence in a future rev of the header document. Joel thought that this clarification is deserving of a RFC because there was confusion on the topic. Someone mentioned that the MPLS folks are referring to this document. Juha thought that the document should be generalized beyond specifically specifying IP. He would prefer to see a draft describing the mappings of DSCPs in generic tunnels. General consensus was that this document could be moved on an informational RFC track with appropriate adjustments and support from the TSV area directors.

Andrew Smith discussed the alignment of the conceptual model with the MIB and the PIB. Some issues relate to terminology (discarder vs. dropper). There are also some structural issues that are being worked. Andrew is suggesting that many of the inconsistent concepts need to be moved from the MIB to the model.

There are a number of open issues:

1. There is a difference in interpretation of the token bucket behavior between the model and the MIB. Kathie indicated that the problem was that one description allows a packet to be sent when there are some tokens but not enough for the full packet size while the other description only allows a packet to be sent when there are enough packets for the full packet. Fred implemented the partial token approach in the MIB to cover the case where the bucket size was smaller than the packet size. Fred also pointed out that his description was of a meter (ingress) while Kathie was talking about a shaper (egress). Kathie and John W. wanted to define the conservative definition (requiring a token value greater than the packet size). Kathie indicated that she wanted the model (as opposed to the MIB) to be more conservative. There was agreement to continue this on the mailing list.

2. Should a classifier be part of a TCB? Model assumes yes while the MIB assumes no. Andrew will make the model align with the MIB.

3. Should MPLS be discussed in either document? General discussion suggested that less focus should be given to MPLS.

4. Should the model include discussion of non-DSCP markers? Loosen wording in the model document to allow other markers (802.1, or labels). Because the MIB is specific to DiffServ, the MIB document should not be loosened.

5. The meter in [SRTCM] cannot be precisely modeled using two two-parameter token buckets because its two buckets do not accumulate credits independently. Do we need to show how the [TRTCM] meter should be implemented? There was no time to discuss this.

6. Are the current examples for queues, scheduling and buffer management sufficient? Kathie stated that as these are still areas of research and that we ought to be less precise about specifying particular algorithms.

7. Is the description of a shaper sufficient? Andrew would like additional comments on section 7.2. Juha suggested that there are some boxes that can shape both on the ingress and the egress. A number of people agreed and Andrew said he would clarify the text.

8. Does the concept of a Queue Set belong in the model (and the MIB). Dan Grossman would prefer to see the Queue Set concept removed. Andrew believes that Queue Sets allow information to be shared between queues such as shared buffering.

DiffServ MIB Open Issues (Andrew)

Breakdown of objects into: core, optional and "no way". Each attribute needs to be evaluated to determine its status. There needs to be agreement on conformance statements.

Closer alignment with the Conceptual Model is also an issue:

0. One example is difference in terminology (discarder vs. dropper). Brian would like to see the two converge. The justification for the difference in terminology is that the organization of the components is different between the MIB and the model. The dropper was for AF traffic that does not conform. A discarder drops all packets. Yoram suggested that this was a special case of a dropper. John W. wanted to name everything a dropper (absolute and algorithmic). Dan Grossman stated that the introduction of the term 'discarder' was unintentional, and that it would be appropriate to use dropper to align with RFC 2475. Another terminology item was 'counter' vs.'monitor'. John W. noted that "a monitor is a lizard". Consensus was that all references should be to counters.
1. Cascaded token-buckets are not equivalent to a multi-rate token-bucket: do we need to fix this by allowing a multi-rate TB in the MIB or by defining cascaded buckets to mean "multi-rate"? John W. believes they are not the same thing. Fred and Andrew will discuss this further.
2. Markers were resolved earlier in the discussion where it was agreed that the MIB would only define DSCP markers.
3. Counters: be part of various modules (dropping, scheduling, etc.) or should a separate monitor block be specified. This issue was not given any discussion time.
4. Queue Sets: already discussed previously.
5. Do we need scheduling units of 'packets' (as opposed to KBPS or BPS)? Not discussed.
6. Are absolute rates sufficient or should we include "relative to line speed" ones as well? Not discussed.
7. Scheduler parameters defined in weights vs. rates vs. priorities: the proposed text is confusing. Andrew wanted to use only rates and priorities. Not discussed in the meeting.

DiffServ PIB Issues (Michael Fine)
Michael reviewed the benefits of the PIB. He then discussed the need for 'roles'. There are 4 fundamental PIB elements: Interface Types/Capabilities, Filters/Classifiers, Meters/Actions, and Queues/Thresholds. There are Capability Policy Rule Classes for specifying the capabilities of classification, policing, and scheduling components in devices. Joel was concerned that the classification was too implementation specific and inconsistent with the conceptual model. This discussion was not concluded and will be moved to the list.

(second session)

Brian noted that folks were confused about why behavior aggregate work was part of the charter, even though this was agreed to in December. Kathie presented an overview of the BA draft. The intent of the BA draft is to expand on the BA definition that has been used loosely in DiffServ to date. Another desire was to put in place a process for defining generally useful BAs. Kathie wanted to have the group consider whether these BA documents should be experimental or informational RFCs. A BA should define what Traffic Conditioning is used and how per-hop-behaviors should be specified.

Juha questioned the need for this work. Kathie argued that BA definition was a useful step toward defining services and that particular BA defnitions were not required of network operators.

Van provided a review of the virtual wire BA draft. The purpose of the VW BA is to support circuit-oriented traffic over an IP backbone. The jitter window for any packet in the VW BA is a function of the time slots in the circuit switched network at the egress of the IP network. Therefore, higher link speeds in the IP network will allow larger jitter windows at the egress of the IP network. This additional jitter window allows the order of packet processing due to collisions between different customer packets within the same BA to be immaterial to the service.

Dan Grossman was very confused by the draft, and its implication on the existing definition of BAs, what the topological scope of a BA was presumed to be, whether a BA was intended to be a type or an instance, and in general how this draft related to the existing diffserv architecture. Scott Brim believes that BAs are a good thing to do, but he agrees with Dan that the BA doc is poorly specified. Fred asked whether the BA specification are to be used to help construct domain specific services. Kathie indicated that this was the intent of these drafts. This discussion will continue on the list.

Kwok presented current changes to the MIB. With the limitation of less than 5 minutes of presentation time, Kwok spent most of this time on the major change areas of the more flexible Action Table, Queue Set and Queue Tables. With the dropper as one of the Action Types, relating to the Queues, Kwok presented a specific random drop model. With the flexible Action Table, many different random drop models can be supported by the current MIB, not just one vendor's or just another vendor's. Current rough consensus is to keep the Working Group MIB as flexible to accommodate any vendor's random drop model as done in the version 02 draft, and remove any vendor's random drop model from the Working Group MIB. The terminology of random drop and where it is specified may be changed to align with the Model draft. Van commented that a dropper curve should not be specified. Van also believes the parameters proposed in the Firiou and Borden paper referenced by Kwok will result in a poorly functioning RED.


Quality of Service Policy Information Base
The ‘Virtual Wire’ Behavior Aggregate