Configuration Guidelines for DiffServ Service Classes
RFC 4594

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Configuration Guidelines for DiffServ 
         Service Classes' to Informational RFC 

The IESG has approved the following document:

- 'Configuration Guidelines for DiffServ Service Classes '
   <draft-ietf-tsvwg-diffserv-service-classes-03.txt> as an Informational RFC

This document is the product of the Transport Area Working Group. 

The IESG contact persons are Allison Mankin and Magnus Westerlund.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-classes-03.txt

Technical Summary
 
 This Informational document describes service classes configured with
 Diffserv, and recommends how they can be used and how to construct them
 using Differentiated Service Code Points (DSCP), traffic conditioners,
 Per-Hop Behaviors (PHB), and Active Queue Management (AQM) mechanisms.
 There is no intrinsic requirement that particular DSCPs, traffic
 conditioners, PHBs, and AQM be used for a certain service class, but
 as a policy and for interoperability it is useful to apply them
 consistently.

Working Group Summary
 
 The working group quickly determined that this document should
 be Informational rather than a BCP.  There were other significant
 working group review issues, but the discussions did not entail
 major controversy.
 
Protocol Quality
 
  A directed review of the document was conducted in the working 
 group with written reviews invited from Brian Carpenter, as one 
 of the Chairs of the former Diffserv WG, Alan O'Neill, as an
 expert on mobile multimedia, and David Black, as an expert on
 Diffserv, but also diverse applications and security aspects.
 Revisions followed these reviews.  For the Working Group Last
 Call of the document, a request was sent to many working groups
 representing application or other areas, asking them to take
 another look.  These groups included MPLS, DCCP, the Routing Area
 WG, SIPPING and AVT.  Some comments were received and addressed
 in the final revision.

 James Polk is the WG Chair shepherd.  Allison Mankin is the
 Responsible Area Director.

Notes to the RFC Editor 

Section 3.2,  Network Control Service Class

OLD:
   Traffic characteristics of packet flows in the Network Control
   service class:
   o  Mostly messages sent between routers and network servers
   o  Ranging from 50 to 1,500 byte packet sizes, normally one packet at
      a time but traffic can also burst (BGP)

NEW:
   Traffic characteristics of packet flows in the Network Control
   service class:
   o  Mostly messages sent between routers and network servers
   o  Variable size packets, normally one packet at a time but traffic
      can also burst (BGP)


Section 3.3, OAM Service Class:

OLD:
   Traffic characteristics:
   o  Variable size packets (50 to 1500 bytes in size)
NEW:
      Traffic characteristics:
   o  Variable size packets



Section 4.2, Signaling Service Class
OLD:
   Traffic characteristics:
   o  Variable size packets (50 to 1500 bytes in size)

NEW:
   Traffic characteristics:
   o  Variable size packets, normally one packet at a time


Section 4.4, Real-time Interactive Service Class
OLD:
   Traffic characteristics:
   o  Variable size packets (50 to 1500 bytes in size)

NEW:
   Traffic characteristics:
   o  Variable size packets

Section 4.7 Low Latency Data Service Class
OLD:
   Traffic characteristics:
   o  Variable size packets (50 to 1500 bytes in size)

NEW:
   Traffic characteristics:
   o  Variable size packets


Section 4.8, High Throughput Data Service Class
OLD:
   Traffic characteristics:
   o  Variable size packets (50 to 1500 bytes in size)

NEW:
   Traffic characteristics:
   o  Variable size packets



Section 1.5.5, Admission Control
OLD:
 Since RTP voice does not react to loss or delay in any
 substantive way, the network SHOULD police at ingress to
 ensure that the voice traffic stays within its negotiated bounds.

NEW:
 Many RTP voice payloads are inelastic and cannot react
 to loss or delay in any substantive way.  For these
 voice payloads, the network SHOULD police at ingress to
 ensure that the voice traffic stays within its negotiated 
 bounds.


Section 4.1, Telephony Service Class
OLD:
 Since RTP telephony flows do not react to loss or substantial
 delay in any substantive way, the Telephony service class
 SHOULD forward packet as soon as possible.

NEW:
 Since the inelastic types of RTP payloads in this class
 do not react to loss or significant delay in any substantive
 way, the Telephony service class SHOULD forward packets as
 soon as possible.  Some RTP payloads that may be used in
 telephony applications are adaptive and will not be in
 this class.