2.7.2 Differentiated Services (diffserv)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99


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@external.cisco.com
To Subscribe: mailer@cisco.com
In Body: subscribe diffserv 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 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 has standardized a common layout to be used for 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 will also standardize a small number of specific per-hop behaviors, and recommend a particular bit pattern or 'code-point' of the DS field for each one.

In addition, an informational framework document will be produced. The framework document will describe more general aspects of the differentiated services environment. It will give general examples and possible services representing our current understanding. Since the services and signalling architectures are expected to undergo the most evolution as diffserv is deployed, this document will capture current understanding only.

Another goal of the WG is to allow experiments 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 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. In particular, 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 for diffserv nodes.

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:

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:



Meet at LA IETF to review strawman spec



Initial discussions and outline for framework doc (FYI)



Revised drafts of spec and framework



Interim meeting to review spec and framework docs



Submit drafts to IESG for consideration as RFCs



Meet at Chicago IETF to discuss boundary mechanisms and traffic conditioners



Publish drafts on boundary mechanisms and traffic conditioners



Meet at IETF to finalise boundary mechanisms and traffic conditioners documents



Finalize EF per hop behaviour draft, submit to IESG



Publish boundary device model and MIB drafts



Finalize AF per hop behaviour draft, submit to IESG



Meet at Minneapolis IETF to finalize framework draft and discuss boundary draft and MIB draft

May 99


Finalize boundary and MIB drafts, submit to IESG

Jul 99


Meet at Oslo IETF to review traffic conditioner drafts and open issues.

Sep 99


Finalize traffic conditioner drafts


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

Differentiated Services Working Group Minutes
IETF Summer 1999 Meeting, Oslo Norway
July 12, 1999

Co-chairs: Kathie Nichols, Brian Carpenter
Reporter: David Black

Update and Agenda Bashing, Kathie Nichols (co-chair)

Two of the presentations on this agenda are for limited purposes
- The MPLS draft presentation concerns only some new terminology proposed in that draft that the authors would like diffserv to adopt.
- PIBs are not currently part of the diffserv charter (subject to change)and hence that presentation is FYI, as the draft is not an official WG work item.

PHB Identification Codes, Scott Brim draft-brim-phbid-00.txt

Draft co-authored w/Brian Carpenter.

This is about support for communicating behaviors during signalling, not DSCPs or individual QoS parameters. Motivating examples are MPLS and bandwidth brokers (during the meeting, MPLS people made it clear that they need this NOW!). Want to standardize a single format to avoid having multiple ad-hoc solutions devised.

Need to communicate PHBs (std and non-std), plus PHB sets. Use a 16 bit field: Standardized PHBs: recommended DSCP is in 6 MSBs, other 10 bits are zero (reserved for future use). For a PHB set, use the lowest (numerically) recommended DSCP. Non-standardized PHBs: 12 bit left justified value assigned by IANA, other 4 bits are 0001.

AFx issue -- what does AF2 mean when signalled? This should be obvious from context, if not, the most general approach is to signal all the detailed QoS parameters.

How many bits? One byte of overhead is worth paying to anticipate future - this is just signaling, not per-packet overhead.

Document needs to be advanced as standards track RFC ASAP, as MPLS and others need it now.

[Audience Comments/Q&A]
This is applicable to "want this traffic treated as EF, tell me what DSCP to use". If DSCP is in LSB, easy to expand. Advantage of current format is that no bit shifting is needed to extract DSCP when recommended DSCP is used, but note that there's no requirement that the network actually use the recommended DSCP for the PHB.

Will add flag to distinguish signaling a PHB set from an individual PHB, as opposed to current approach of inferring this from context. Even the flag doesn't cover all cases, for example AF, allows additional codepoints to be interlaced with standard codepoints to increase the number of drop levels. If this is a concern, explicitly signal every codepoint in the set; further details (e.g., ordering concerns) are specific to the signaling used, and hence get addressed in the appropriate protocol spec, not here (e.g., use of this in RSVP gets handled by issll WG).

IANA registration process allows one non-standard ID to represent a set of PHBs.

Examples will be added to the document, at least MPLS and qbone bandwidth broker; MPLS example text will be provided by people working on MPLS.

Document will be revised and posted to list shortly. NOTE: The document is expected to be last called and sent to the IESG from the working list prior to the next IETF meeting; don't expect to see it again in DC.

MPLS Support for DiffServ, Francois Le Faucheur draft-lefaucheur-mpls-diff-ppp-00.txt

Motivating problem is that MPLS has run out of bits -- only 3 bits are available in the MPLS header for QOS, and a 6 bit DSCP won't fit. Initial work is over ATM and frame relay.

