Update on the IETF Diffserv Working Group

1. Update on the IETF Diffserv Working Group NANOG 13 Detroit, MI June 8, 1998 Kathleen M. Nichols knichols@baynetworks.com

2. Overview • Working Group information • Diffserv overview • What we’re doing • What we’re not doing • Where we’re at • Interim meeting, June 11 and 12

3. Diffserv Working Group • In the Transport Area, ADs Scott Bradner and Vern Paxson • Chartered in February, co-chairs Brian Carpenter of IBM and myself General Discussion:diff-serv@baynetworks.com Related topics:diff-serv-interest@baynetworks.com To Subscribe: majordomo@baynetworks.com In Body: subscribe diff-serv (or diff-serv-interest) Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ IETF page: www.ietf.org/html.charters/diffserv-charter.html

4. Goals and Milestones • Apr 98: Meet at LA IETF to review strawman spec • June 98: Interim meeting in Boston, MA (6/11-12) to review revised spec, architecture, framework docs • Jul 98: Submit drafts to IESG for consideration as RFCs (expect spec and architecture doc) • 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

5. What is Diffserv? • Use minimal standardization to provide tools and “knobs” that • Allow traffic engineering within your domain • Allow you to offer new services to customers • Uses a bit-field in the packet (6 bits of the IPv4 TOS or IPv6 Traffic Class octet) as a codepoint to determine the packet’s forwarding treatment

6. Diffserv codepoint and PHB model • Codepoints should be looked at as an index into a table of packet forwarding treatments at each router (PHBs) • Behavior for a few codepoints will be globally assigned (e.g., precedence 6/7 routing traffic) but most codepoints are left for your use • Vendors providing diffserv-capable equipment must make codepoint to behavior mapping flexible and accessible to you

7. How does Diffserv work? • A packet may be marked with a codepoint “anywhere” in the network (but marking probably occurs at domain boundaries) • All packets with the same codepoint get the same behavior (providing aggregation and scalability) • Per-flow state stays at network edges • Marking can be based on microflow identification, the packet ingress link, the measured temporal characteristics of a microflow or aggregate, etc. (Diffserv-capable equipment will include traffic conditioners you can configure.)

8. Examples of traffic engineering with diffserv Use codepoints to: • map packets to weighted round-robin queues • one might get majority share of the output link during congestion • one might get no share unless there is no other traffic • invoke drop preference mechanisms to give preferential treatment to some packets during congestion • mark all traffic bound for “frivolous” web sites for downgraded treatment

9. New Customer Services from Diffserv • Services built by adding rules to behaviors • Rules for initial packet marking • Rules for how particular aggregates are treated at boundaries • Rules for temporal behavior of aggregates at boundaries • Only requires bilateral agreement at domain boundaries (i.e., no end-to-end agreements required)

10. What we’re doing • Specify the fowarding path while letting the policy mechanisms evolve • analogy to IP forwarding/routing • this allows a wide range of uses of the basic building blocks • Standards track for DS field and a small base set of PHBs (with limited RFC791 backward compatibility) • Informational track for architecture doc, specifications of traffic conditioners

11. What we’re not doing • Specifying policy mechanisms and protocols • Service specifications • Specifying specific implementations of PHBs • Standardizing the entire code space of the DS field • Telling you how to use the building blocks

12. Where we’re at now • Five WG drafts: • a strawman spec (“dsopdefs” - out of date) • revised spec (“header-00” - soon to be new version) • “backwards compatibility” spec (“precedence” - to be split) • architecture doc • framework doc • RSVP interoperability informational doc (in pipe) • Next version of the spec (header-01) will come out after the Interim meeting and should include some codepoints from the “precedence” draft

13. Partial Issue List for the Interim Meeting • Allocation of experimental and local use codepoints, migration to standard values • Number and type of PHBs to be allocated specific codepoints in base set • Handling backward compatibility (RFC791) • Mechanisms to deliver assured service • Review of Architectural and Framework documents

14. Some Topics for the Interim Meeting • Proposal for EXP registration/migration • Discussion of first standards track document (draft-ietf-diffserv-header-00,portions of draft-ietf-diffserv-precedence) • Assured service (portions of draft-ietf-diffserv-precedence) • Architecture and Framework documents to be discussed (draft-ietf-diffserv-arch and draft-ietf-diffserv-framework)

15. Summary • Diffserv is useful for both end-to-end service and intra-domain traffic control • The diffserv WG is concentrating on standards track RFCs and informational RFCs that concern the diffserv building blocks that appear in the packet forwarding path, not policy issues • The WG schedule is aggressive and, so far, is being met