Update on the IETF Diffserv Working Group NANOG 13 Detroit, MI June 8, 1998

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