The IESG has approved the following document: - 'Configuration Guidelines for DiffServ Service Classes ' <draft-ietf-tsvwg-diffserv-service-classes-02.txt> as an Informational RFC This document is the product of the Transport Area Working Group Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-service-classes-02.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. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
