NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Brian Carpenter <brian@icair.org>
Kathleen Nichols <nichols@packetdesign.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Scott Bradner <sob@harvard.edu>
General Discussion:diffserv@ietf.org
To Subscribe: diffserv-request@ietf.org
In Body: subscribe your_email_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/diffserv/
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 theIPv4 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 Per-Domain Behaviors (PDBs). A PDB is a collection of packets with the same codepoint, thus receiving the same PHB, traversing from edge to edge of a single diffserv network or domain. Associated with each PDB are measurable, quantifiable characteristics which can be used to describe what happens to packets of that PDB 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 PDB within that network. A PDB 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 PDB 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 PDB descriptions, specific descriptions of PDBs 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
Done |
|
Publish draft of format for BA descriptions |
Done |
|
Meet at Adelaide IETF to review tunnels draft, discuss initial PDB descriptions |
Done |
|
Solicit PDB descriptions |
Jul 00 |
|
Finalize model and MIB drafts, submit to IESG |
Done |
|
Finalize tunnels draft, submit to IESG |
Aug 00 |
|
Finalize PIB draft, submit to IESG |
Done |
|
Finalize PDB format draft, submit to IESG |
Aug 00 |
|
Meet at Pittsburgh IETF to finalize initial PDB descriptions, submit to IESG |
Dec 00 |
|
Meet at San Diego IETF to close any open issues, make WG dormant |
· An Informal Management Model for Diffserv Routers
· Management Information Base for the Differentiated Services Architecture
· New Terminology for Diffserv
· Differentiated Services Quality of Service Policy Information Base
· A Bulk Handling Per-Domain Behavior for Differentiated Services
· A Delay Bound alternative revision of RFC2598
· An Assured Rate Per-Domain Behaviour for Differentiated Services
· Supplemental Information for the New Definition of the EF PHB
RFC |
Status |
Title |
RFC2474 |
PS |
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers |
RFC2475 |
An Architecture for Differentiated Services | |
RFC2598 |
PS |
An Expedited Forwarding PHB |
RFC2597 |
PS |
Assured Forwarding PHB Group |
RFC2983 |
Differentiated Services and Tunnels | |
RFC3086 |
Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification | |
RFC3140 |
PS |
Per Hop Behavior Identification Codes |
Minutes from the Diffserv WG meeting at the 51st IETF
Status
Brian not able to attend.
Things winding down for possible closure or dormancy.
RFC 2598 bis
-- Scott Bradner
We need a "changes since 2598" section.
MIB
-- Fred Baker
25 specific changes have been agreed to and made, particularly a signficant rewrite of the front matter and description clauses so as to make them readable.
Discussion of Classifier Indices occurred. This was driven by several comments on MIB complexity.
Walter Weiss raised some issues on how to represent droppers in this MIB. Walter will provide text describing his proposed changes by Aug 20.
Walter also asked for some changes to improve the flexibility of schedulers. He is providing the description to the list on this.
Kwok and Fred will review the posted edits.
Everything should be completed by Aug 27, the WG chairs' goal for Last Call.
PIB
-- Kwok Ho Chan
Aiming to go to last call on Aug 27 with MIB. Current PIB is aligned with current MIB. Changes will be made to match MIB changes.
There will be a small change needed to the uniqueness class of the qosDataPathEntry.
Informal Model
-- Dave McDysan
The draft describes concerns about the consistency (or lack thereof) in the behavior of traffic meters. He is proposing specific simple text describing what it takes to make shapers and their subsequent policiers consistent. The starting point of the proposed text is to call for using the same policer and shaper. Fred Baker pointed out that some times the appropriate pair are actually different. In general things work if the shaper is "tighter" than the policer, but this is hard to describe simply. John Wroclawski suggested that we may well be willing to work with an "imperfect" definition, rather than trying to produce "perfect" definitions and "perfect" interoperability between shapers and policers. Significant discussion ensued about what should be said, where, and to what degree of precision. It was agreed that if the service is too tightly defined, and the shapers and policers are different, and particularly if the time intervals of interest are small, one is likely not to get the expect behavior consistently. It was also noted that mismatches between expectations of burstiness can also cause undesired treatment.
It was agreed that some warnings about this should be in the informal model, although specifics belong in specific PDBs where they apply. Dave McDysan will provide text to the list to be used by the model editor.
Minor Updates
-- Kathleen Nichols
What to do with the New Terms draft? Proposal is to take one more editing pass, and request publication as an informational RFC. Then, whenever 2474 is ready to be updated the two will be obsoleted together. This proposal received the consensus of the WG at the meeting.
IPv6 Flow ID
-- Alex Conta
This is a heads up on a draft in the v6 working group, to alert diffserv members to relevant work. This draft describes how to use the IPv6 flow label for diffserv classification.
AR PDB
-- Juha Heinanen
The goal of this PDB is to provide support for granting an assured rate of traffic delivery to a traffic aggregate. This PDB uses the AF PHB. There are several simulation studies for a range of interesting cases. Real world experience is rather harder to come by, although strongly desired. Several operators indicated that they are offering services like this, indicating interest in this kind of PDB. Dave McDysan expressed an interest in more concrete specifications, perhaps making it possible in the future to use such a document to aid in discussions and agreements between providers.
John Wroclawski raised a concern that this document may be too broad, and rather than describing a PDB is actually describing a family of PDBs. Dave McDysan described more clearly examples of several distinct PDBs could be that are described in the current draft. Juha will try to tighten up and clarify the description rather than creating several almost identical documents.
The consensus of the room was that the proposed PDB passes the test of being "relevant" by its level of interest, so it should go forward. Kathie pointed out that the PDB process defined in RFC3086 does not require close scrutiny of the simulation and/or experimental results till later in the process.
The MIB
'draft-ietf-diffserv-pib-04'
Consistent Metering in Diffserv Traffic Conditioning
Assured Rate PDB