Proposal to use one LSP (Label Switched Path) per FEC (Forwarding Equivalence Class),which may contain multiple behavior aggregates that go into the same queue. Need to encode drop precedence into MPLS (shim) header to make this work (3 bits are available). Looking to have a common solution w/PPP, although PPP has more flexibility.

Point of this presentation is that new terminology is needed:
- Scheduling Aggregate: Set of behavior aggregates that share common ordering constraints, motivating example is AFxy - for a given x, changing the value of y must not cause reordering.
- Per Hop Scheduling - set of PHBs applied to the set of behavior aggregates in a scheduling aggregate. This requires doing things like signaling {AF11, AF12, AF13} as a set.

Purpose of this presentation is to ask diffserv WG to approve and adopt these terms -- the draft as a whole is being handled in the MPLS WG.

Q: Is this additional layer of abstraction necessary when the SA contains exactly 1 BA (e.g., EF)? A: No, it can be omitted.

Q&A: Scheduling Aggregate was called PFC (PHB Forwarding Class) in draft-wu-mpls-diff-ext-01.txt.

This set of new terms is needed in part because PHB group definition in original diffserv RFCs is too broad. It is critically important in this context that the PHBs in this aggregate go into the same queue.

Definition uses the words "ordering constraint" not "queue" - this is deliberate and intended.

In original work on diffserv architecture, the term PHB reordering group was used for this purpose, but was dropped along the way.

Resolution: proposals for alternative wording need to be made on list in the next few weeks, will subsequently call consensus for this on the list, and the words that result from that process will go into the next revision of the diffserv architecture RFC.

ASIDE (from your harried taker of the minutes): If Scheduling Aggregate is used, please avoid abbreviating it as SA in order to avoid confusion with IPSEC Security Associations.

A Conceptual Model for Diffserv Routers, Steve Blake draft-ietf-diffserv-model-00.txt

Need a conceptual model of diffserv routers in order to build management software in a consistent fashion. This is also needed as a basis to design the diffserv MIB, even though the MIB is more specific.

Model is distributed forwarding: router core is surrounded by ingress and egress interfaces. Classification and queuing occur at interfaces, via classifiers, meters, and action elements). Queuing only at output interface. The use of a separate interface per port makes some policies impossible to specify (e.g., constraints on all traffic from a subnet that has multiple paths to a router would require shared state across interfaces).

Classifier splits inbound stream into multiple streams based on filters, includes both BA and MF classifiers. Classifiers can be combined to build more complex ones via logical operations on filter criteria (e.g., AND, OR).

Meter sorts packets from a stream based on some sort of temporal profile (e.g., token bucket, multi-level token bucket, average rate, etc.). Meters can sort into multiple outputs, not just two.

Action elements: dropper (drop all), marker (mark w/one mark), shaper (to temporal profile and queue depth), monitor. Traffic Conditioning Block built by assembling these components. In general classification feeds metering feeds actions.

