Building Blocks for IP Differentiated Services

1
Update on the IETF Diffserv Working
Group NANOG 13 Detroit, MI June 8, 1998
Kathleen M. Nichols knichols_at_baynetworks.com
2
Overview

• Working Group information
• Diffserv overview
• What were doing
• What were not doing
• Where were 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 Discussiondiff-serv_at_baynetworks.com
• Related topicsdiff-serv-interest_at_baynetworks.com
• To Subscribe majordomo_at_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-cha
  rter.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 packets 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 were 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 were 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 were 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-p
  recedence)
• 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