NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 05-Oct-99
Chair(s):
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 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:
Done |
|
Meet at LA IETF to review strawman spec |
Done |
|
Initial discussions and outline for framework doc (FYI) |
Done |
|
Revised drafts of spec and framework |
Done |
|
Interim meeting to review spec and framework docs |
Done |
|
Submit drafts to IESG for consideration as RFCs |
Done |
|
Meet at Chicago IETF to discuss boundary mechanisms and traffic conditioners |
Done |
|
Publish drafts on boundary mechanisms and traffic conditioners |
Done |
|
Meet at IETF to finalise boundary mechanisms and traffic conditioners documents |
Done |
|
Finalize EF per hop behaviour draft, submit to IESG |
Done |
|
Publish boundary device model and MIB drafts |
Done |
|
Finalize AF per hop behaviour draft, submit to IESG |
Done |
|
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 |
Internet-Drafts:
· A Framework for Differentiated Services
· Format for Diffserv Working Group Traffic Conditioner Drafts
· A Conceptual Model for Diffserv Routers
· Management Information Base for the Differentiated Services Architecture
Request For Comments:
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 |
Diffserv Working Group meeting, Washington D.C.
Chairs: Brian Carpenter and Kathie Nichols
Reporter: David Black (additional notes from Yoram Bernet)
Monday Evening Session, November 8, 1999 -----
Agenda Bashing and WG status
Core WG drafts today. Tomorrow will take up unsolicited drafts.
New Terminology - Dan Grossman, Motorola
(draft-ietf-diffserv-new-terms-01.txt)
This document's purpose is to capture group decisions on terminology and taxonomy for use in future documents. Summary of these changes:
(1) Use the terms Service Level Specification and Traffic Conditioning Specification, not Agreements (latter implies business contracts).
(2) The definition of PHB Group in RFC 2475 doesn't fit the entire set of AF classes. Hence, AF is a type of PHB Group. AF1x, AF2x, AF3x, and AF4x are instances of this type, only the instances are PHB Groups. The next update of RFC 2597 will reflect this.
(3) The DS Field is no longer the entire TOS octet. DS Field is the 6 MSBs of the (former) IPv4 TOS Octet and IPv6 Traffic Class octet. The other two bits are currently unused by diffserv. DSCP is a value in the DS Field. draft-bradner-iana-allocation-02.txt (soon to be an RFC) is an example of this usage.
(4) MPLS needs notion of a set of Behavior Aggregates with a common ordering constraint. Terms: PHB Scheduling Class = PHB group that has a common ordering constraint
Ordered Aggregate = Set of Behavior Aggregates that share an ordering constraint.
The words "All of the packets of an OA are members of the same PHB scheduling class."are problematic due to the use of "members of". Francois Le Faucheur has provided an alternative: "An Ordered Aggregate is the set of Behavior Aggregates that correspond to the PHBs of a PHB Scheduling Class". This will be incorporated into the draft. The terms in (4) are actually applicable to any device that polices an edge interface, MPLS just happened to encounter the need for these terms first, but they're not specific to MPLS
Reference [3] in the draft (RFC 2597) needs to be corrected.
An issue was raised that an ordering constraint affects packets within the same microflow; not reordering the Ordered Aggregate is sufficient to achieve this property, but not necessary. On the other hand working involving the term microflow seems to be a bit strong to put in a core diffserv document. The next version of document will have a parenthesis around the word microflow to reopen this issue.
All other issues in this document are considered to be closed.
PHB ID Draft - Scott Brim, Newbridge
(draft-ietf-diffserv-phbid-00.txt)
This is a minor update to the PHB ID draft (draft-brim-...) from Oslo. This is a teneral purpose approach to signal PHBs (as opposed to DSCPs). Have added a flag to indicate whether PHBID is a single PHB or a set (Bit 14). Sets are as defined in the appropriate document, for unusual sets (e.g., 2 of the 3 AF 1x PHBs), a list of the PHBs should be signalled. Also added a few examples. Standard PHBs use recommended DSCP, otherwise IANA allocates a 12 bit ID value. Bit 15 is set to 1 to indicate latter case.
Next step is to last call this on the mailing list. No opposition to this in the meeting.
A Conceptual Model for Diffserv Routers - Brian Carpenter, WG co-chair (draft-ietf-diffserv-model-01.txt)
The authors are Yoram Bernet, Andrew Smith, and Steve Blake, but Brian is presenting due to absence of Andrew and Steve
Changes since previous draft:
- New Glossary
- Allow all model elements to be associated with both ingress and egress interfaces
- Queues are first class elements in the model
- Routing core function characterized: zero loss/zero delay in conceptual model Actual loss/delay gets reflected in traffic conditioning elements of conceptual model.
- MPLS LSRs acting as Diffserv routers: discussion added, although the DS Field is hidden from an MPLS router. This creates some complications.
- Meters are now separate with more discussion of simple and multi-bucket meters. Appendix A contains a concrete definition of a token bucket.
- Mux, mirror, enqueue, and null action elements added. A mirror makes a logical copy not a physical one, mirror may need to be replaced with another word as part of clarifying text, "tee" is one possible replacement, "inverse mux" is another, "splitter" is a third. Both of these changes need to be made to the text.
- Lots of details added on queue parameters and queue sets. Shaping queue also defined. Removal of items from a queue is not modelled well. Queues can be thought of as having both a buffering element and a scheduling discipline that can be considered separately. Dan Grossman will send some suggested language to the list.
- Traffic conditioning blocks can be composed of any elements connected in any fashion, and TCBs are recursive, and hence can be connected with TCBs and other elements to form yet other TCBs.
- TCBs have 1 input and one output: This is an oversight and will be removed in the next version (e.g., Figure 8 is a TCB with one input and multiple outputs).
The overall motivation for modelling queues is to have enough detail to be able to push rules down to routers - need enough details of how the queue works to write these rules in a standard fashion, but don't want to specify every last implementatation detail.
A discussion ensued about specific queue parameters, such as minimum service rate. The motivation for what was done is that min and max rate are reasonably generic, and going beyond there gets into implementation-specific details very quickly. These are supposed to be primitive elements (e.g., could model a complex implementation queue as being logically composed of multiple primitive queues in the model).
Overall caution - this is not supposed to be a prescription for hardware designers.
- New section on security considerations.
- Appendix A is a new example.
Open Issues ...
- Appendix A token bucket definition is fine as is.
- SRTCM meter cannot be built out of a set of that sort of token buckets. This is an important example as it's very close to Cisco CAR. The meters in this draft are examples, but need to check MIB to make sure that this meter can bemodelled adequately there. Pointing to description of this meter in the AFRFC is an alternative to describing it here, as the cascading token buckets example is easier to describe.
Comment: Put some restrictions on the composition rules to avoid ridiculous things.
Monitoring elements will be generalized to count without an indication of direction so that a monitor can track queue size. Discussion of specific resolution text will have to be on the list where all the authors can participate.
- Should traffic conditioner blocks be allowed to contain classifiers? Seems to be an ok thing to do given how definition of a TCB has evolved, but will not be changed to allow this, as there was no compelling reason to do so.
- RSVP module: discussed on list, RSVP is only an example, hence the module needs a more generic name. Functionality is to handle QoS information that is dynamically signalled, potentially on a relatively fine grain. MPLS LSP setup protocol can also be used as an example here.
Comment: Cable Device MIB has a large amount of policy extensibility, based on classifying packets to an arbitrary number that then has its own set of tables.
- Should MPLS LSRs be mentioned in the model? Yes, MPLS classifiers are an important part of a router implementation.
- Do class selectors require additional queue parameters? No comments in meeting.
Open issues, especially queue issues need to be taken to list for resolution.
Additional notes on the discussion provided by Yoram Bernet:
1. As noted by Steve, the term 'mirroring' needs to be replaced. Suggested alternatives included: splitter, tee, tap (as in wire-tap), inverse-mux.. I think that the point is to use a term that makes it clear that this is a logical copy, not a physical copy (as in for example, multicast).
2. Some expressed the opinion that the abstraction of queues in terms of max rate/min rate is too simplistic to implement the queuing mechanisms that they envisioned. Others (including at least one major router vendor/implementor) indicated that the queuing abstraction in the draft enables the expression of a variety of queuing mechanisms including those that are most used. Suggestion to those who are not happy with the current abstraction - write to the mailing list. Dan Grossman offered to submit text on this to the list.
Aside: A recurring theme related to the purpose of the draft and the nature of indirection intended. The draft attempts to identify the *types* of traffic conditioning elements (e.g. meter, classifier, etc.) and to offer a minimal set of *sub-types* of these types, with the parameter set that would be appropriate. For example - a 'classifier' is a TC element and a BA classifier is a sub-type of a classifier that has a six-bit field as its only parameter. The draft *does not* state that the set of sub-types is exhaustive. On the contrary, it suggests that anybody can define a new sub-type, by specifying the parameter set that is appropriate (and the name of the new sub-type). The draft *offers* a minimal set of sub-types that is believed to be useful and necessary for realizing basic implementations of a diffserv router.
Some suggested that the draft should not define any 'sub-types'. However, the counterpoint presented is that without specifying a minimal set of sub-types, the draft would not go far enough as it would not fulfill its purpose of specifying the basis of a diffserv MIB needed to implement a diffserv router. Since the draft allows for additional sub-types to be defined in other drafts, there is no harm in offering a minimal subset in this draft.
3. There was a discussion of whether the queuing parameters should include
a. a value and a flag indicating whether that value is a max rate or a min rate.
b. two values, one for max rate, one for min rate Suggestion was made that 'b' is preferrable, as it would allow for the specification of both a max and min rate simultaneously. It would also allow for a special value to indicate 'unspecified' min rate and/or max rate.
4. There are words in the Glossary (section 2) to the effect that a TCB has a "single input and output". This conflicts with some of the sample TCB diagrams and was believed by the group to be overly restrictive. A TCB should be allowed to have an arbitrarty number of inputs/outputs. One of the slides presented, suggested a 1:1 nature of a TCB. Nobody really understood what was meant by this. We assumed that it referred to the 1 input, 1 output restriction, which should be removed.
5. There are words in the draft to the effect that a monitor 'increments' for every packet passing through it. This was also believed to be overly restrictive and the suggestion was made that it be specified as something that simply 'counts', with no specification as to whether it counts 'up' or 'down'.
6. There was a suggestion that we look at the 'RFC for the cable device MIB' for an example of traffic conditioning abstractions.
7. There was some discussion regarding the emphasis/de-emphasis of RSVP as a configuration mechanism. The following points were made:
a. to the extent that it is mentioned, it should be cited as an *example of one mechanism* to effect configuration.
b. that it should be captured as a 'qos configuration box'.
c. that it should not simply be captured as a 'qos configuration box' because there is already a box titled 'diffserv config and management interface' and that the box labeled RSVP is sufficiently different because it represents a configuration mechanism that tends to be much more dynamic and much finer grain (per-microflow) a mechanism than represented by its diffserv config counterpart.
d. that MPLS is another example of the need for a dynamic, finer grain configuration mechanism that justifies using two boxes to represent the different types of configuration.
8. The question was asked as to whether MPLS support required anything additional. Response was that the only requirement for MPLS appears to be that the model support a classifier sub-type for MPLS.
Diffserv MIB - Kwok Ho Chan, Nortel
(draft-ietf-diffserv-mib-01.txt)
MIB draft didn't quite make cutoff, but really needs to be discussed.
Added Andrew Smith's IP 6-tuple MF classifier.
Added info on where the classifier configuration information came from.
The latter precipitated a long discussion on whether a more generic approach to indicating the source of arbitrary information, not just classifier configuration information was in order. No clear resolution, as much of the room did not understand the issues well enough to express an opinion. This is complicated by the forthcoming PIB discussion in the OPS configuration management BOF, and hence the whole matter has been taken under advisement by the MIB draft authors.
The queueing text has been clarified to allow multiple queues/scheduling disciplines to be used on the same interface. Discussion on the list determined that the Meter Pass and Meter Fail objects should be allowed to point to anything - the draft will be updated to reflect this.
Queueing issues came up here again. Andrew Smith is expected to provide some text on the use of minimum and maximum rates. Subclassing to add additional queue parameters was mentioned as a possible structure. Van Jacobson will send a detailed proposals to the list on:
- This subclassing approach to queues
- A more general approach to configuring token buckets.
- Changing the meter specification so that the count can never be negative.
Next version will add a table to specify an interface role. This is a policy WG concept that makes higher level provisioning easier to do.
Final addition is that the MIB draft needs a diagram and usage section to clarify relationship of tables, how they are intended to be used, and how this relates to the model.
Still have work to do on this document -- there are issues to be taken to the list. May need an interim meeting to make progress faster than the list has been, but should try email on list first.
Diffserv and Tunnels - David Black, EMC
Your intrepid scribe presented this, hence all I can do is refer to the draft.
Two conclusions:
(1) The final slide of the presentation raised open issues. This will be taken to the list for discussion before preparing a new version.
(2) WG consensus is that this is important, and the next version of this draft should be a WG draft (i.e., draft-ietf-diffserv- ...).
Closing Remarks, Kathie Nichols, WG co-chair
Would like to focus on issues that need to be resolved to encourage diffserv deployment.
Tuesday Afternoon Session, November 9, 1999 -----
This is the unsolicited draft session. These notes capture the brief resolution of what to do with each of the unsolicited drafts, as well as salient points that were discussed.
SNMP-based QoS Programming Interface MIB for Routers
(draft-kanada-diffserv-qospifmib-00.txt)
Portions of this draft are candidates to be merged into the diffserv MIB, especially the classifier objects. The authors of this draft need to take this up with the MIB draft authors, and additional suggestions for things to merge should be sent to the list.
Rate Adaptive Shapers (draft-bonaventure-diffserv-rashaper-01.txt)
This should be discussed on the list and then may be advanced as an Informational RFC as complement to RFC 2697 and 2698 if the WG approves via the list.
draft-bless-diffserv-multicast-00.txt
Multicast issues need to be taken up at some point, but WG has other more pressing matters that need to be attended to first. This draft is primarily about how to add diffserv to multicast routing, and is proposed as material to incorporate into the diffserv architecture RFC (2475). Needs extensive WG discussion in order to revise RFC 2575 (Section 5).
Provisioning material should be taken up with Traffic Engineering WG, not here.
There's also some issll WG work on a multicast branch in the middle of a diffserv network in the intserv over diffserv work.
Need to make sure that the scope is clear before taking up as WG work item, but problem area is important to address.
draft-bless-diffserv-lbe-phb-00.txt
Less than Best Effort PHB. Part of the proposed solution to multicast problems identified in previous draft. Also useful for background data, penalty boxed flows, and deploying multimedia apps in a way that won't disrupt existing traffic.
Significant discussion occurred both in the meeting and on the list about whether a new PHB is necessary. The WG needs to address this set of problems, but the need for a new PHB is an open issue that will be taken to the list. If a new PHB is needed, then it can be decided whether this is the right base document to start from.
One proposal was to remap DSCP 0 to be the same as Class Selector 2, thus turning Class Selector 1 into LBE.
Time Sliding Window Three Color Marker (draft-fang-diffserv-tc-tswtcm-00.txt)
This is a TCP-friendly marker that works better than token bucket for TCP running through RIO-like droppers. Comes in 2 and 3 color versions. There are experimental results that will be reported in Broadcom '99 (December).
The experimental results should be made available to the WG, and then it would be reasonable to have this draft progress to become an experimental RFC. The authors will post a message to the list containing URLs for all of their results.
The diffserv WG is not currently progressing traffic conditioning documents as standards track RFCs.
draft-fu-diffserv-security-00.txt
Despite none of the the authors of this draft being at the session, comments were made that the draft has some merit because it looks at problems caused by boundaries not working correctly - diffserv assumes that edges do work correctly and interior nodes depend on this. Looking at what happens when this assumption is accidentially or deliberately false is of interest, although this draft is at best very preliminary, and in particular needs to have the configuration protocol material removed and taken up with the appropriate protocol WGs.
draft-lin-diffserv-gtc-00.txt
The authors of this draft were not present and did not provide any presentation material, and hence the draft was not discussed. If they would like the WG to do something with this draft, send the request to the list.
draft-nadas-diffserv-experience-01.txt
Update of a previous draft presented at the Oslo decides BOF. This is primarily to provide information to the WG, atlhough an Informational RFC is not the best way to publish this sort of results. The WG thanks the authors for their efforts in making their results available as an Internet-Draft, and encourages others with similar results to do likewise.
Expedited Forwarding with Dropping PHB
(draft-dieder-diffserv-phb-efd-00.txt)
EF for wireless to deal with peculiarities in that domain. Wireless will always drop packets under some circumstances. The proposed PHB eliminates congestion drops, but allows drops caused by media effects in wireless. This PHB may also be useful for fixed networks, to absorb otherwise unused EF capacity.
Needs more discussion on list to decide whether to advance this as a standards track document, experimental document, or not at all.
The Multimedia Color Marker (draft-medina-mmcm-00.txt)
Adaptive color marker for audio/video streams. Modification to Juha Heinanen's three color marker. Adds 3rd Token bucket to limit inbound traffic and drop proactively on ingress rather than reactively when problems occur. Goal is to increase delivery probability of green packets by dropping yellow/red at edge node that knows the difference as opposed to somewhere inside.
An opinion was expressed that marker documents should not also discuss dropping.
The draft needs more feedback, and support from group. Relationship to the existing informational marker RFCs (2697 and 2698) is particularly important to discuss on the list.
Interoperability PHB group (draft-kilkki-diffser-interoperability-00.txt)
This draft reraises a proposal to define PHBs that can be used end-to-end rather than edge-to-edge within a domain. This idea was rejected by the WG almost a year and a half ago at the Cambridge, MA interim meeting, due to opposition from major ISPs.
Representatives of two medium sized network operators opposed consideration of this material here, with one suggesting that the general topic of inter-ISP service interoperability belonged in an ISP industry forum, not the IETF.
End of Meeting Comments
Overall, the areas that seem to be of strong interest are: Multicast issues, Less than Best Effort PHB, and EF with dropping PHB.
Diffserv over specific link layers (primarily PHBs) should be done via changes to the issll WG charter, not in the diffserv WG.
Multicast needs more discussion. In addition to LBE, a separately provisioned and configured EF might also be useful.
A comment was made that the diffserv WG needs to start discussion of services to avoid to avoid inventing new PHBs for services that can be implemented by appropriate configuration of existing PHBs.
More discussion on these topics to come on the list.