Material in draft on queuing is known to be incomplete. In addition, the meters defined in the draft are colorblind (i.e., don't take into account previous meter-based traffic marking), more work is needed on the draft to support color-aware meters.

Open issues
- Can all the proposed traffic conditioning elements be adequately modeled?
- Can the PHBs be modeled using the proposed queuing definitions? (not yet)
- Need to line this up with the MIB and PIB drafts.
- What about MPLS?

Q: What is the value of the TCB abstraction?
A: MIB is based on this, each stage can be omitted if not needed.

Diffserv MIB, Fred Baker draft-baker-diffserv-mib-00.txt

Motivation: use conceptual model, keep things simple, support existing PHBs, limit number of counters that are affected by a single packet forwarding.

Default and precedence PHBs have similar functional graphs (describing the router processing that implements the PHB). EF works differently at ingress (meter and drop excess traffic, mark what's left), egress (have to conform to inter-domain SLA) and core (just forward). AF is interesting due to ability to apply one of several codepoints, and the number depends on configuration (e.g., past proposal for more drop levels). Edge marking is based on MF classifier.

MIB design is multi-stage: Classify, Meter, Actions, Queue. First two stages can introduce multiple paths through traffic conditioning.

Consideration of network structure drives need for similar functionality on both input and output, except that queuing is output only.

Classifier requires a supporting table providing classification parameters - has an "otherwise" clause, table can be arbitrary.

Meters built out of simple token bucket meter, can cascade to build more complex meters. Need the "everything conforms" trivial meter. Actions are in the meter table, examples: mark, select queue, apply drop policy.

Monitors: count conforming traffic (packets, bytes) and queue-caused drops (random, tail). Counter structure is a bit complex due to need for larger counters for really fast links vs. simplicity of smaller ones and lack of 64 bit counter support in SNMPv1. What's there is based on advice from an SNMP/MIB expert.

Queue holds traffic and meters out at some rate, hence has shaper functionality (shaper has to have a queue, hence the shaper support was combined with the queuing for simplicity). Only simple priority supported among queues at the moment.

Open issues:
- Completeness of classifiers (something is done with every incoming packet).
- Decision is to ensure completeness by requiring that the "otherwise"/"or else" row always be present, and then it's up to configuration software to set up the classifier so that's never used if that's what's wanted.
- Queues: add max queue depth, buffer allocation policies? Group queues into sets?
- Shapers: Should these be part of the queuing or an action in their own right?
- Do we need multi-rate shapers (draft only has single rate)? Is it important to standardizing different kinds of shapers (i.e., those that shape to different sorts of profiles)?

Q: Can MIB handle general drop mechanisms, as opposed to RED/RIO specifically?
A: Have "other" drop policy, that's a start.

Q: Need richer meters, cascaded token buckets is a good start, is there an extension mechanism? Probably need separate MIB for plugged in meters.
A: No, no extension mechanism at the moment - these issues will be taken offline and addressed in the next version of the MIB.

Q: AF has notion of measuring congestion level to determine what to drop. Need to capture the function used to do this, and in particular the interval over which the average is computed in the MIB.
A: Yes it's missing, list of markers is known to be incomplete, e.g., SRTCM and TRTCM (see Juha's drafts) don't seem to be covered well. Conceptual model is general, will need to fill in details in MIB.

Comment: PHB ID not present in MIB. Should be there in addition to DSCP.

Q: This doesn't seem to be able to handle multi-priority switch fabrics in a router?
A: Can put queue between ingress and fabric to handle this, but that's not required as there are real routers that don't do any queuing there.

Q: Want shaping included in TCB, unclear on difference between shaper and queue. Treat shaping as an action, rather than a side effect of queuing.
A: Open issue, but not clear whether there's a substantial difference between shaping and queuing. Will have to take this one offline.

Q: Use string instead of number to index classifier table?
A: Also take that offline.

Q: Need sufficient queuing parameters are to control buffer allocation in order to run other QoS services concurrently with diffserv.
A: Appropriate for diffserv MIB not to badly break other things. Will take this up offline, concise proposal on necessary parameters will be appreciated.

Q: Generalize MIB by removing restrictions on downstream element to avoid need to structure things into TCBs? Everything can be represented in the current structure, but with a lot of null elements in some cases.
A: Yes, that's the goal, current model draft falls short. MIB needs more work, will take this offline.

Consensus obtained to take design team offline to revise both the model and MIB, results will come back at November DC meeting, significantly more cooked. The current MIB draft will be retitled as a WG doc, and coordinated with improved version of model doc.

PIB, Keith McLoghrie draft-mfine-cops-pib-01.txt

PIB will be added to next version of diffserv charter.

PIB defines data structure for policy download from PDP to PEP (e.g., router). PIB is intermediate between MIB and schema - PIB is config-only (and reports device capabilities), no monitoring or status. PIB aims to capture network-wide policies (that apply at multiple cases), by contrast to MIB that focuses on a single device.

PIB language based on SMI (MIB authoring language), with a few small changes.

Roles used to categorize interfaces to help determine which policies are applicable to which interfaces. Interfaces have a combination of roles, which in turn pick the applicable policy rules.

If PIB is not higher level than MIB, PIB is a waste of time - Keith strongly suggests that the PIB is higher level and hence important.

Diffserv and Tunnels, Brian Carpenter (co-chair).

Problems: What is DSCP in outer header of tunnel? What, if anything should be done to the inner DSCP on decapsulation? IPv4 to IPv6 translator has similar problems.

Can copy DSCP to outer and back to inner only if service level specs match at both ends of tunnels - this is often not the case (e.g., if tunnel is purchased transit, it may well have a different PHB than the flows it carries). IPSEC also forbids mindless copying back to inner at tunnel egress (but flexibility can be obtained provided that it doesn't open up security holes -- ECN is in the midst of doing so).

This issue needs attention because it's already causing problems. RFC 1853 is simply wrong. draft-ietf-ifmib-tunnel-mib-04.txt has been corrected with an escape hatch, also RFC 1933bis has been fixed to leave flexibility, and this may not be the end of the story.

There's going to be an off-line team to formulate an overall approach and write a draft. Volunteers are actively solicited if you're interested, please send email to David Black <black_david@emc.com> and Brian Carpenter <brian@icair.org>.

Discussion of future topics and charter revision postponed, but those interested were advised to attend the DECIDES BOF in Oslo.


DSCPs and tunnels (and translators
PHB Identification Codes